Apache BookKeeper的核心抽象与写入流程

Twitter调研后决定基于Apache BookKeeper（最早可追溯到2008年Yahoo巴塞罗那研究院解决HDFS NameNode可用性问题的研究项目，2014年底脱离ZooKeeper成为顶级项目）来满足[[分布式日志的三大核心需求与负载类型]]，因为它提供三个核心特性：I/O分离、并行复制、容易理解的一致性模型。BookKeeper由三个组件构成：客户端（Client）、数据存储节点（bookie）、元数据存储服务ZooKeeper——bookie启动时向ZooKeeper注册节点，Client通过ZooKeeper发现可用的bookie。它的核心读写单元叫Ledger（一组追加有序的记录，全局唯一ID）；Client创建Ledger时会从bookie Pool里按数据放置策略挑出一批bookie组成一个Ensemble；每条被追加的记录会被赋予从0开始递增的Entry ID，每条Entry并行发送给Ensemble里的所有bookie，且发送采用流水线方式——发送第N+1条记录不需要等第N条记录的写请求返回。当一条Entry的写操作收到Ensemble里大多数bookie的确认（Acknowledge）后，Client就认为这条记录已经持久化并有大多数副本，可以向Application返回确认；写记录的发送可以乱序，但确认必须按Entry ID顺序有序确认，从而保证日志的严格有序性。如果Ensemble里存活的bookie数量不足以构成大多数，Client会发起Ensemble Change——从bookie Pool里挑选额外的bookie替换掉不存活的bookie，以此保证写操作的高可用性，而不需要停下来等故障恢复。这套设计的核心思路是”用大多数确认换取持久化保证、用并行流水线写换取吞吐量、用Ensemble Change换取故障时的持续可写性”，三者组合起来构成了BookKeeper作为分布式日志底层存储的基础能力。