Raft 中的 IO 执行顺序 - OpenACID Blog

[giscus[bot]]

Raft 中的 IO 执行顺序 - OpenACID Blog

Raft 先写日志后写 term 会导致已提交数据丢失。本文分析问题本质，总结 TiKV、HashiCorp Raft、SOFAJRaft 的三种安全解决方案

https://blog.openacid.com/algo/raft-io-order-cn/

[longuan]

有一个疑问，“如果N3在写入 E5-1 之后、持久化 term=5 之前崩溃，此时 N3 的存储 term 仍然是 1，但 E5-1 已存在于日志中”，这时N3应该没有响应L5的AppendEntries，L5为什么会认为E5-1 已经被复制到 3 个节点（N5、N4、N3）？

[drmingdrmer]

这个疑问没毛病, 我文中不严谨, 例子中它不会实际造成误以为commit了, 这个结论不对, 实际上的问题是: 允许乱序执行IO在使用异步IO的Raft实现中会引入一些raft 论文中没有详细说明的步骤, 因为raft 论文中都是假设同步IO, 即内存中数据和磁盘上数据是一致的.

让我澄清一下我所说的异步I/O带来的复杂性是什么意思。

Raft论文假设使用同步I/O,并没有讨论异步I/O系统中出现的实现复杂性。

在使用异步I/O的Raft实现中,需要跟踪两个任期(term)值:

• t_mem:内存中的任期,当看到更高的任期时立即更新(例如,在AppendEntries请求中)

• t_disk:持久化的任期,仅在保存任期的I/O操作完成后才更新

• 不变式t_mem >= t_disk始终成立

现在考虑这个场景:收到一个AppendEntries请求,其中append_entries.leader_term == t_mem但append_entries.leader_term > t_disk。处理程序应该同时提交保存任期的I/O和保存条目的I/O,还是只提交保存条目的I/O?

如果你提交两个I/O操作,可能会做冗余工作,但正确性很直观。如果你只提交保存条目的I/O,你必须等待之前提交的保存任期I/O和当前的保存条目I/O都完成后才能响应——这需要跨RPC处理程序跟踪待处理的I/O操作。

这就是I/O顺序很重要的地方:

**允许I/O重排序时:**AppendEntries处理程序必须检查t_mem和t_disk,并跟踪先前保存任期操作的完成情况。

**不允许I/O重排序时:**AppendEntries处理程序只需检查t_mem并只提交保存条目的I/O。一旦该操作完成,所有先前的I/O(包括任何待处理的保存任期操作)都保证已经完成。

Raft论文没有区分t_mem和t_disk,因为它假设使用同步I/O,这使得协议看起来简单直观。该论文没有讨论这些在异步I/O下变得重要的实现考虑因素。

[longuan]

怎么有一股AI味儿哈哈哈。我查了一下，我的问题答案应该是这样：在Raft看来，只要log entry被replicate到大多数节点，这个log entry就被认为是committed，而在这种场景下，committed log被回滚了，所以是不被允许的。不知道这么理解对不对？

[drmingdrmer]

因为你这个问题刚好有人问过, 我之前用英文回答过一遍, 所以直接AI翻译了一下.

只要log entry被replicate到大多数节点，这个log entry就被认为是committed，而在这种场景下，committed log被回滚了，所以是不被允许的。

简单说是这样, 但是Raft明确说了appendEntries需要等save-term IO和save-entries都sync了才能返回appendEntries的response. Raft本身没问题. 是实现中的问题. 另外一个朋友也提到了这个问题, 我重写一下, 明确下问题具体出在实现里而不是Raft本身:
https://blog.openacid.com/algo/raft-io-order-fix-cn/