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

Question

我很难理解领导者什么时候会确认客户端。这是DistributedLog documentation的一部分：

  

附加到日志段的每个批处理条目都将分配一个   日志段编写器单调增加条目id。一切   条目在管道中异步写入。日志段   因此，writer更新了一个名为LAP的内存中指针   （LastAddPushed），这是最后一个批处理条目的条目ID   由作者推送到日志段存储。条目可能是   无序写入但只能在输入ID顺序中确认。沿   成功确认后，日志段编写器也会更新   内存中的指针，称为LAC（LastAddConfirmed）。 LAC是参赛作品   作者已经确认的最后一个条目的id。一切   在LAC和LAP之间写入的条目是未确认的数据   他们对读者不可见。

     

读者可以读取LAC中的条目，因为这些条目是已知的   持久地复制 - 从而可以安全地阅读而不会有风险   违反读取订单。作者包括每个当前的LAC   它发送给BookKeeper的条目。因此每个后续条目   使读者可以看到上一个条目中的记录。 LAC   更新可以捎带在由。写的下一个条目上   作家。由于读者是严格的追随者，他们可以利用LAC   从任何副本中读取持久数据，而无需任何副本   与作者沟通或协调。

     

DL引入了一种类型的系统记录，称为控制   record - 它在两阶段提交算法中充当提交请求。   如果没有应用程序记录到达指定的SLA，则编写者   将生成一个控制记录。通过编写控制记录，它   将推进日志流的LAC。控制记录已添加   在收到写入用户的确认后立即   如果没有添加应用程序记录，则记录或定期。它是   配置为作家冲洗政策的一部分。同时控制日志   记录存在于物理日志流中，它们不会被传递   由日志读者提供给应用程序。

现在考虑以下情况：

1. Leader向Bookkeeper发布消息
2. 关注者获取消息，附加到日志并向领导发送ACK
3. 领导者获得粉丝的确认，增加LAC和 回复客户端已提交邮件。
4. 现在：领队失败之前它可以捎带给LAC的粉丝 已增加。
5. 问题是：由于潜在的领导者不了解这一事实 LAC已经增加，它成为新的领导者和 将日志截断为旧LAC，这意味着我们丢失了一个条目 已被前任领导确认的日志。

结果，客户端已确认邮件已成功写入，但已丢失。

Answer 1

  

由于潜在的领导者没有意识到LAC已经增加的事实，它将成为新的领导者并将日志截断为旧的LAC，这意味着我们已经丢失了前一个领导者确认的日志中的条目。 / p>

有几种情况：

1）如果领导者优雅地关闭日志，它将密封它正在写入的日志段。 LAC将被提前，它也将被记录为日志段元数据的一部分（存储在元数据存储中）。

2）如果领导者崩溃并且没有优雅地关闭日志，潜在的领导者会出现，它将通过recovery process。新领导人将做的是：

• a）它将尝试封印前一个领导者写的最后一个日志段。密封过程由簿记客户端完成，其包括两部分：（a）它将围绕日志段。 fencing强制在此日志段中不再发生写入。 （b）然后，它将从最后一个已知的LAC进行前向恢复，并恢复已写入但尚未提交的条目。

• b）恢复最后一个日志段后，新的领导者将打开一个新的日志段来写入条目。

希望这能解释你的问题。

DistributedLog也有一篇论文发表在ICDE 2017中。你可以从here获得它。