数据库事务使用日志文件，辅助实现数据库事务。
在分布式系统中，为了获得高可用性，通常会对数据进行复制，以维持数据的多个可用副本。
通过重做日志实现数据复制的思想已经广泛使用，例如，MySQL使用binlog复制从库，Zookeeper主节点向从节点广播操作所有操作序列。
我们需要一个可靠的日志服务组件。但是，要在项目中实现一个高可用的复制方案着实不易，要考虑的问题很多，硬盘故障导致数据丢失，应用宕机数据要恢复，在线扩容应用后数据要再平衡等等。
如果有一个高可用的日志服务，能够按顺序记录应用的所有写操作，我们的复制架构就可以简化为：
1）主节点先写操作日志Write-ahead Logging (WAL)，然后修改主节点本地数据。
2）从节点通过Tail操作日志，完全回放主节点的写操作，从而与主节点的数据保持完全同步。
Apache Bookeeper 的目的就是提供这种高可用分布式日志存储服务。Bookeeper最初是Hadoop用来在线备份HDFS NameNode写操作的日志存储服务，后来成为Apache的一个独立子项目。目前，Apache Pulsar，Twitter通用日志服务组件等很多项目都在使用bookkeeper作为底层存储方案。
Bookeeper采用无主复制方案实现数据复制，它的目标是：高效写，高错误容忍性。
无主复制方案中没有主副本，每个副本是平等的，都需要处理读写操作，依赖多数裁决的方式，来确定操作结果。
1）写操作
写操作发送给所有N个副本，在获得超过半数副本确认后，即认为写成功。
2）读操作
从超过半数的节点读，由于读写的副本集合存在交集，那么一定可以读到写操作的结果。
Bookeeper使用的是相对==宽松的==的无主复制方案，它放宽了读写副本数量的限制，不要求一定超过半数。
创建Ledger时，指定保存数据的bookie节点数E，写节点数Qw，确认节点数Qa，满足: E >= Qw >= Qa 即可。
这带来了很有趣的特性，当E>Qw时，意味着每一次写都只会更新部分节点，Bookeeper利用这个特点，实现了条带化写(类似Raid0的条带化)，使写操作均匀分布在E个节点上。
发生条带化写时，每个节点只保存了一部分数据，因此，读操作需要从多个节点读。
应用需要综合考虑对吞吐量、可用性、数据持久性的要求，使用合理的(E,Qw,Qa)创建Ledger。高吞吐量=>增大E，减小Qw，高可用性=>减小Qa，数据持久性=>增大Qa。
Bookeepr提供的数据一致性保证是：顺序写(写操作不乱序，前面的数据确认前，不会确认后面的数据)，前缀一致读（不会发生数据回滚）。
对每一个Ledger只允许一个Writer，和多个reader，读写可以并行。但是，由于writer只在关闭ledger时才会把该ledger的LastCommitId更新到ledger的元数据中(在zk中保存)，reader没有办法实时获取当前ledger的最新数据进展。当然，reader可以使用屏蔽读打开ledger，这会强制writer关闭ledger。也就是说，读写没办法并行。
在Pulsar中，为每一个topic(由多个ledger构成)指定一个owner，所有消息读写操作都通过owner进行。因此，owner不需要经过zk，就知道LastCommitId，因此可以提供实时的读写并发服务。
可以从Bookeeper官网了解基本概念，相关在资料在文末有链接，这里谈一些笔者自己的理解。
1.Bookeeper的可扩展性怎么体现？
Bookeeper数据存储的逻辑模型：
Ledger的元数据格式：
当创建或重新打开ledger时，会创建一个新的fragment，分配保存数据的bookies。另外，在写数据过程中某一个bookie出现故障时，也会关闭当前frament，创建新的frament，并重新分配保存数据的bookies(不包含出故障的bookie)。
因此，fragment是bookeeper最小的逻辑数据单元，数据持久化的保证也是在fragment的级别上起作用。
通过把应用的日志和数据流分割成一个一个的segment，每个segment存储在Bookeeper的一个ledgers中，数据自然就分布在整个数据集群中。
这样处理的好处：逻辑日志和物理存储解耦，日志大小不局限于单个服务器的存储空间；存储集群中增加新服务器后，新创建的ledgers会自动利用新增的存储空间。
2.什么是条带化写，它带来什么好处？
Bookeeper的复制方案对Write Quorums方案做了一些优化，
E : 副本个数
Qw: 写副本数量
Qa: 等待响应副本数量
E >= Qw >= Qa。
当Qw=E时，Writer向所有Bookies发送写请求。
当Qw<E时，Writer只向部分(Qw)Bookies发送写请求，这就是所谓的条带化写。
选择写Bookies的方式是从第entryid%E个副本开始，向Qw个副本发送写操作。
由于entryid是一个单调递增的值，可以想象，数据被均匀分布在整个副本集E中。
由于条带化只写Qw个Bookie，它降低了系统的IO压力。
3.怎么处理Bookies异常？
writer向Qw个副本发生写操作请求，当收到Qa个Ack时，认为写入成功。
当未收到某个Bookies的响应时，Writer就关闭当前ledgers，设置ledgers的last commit id。然后，新建一个ledgers（新分配的Ensembles不包含出问题的Bookies），开始后续的写操作。
4.当writer异常宕机后，如何正确修复数据和关闭ledgers？
当writer发送故障宕掉时，ledgers会处于未关闭状态，后续的writer/reader必须先修复数据：
a) 在zk中把ledgers置为恢复状态;
b) 通过RPC要求所有相关的Bookies屏蔽该ledgers的所有后续写操作;
c) 向所有Bookies读取该ledgers最后提交的entryId，在收到Qw个Ack后，确定该ledger的最大highEntryId；
d) 从ledger最后活动的fragment头部开始，逐条读取数据，确保每一个entry都有Qw个副本；
e) 最后，在zk修改ledgers为关闭状态，并把最后有效记录置为highEntryId。
5.Bookie如何确定消息的commit状态？如何实现pipeline写？
Bookeeper使用一个类似两阶段提交的方式确定最后提交的entryId，有两种方式发送commit消息，
a）捎带：每条写消息都会携带当前已经提交的最大entryId（writer收到Qa个Ack的消息）。
b）单独发送：在指定时间内没有新消息发送时，单独发一个commit控制消息WriteLacRequest 给Bookies。这个消息对reader不可见。
一旦Bookie收到一个commit entryId，就意味着这个entryId及之前的所有消息都是committied，对reader可见。
写操作和commit在逻辑上是两个独立的操作，很容易在writer实现pipeline写。
例如，当前writer确认当前commitId为100，这时候连续发送了110、111、112三条消息，消息中携带的last commit id都是100。过了一段时间writer收到Qa个对108号消息的确认，在后续发送的113号消息（或者因为没有后续消息，单独发送一个commit消息）中携带的last commit id就要写上108，Bookies收到消息后就可以确认108以前的消息都是已提交的，reader可见。
6.读操作有哪些方式？
常见的两种read方式：
a) 指定entryId读(ReadRequest)，读取一条entry。
b) 长轮询(ReadLacRequest)，实时读最新的记录，达到tail账本的目的。
因为是Quorums读，reader就需要从多个Bookies读数据，这也存在多种方式，
a) 顺序请求，依次向E中的副本读数据，直到读到为止(考虑Bookies数据损坏，或发生条带化写)。
b) 并发请求，同时向E中的所有副本读数据。
7.Bookeeper在zk里保存什么数据？
Bookeeper使用zk:
a) 保存ledger元数据，包括E、Qw、Qa配置，fragment列表，状态(OPEN/CLOSE/RECOVERY)、last commit entryId等。
b) 当使用Log Api时，还要保存Log的元信息。
近来Bookeeper社区有一种声音，要使用etcd代替zk，考虑点：
1. Zookeeper’s log is only exposed through a tree like interface. It can be hard to shoehorn your application into this.
2. A zookeeper ensemble of multiple machines is limited to one log. You may want one log per resource, which will become expensive very quickly.
3. Adding extra machines to a zookeeper ensemble does not increase capacity nor throughput.
另外，Etcd已经在k8s中集成，使用Etcd更方便部署。
8.Bookeeper在存储实现上有哪些优秀的设计？
Bookeeper存储有4个核心组件：
- Journals: WAL日志，提升吞吐量，防止数据丢失。
- Index：为每一个entry，保存在EntryLog文件中的位置索引，{(ledgerId,entryId), offset}。
- EntryLog：顺序保存所有ledger的消息，当bookie启动，或者文件过大时，创建新的EntryLog。
- WriteCache：写操作在同步写入Journals日志，在内存缓存。
- ReadCache: 读操作时先读WriteCache(因为这是最新写入的数据)，如果找不到则从ReadCache查找，如果还没有，则通过Index查找entry的文件偏移，从文件把数据读入ReadCache，最后返回数据给reader。
Bookeeper的Journals日志是同步顺序写，Endex和EntryLog是异步顺序写（后台线程周期性fsync()），把它们放在不同磁盘上，可以充分发挥Bookeeper的IO性能。
参考Understanding How Apache Pulsar Works
9.Plusar使用Bookeeper的基本原理？
Plusar可以认为是建立在Bookeeper/Zookeper上的一个Proxy，
- 使用多个ledger序列来保存一个topic的数据，获得极大的吞吐量和存储扩展性。
- 为每个topic指定一个owner proxy，主题的读写都通过这个owner进行，巧妙的处理了bookeeper中reader无法及时获取ledger的LastCommitId的问题。
- 在proxy上维护cache，减少向bookeeper存储读取数据的次数，提升性能。
- Plusar有一些后台进程，在不断扫描和修复数据，确保每一个fragment都有Qa个副本。
- 基于bookeeper的数据可靠性保证，向Plusar的用户提供数据可靠性保证。
- Plusar可以为每个消费组提供：独占、共享、主备三种访问语义。
从Plusar的底层模型推断，Plusar可以提供"恰好一次"发布语义，
- 当writer不出故障时，Bookeeper存储模型可以保证这一点；当writer故障时，reader可以正确关闭ledger，writer重启后，通过查看ledger的lastCommitId可以知道最后提交的消息，不会发生消息丢失和重复）。
- 但是对于reader来说，它可能在消费了数据，但没有提交commit时意外的挂掉。再重启后，就会读到重复的数据。对这种跨系统的”恰好一次“投递语义，需要应用程序介入。
