领导者何时在DistributedLog中确认客户端?

我很难理解领导者什么时候真正认可客户。这是分布式日志的一部分 documentation :

附加到日志段的每个批处理条目都将分配一个 日志段编写器单调增加条目id。所有的 条目在管道中异步写入。日志段 因此,writer会更新一个名为LAP的内存指针 (LastAddPushed),它是最后一个批处理条目的条目id 写入程序推送到日志段存储区。条目可以是 无序写入,但仅在条目id顺序中确认。沿着 成功确认后,日志段编写器也会更新 内存中的指针,称为LAC(LastAddConfirmed)。LAC是条目 写入程序已确认的最后一个条目的id。所有的 LAC和LAP之间写入的条目是未确认的数据 读者看不到它们。

读卡器可以读取高达LAC的条目,因为这些条目是已知的 可持久复制—因此可以安全地读取,而不会出现以下风险 违反读取顺序。写入程序在每个 它发送给簿记员的条目。因此,每个后续条目 使前一条目的记录对读者可见。拉丁美洲和加勒比海 更新可以在 作家由于读者是严格的追随者,他们可以利用LAC 从任何副本读取持久数据,而无需 与作者的沟通或协调。

DL引入了一种类型的系统记录,称为控制 记录-它在两阶段提交算法中充当提交请求。 如果指定SLA内没有到达任何应用程序记录,则写入程序 将生成控制记录。通过写入控制记录 将提升日志流的LAC。添加控制记录 在收到书面用户的确认后立即 记录,如果未添加应用程序记录,则定期记录。它是 配置为写入程序刷新策略的一部分。While控制日志 记录存在于物理日志流中,不会传递 由日志读取器发送到应用程序。

现在考虑以下场景:

1. 领导向簿记员发布消息
2. 追随者获取消息,附加到日志并向领导者发送ACK
3. 领导者从追随者那里获得确认,增加LAC和 答复客户端消息已提交。
4. 现在:Leader还没来得及背上LAC的追随者就失败了 已递增。
5. 问题是:既然潜在的领导者不知道这个事实 LAC已经增加,成为新的领导者 将日志截断为旧LAC,这意味着我们在中丢失了一个条目 由前任领导确认的日志。

因此,客户端已确认消息已成功写入,但已丢失。