单写与三写 [英] SingleWrite vs TripleWrite

问题描述

我很清楚何时和何处使用SingleWrite作为MQ中的日志算法是有利的.它使高吞吐量，低并发工作负载受益.当工作负载并发较多时，TripleWrite的开销就更少了.

I have a fairly good grasp on when and where using SingleWrite can be advantageous as a log algorithm in MQ. It benefits high throughput, low concurrency workloads. When the work load is more concurrent, TripleWrite's overhead is less of a factor.

我不理解并且很难找到任何有关TripleWrite(自v6起是Websphere MQ的默认值)的实际实现方式的信息.我知道它实际上不会将每个事务都写入日志三次，并且仅在涉及部分页面时，它的行为与SingleWrite不同.但是它有什么不同呢?它会调用fsync 3次吗?

What I don't understand and am struggling to find ANY information about is how TripleWrite (the default for Websphere MQ since v6) is actually implemented. I know it doesn't actually write every transaction to the log three times, and that it only behaves differently from SingleWrite when partial pages are concerned. But what does it do differently? Does it call fsync three times?

我没有任何实际的实际目的或要解决的问题，这比什么都更具好奇心.我从事Websphere MQ已有两年了，希望对此有所了解.

I don't have any real practical purpose or problem to solve, this is more curiosity than anything. I've been working with Websphere MQ for a couple of years and would like to understand this better.

有人能阐明一切吗?

我已经考虑了很多，其中一种选择是它类似于InnoDB的DoubleWrite. InnoDB有一个双重写入缓冲区，在将更新写入数据文件之前，所有更改都先被顺序写入.恢复时，您有一个完整的成功写入的双写缓冲区可从中恢复，或者表数据从未被修改.

I've thought about it some more and one of the options is that it is something similar to InnoDB's DoubleWrite. InnoDB has a double write buffer that all changes are written to first sequentially, before the updates are written to the data file. On recovery either you have a complete successfully written double write buffer to recover from, or the table data was never modified.

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

I am not sure if this is similar to MQ's TripleWrite because it has been asserted in several different instances that TripleWrite does not repetitively write all the pages, and that TripleWrite only behaves differently from SingleWrite when applied to partial pages.

推荐答案

非常粗略地讲类似以下内容(请记住，该问题仅与部分页面有关，随着您升级MQ版本，它们的可能性越来越小-这就是为什么单次写入的好处大部分都是很小的)

Very roughly speaking its something like the following (Remember the issue is only ever about partial pages which are less and less likely as you move up releases of MQ - that's why the benefit of single write is very minimal mostly)

想象一下，MQ在一个页面中写入了10个字节，因此日志页面中有很多空间(固定大小).当MQ然后想要写更多的字节时(记录器已经移动到页面的其余部分，或者可能(不太可能)少量的更多数据)，它不能只写那个页面，因为磁盘可能在写和写过程中崩溃.可能会破坏为保持完整性而需要保存的内容(前10个字节).因此，第二次写入(具有更多数据)发生在其他位置，随后是第三次写入，其遍历原始页面.因为它始终知道哪些写入成功，所以它知道在恢复步骤期间应使用原始页面还是其他位置"页面.

Imagine MQ wrote 10 bytes into a page, so has lots of space left in the log page (which are fixed sizes). When MQ then wants to write more bytes (either the rest of the page now the logger has moved on, or potentially (less likely) a small amount more data), it cant just write over that page as the disk may crash mid write and would potentially corrupt what was already needed to preserve to maintain integrity (the first 10 bytes). Hence the 2nd write (with more data) occurs elsewhere and is followed by a 3rd write which goes over the original page. Because it always know which writes were successful, it knows whether the original page or the 'elsewhere' page should be used during the recovery step.

这篇关于单写与三写的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！