raft：关于只读查询的一些问题

Question

在 raft 的论文文档第 6.4 章中，它给出了绕过 Raft 日志进行只读查询并仍然保持线性化的步骤：

1. 如果领导者尚未将其当前任期内的条目标记为已提交，它会一直等待，直到这样做。领导者完整性 属性保证领导者拥有所有已提交的条目，但在 在其任期开始时，它可能不知道那些是哪些。要了解， 它需要从其任期内提交一个条目。 Raft 通过具有 每个领导者在开始时向日志中提交一个空白的 no-op 条目 它的任期。一旦这个 no-op entry 被提交，leader 的 提交索引将至少与任何其他服务器一样大 它的期限。
2. 领导者将其当前提交索引保存在局部变量 readIndex 中。这将用作版本的下限 声明查询操作的对象。
3. 领导者需要确保它没有被它不知道的新领导者取代。它发出新一轮的心跳和 等待大多数集群的确认。一次 收到这些确认后，领导者知道可以 在发送 心跳。因此，当时 readIndex 是最大的提交 集群中的任何服务器都见过的索引。
4. 领导者等待其状态机至少前进到 readIndex；这足以满足线性化。
5. 最后，领导者针对其状态机发出查询，并将结果回复给客户端。

我的问题：

a) 对于第 1 步，是否仅适用于刚刚选举出领导者时的情况？因为只有新领导者没有为当前任期提交条目。并且由于 no-op 条目对于找出当前提交的条目是必要的，那么实际上这一步在选举完成时总是需要的，但不仅限于只读查询吗？换句话说，通常，当领导者活动一段时间时，它必须在其任期内提交条目（包括无操作条目）。

b) 对于第 3 步，这是否意味着只要领导者需要提供只读查询，就会发送一个额外的心跳，而不管当前未完成的心跳（已发送但尚未收到主要响应）或下一个计划的心跳?

c) 对于第 4 步，它是否仅适用于追随者（对于追随者帮助卸载只读查询处理的情况）？因为在leader上，committed index已经意味着它被应用到本地状态机了。

总而言之，一般情况下，leader（活跃一段时间）只需要做第3步和第5步，对吧？

Answer 1

a：确实只有第一次选举出leader的时候才会这样。在实践中，当接收到只读查询时，您会检查是否已从领导者的当前任期和队列中提交条目，如果没有，则拒绝查询。

b：在实践中，大多数实现批处理只读查询以提高效率。您不需要发送许多并发心跳。如果心跳未完成，领导者可以在该心跳完成后将任何新的读取排入队列以进行评估。一旦心跳完成，如果有任何其他查询排队，那么领导者将启动另一个心跳。这具有批处理线性化只读查询以提高效率的效果。

c：领导者的lastApplied 索引（其状态机的索引）总是等价于其commitIndex，这不是真的。事实上，这就是为什么在 Raft 中首先有一个lastApplied 索引的原因。领导者不一定必须在提交索引的同时同步应用索引。这确实是特定于实现的。在实践中，Raft 实现通常在不同的线程中应用条目。因此，可以提交一个条目，然后将其排入队列以应用到状态机。一些实现将条目放在队列中以应用于状态机，并允许状态机从该队列中拉条目以按照状态机自己的速度应用，因此何时可以应用条目未指定。在领导者提交的最后一个命令之后应用只读查询至关重要。

另外，你问这是否只适用于追随者。线性化查询只能通过领导者进行评估。我想有一些算法可以用来对追随者进行线性化读取，但这会效率低下。追随者只能保持查询的顺序一致性。在这种情况下，服务器在评估操作时使用状态机的索引响应客户端操作。客户端在每次操作时发送他们最后收到的索引，当服务器接收到操作时，它使用相同的算法来确保其状态机的lastApplied 索引至少与客户端的索引一样大。这对于确保客户端在切换服务器时不会及时看到状态返回是必要的。

如果您想支持来自单个客户端的并发操作的 FIFO 一致性，那么除了 Raft 文献中描述的内容之外，只读查询还有一些其他复杂性。其中一些在 Copycat 的 architecture documentation 中有所描述。