收录于话题
#TGIP-CN 内容回顾
22个内容
作为 Pulsar 最重要的一个组件，Apache BookKeeper 支撑着 Pulsar 的一致性、容错性等特点，涉及的内容既多又重要。
所以在上周末的 TGIP-CN 第七期里，延续第六期的 BookKeeper 主题，继续为大家带来了满满的干货。Pulsar 社区年度报告已发布，详情内容可以参考这篇文章：重磅来袭！2020 Pulsar 社区年度报告发布 进行了解和下载。
国内时间 4 月 1 日凌晨 2 点，将在 Zoom 平台举行一次关于 KoP（Kafka-on-Pulsar）的网络研讨会。
活动由来自 OVHcloud 的 Pierre 和 StreamNative 的郭斯杰共同举行。如果你的时间和网络允许，可以扫描下方二维码进行申请。当然我们也会有视频回放，敬请期待！
回顾结束，接下来一起看看这周又有哪些新鲜的 BookKeeper 干货吧！
我们在上周已经讲述了 Bookie、Entry、LastAddConfirm 等概念的相互运作模式。下边的示例中以 3 台 bookie 为基础进行讲解。在一组 bookie 里，利用一台 broker（作为 BookKeeper 的客户端） 去写数据。过程中 broker 会不断的 append entry 到 ledge X 中，T0 时间点更新为 2，这时发出的 entry3 是还没有得到请求回复的。从 broker1 的角度来说，ledger X 写到了 2，即 entry0、entry1、entry2 都写到了 bookie 并都已被确认。所以任何时候用这个 entry ID 都可以找到相应的数据。假设目前 broke2 去接管了当前 topic 的写入，并尝试打开 ledger X 却发现它是 open 状态，这个状态下是无法继续进行读写操作的。那么此时 broker2 就需要对 ledger X 进行一个恢复的操作——Ledger Recovery。Ledger recovery 是指当一个 broker 需要占用一个 partition 时，首先要恢复当前 partition 的最后一个 ledger，这里特指 ledger X。此时返回当前 ledger 里最大的 LAC 数值，然后进行 recovery 的操作执行，让其状态从 open 变为 close。这样操作后，如果 broker1 还在活跃，就有可能还会在 ledger X 进行读写，此时会收到「操作失败」提醒，此时 broker1 知道当前这个 ledger 已经重新在其他 broker 上重新启用，就会取消对它的所属权。由于 entry3 处于 outstanding 的状态，还没有被写到 bookie 上。继续往下读，是没有 entry4 的记录，所以 broker2 在恢复到 4 时发现所有的 bookie 没有进行这条 entry 的读写，就会采取关闭的操作，并将最后一条 entry 写回去。 所以目前 broker2 的状态就是关闭且进行了部分 recovery 的操作，关闭 ledger X 后会再开一个新的 ledger，继续填充数据信息。整个失效恢复的过程，是没有回头复用 ledger 的。因为复用意味着所有元素都处于相同状态且都同意后才能继续去读写，这个是很难控制的。我们从主从复制方式进行切入，将其定义为物理文件。数据从主复制到从，由于复制过程的速度差异，为了保证所有的一致性，需要做一些「删除/清空类」的操作。但是这个过程中一旦包含覆盖的操作，就会在过程中更改文件状态，容易出现 bug。BookKeeper 在运行的过程中，不是一个物理文件，而是逻辑上的序。同时在失效恢复过程中，没有进行任何的复用，使得数据恢复变得简单又清晰。其次它在整个修复过程中，没有去额外动用 ledger X 的数据。
除了上文提到的 FencingRecovery，郭斯杰也在后续讲到了 BookieRecovery 和 AutoRecovery 以及 bookie 的数据回收，具体模型+实例可以参考视频回放中 23:20-38:00 时间段的内容。由于之后的内容涉及到代码实例，回放视频的 41:00- 54:00 时间段内讲述了 BookKeeper on Kubernetes 的相关内容，我们便不再用文字复述，具体可以查看视频。
1. Forward reading 对于写入 essemble 但没有达到 Ack size 要求的数据也会恢复吗？目前的话是不会恢复。这种情况下可以自行选择恢复与否，只需保证最后数据达到一致性状态即可。2. 能详细讲下如何获取未被 Ack 的 entry 如何恢复吗？假设现在 LAC=2，原来的 owner 写了 entry2、entry3、entry4、entry5。但是不确定 entry3/4/5 是否已经被确认了，则恢复的是从 LAC 的 2 开始往前读，看 3 是否满足了请求，以此类推。3. 如果 bookie 4 还未全部恢复，是否可以接受读操作？在 AutoRecovery 状态下，在没有完全恢复的情况下，bookie4 是无法进入到元数据的。所以客户端也不会把整个读请求发到 bookie4 上。理论上可以进行优化，如果中间恢复状态的话，可以利用 bookie4 来提供读请求。4. Bookie4 在恢复过程中，bookie3 又自动恢复了，那 bookie4 的复制过程会被打断吗？会中断 bookie4 的复制过程，保持 bookie3。5. AutoRecovery 时，一个 worker 恢复 ledger 时，可以从多个 bookie 读取不同的 entry，这里是如何选择 entry 从那个 bookie 读取的吗？Entry 存在一个放置策略，基本是一个轮循的状态。在复制时，会优先默认选择第一条 entry。如果第一条 entry 挂掉，则会按顺位方式进行读取。6. Bookie 在 k8s 中的域名，可以自己随便定义吗？7. AutoRecovery 时会有很高的 io，并且出现很多读取超时现象，可以对 AutoRecovery 进行限流吗？可以。在 bookie 的配置里将 batch size 调低即可。8. useHostNameAsBookieID 这个开关，在物理机部署的情况下建议打开吗？如果是内网的话，是不需要用 useHostNameAsBookieID，因为物理机 IP 是固定的。
希望大家通过这两次的直播，对 BookKeeper 的了解可以更加深刻。如果你还没有看过我们 TGIP-CN 的直播，可以点击以下链接进行文字回顾哦。我们所有的直播参考文件都可以在 TGIP-CN 的 repo 下进行查阅，点击「阅读原文」去了解一下吧！