SingleWrite与TripleWrite

时间:2015-03-27 08:25:47

标签: ibm-mq

我非常了解使用SingleWrite的时间和地点可以作为MQ中的日志算法。它有利于高吞吐量,低并发工作负载。当工作负载更加并发时,TripleWrite的开销不再是一个因素。

我不明白并且正在努力寻找任何有关TripleWrite(自v6以来的Websphere MQ的默认设置)实际实现的信息。我知道它实际上并没有将每个事务写入日志三次,并且当涉及到部分页面时,它的行为与SingleWrite的行为不同。但它有什么不同呢?它会调用fsync三次吗?

我没有任何真正的实际目的或问题需要解决,这比任何事情都更具好奇心。我已经使用Websphere MQ几年了,并希望更好地理解它。

有人能够放弃任何光明吗?

编辑:

我已经考虑了一些,其中一个选择是类似于InnoDB的DoubleWrite。 InnoDB有一个双写缓冲区,在将更新写入数据文件之前,所有更改都按顺序写入。在恢复时,您有一个完整的成功编写的双写缓冲区可以从中恢复,或者表数据从未被修改过。

我不确定这是否与MQ的TripleWrite相似,因为在几个不同的实例中已经断言TripleWrite不会重复写入所有页面,并且TripleWrite在应用于部分页面时的行为与SingleWrite不同

1 个答案:

答案 0 :(得分:5)

非常粗略地说出类似下面的内容(请记住,问题只是关于部分页面越来越不可能随着MQ版本的升级 - 这就是为什么单一写入的好处主要是极少)

想象一下,MQ在页面中写入了10个字节,因此在日志页面中留下了大量空间(固定大小)。当MQ然后想要写更多字节时(现在记录器已移动的页面的其余部分,或者可能(不太可能)少量更多数据),它不能只是写入该页面,因为磁盘可能会在写入期间崩溃可能会破坏保存以保持完整性所需的内容(前10个字节)。因此,第二次写入(具有更多数据)发生在其他地方,然后是第三次写入,其超过原始页面。因为它始终知道哪些写入成功,所以它知道在恢复步骤期间是否应该使用原始页面或“其他”页面。