bookkeeper简单分析

上一篇介绍了bookkeeper的安装与测试。这一篇介绍一下bookkeeper的结构与原理。
这是官网给出的bookkeeper结构：

[img]http://dl.iteye.com/upload/attachment/599489/9e5ce5f8-a69b-39b3-8727-48e5f69d3d94.jpg[/img]

bookie就是bookkeeper中的节点，ledger则是log file。由于bookkeeper允许数据复制以保障数据的安全，因此会有一组bookie存放相同的ledger，这称为一组quorum。client的写请求是完全并发向这一组quorum中的bookie发起的。

client先要声明一个或多个ledgerhandler来发起写请求，可以为每个ledgerhandler指定要从多少个bookie中选择写到多少台bookie上。比如

bk.createLedger(3,2,DigestType.MAC, new byte[] {'a', 'b'})

意思是从3台固定的bookie中按roundrobin方法挑选2台服务器，分别存放数据的一个副本。这里的roundrobin就是取模循环。同时，ledgerhandler会在zk上创建一个node，用来存放它自己所选取的3台server的名字。这样在分布式环境下，或者在恢复数据的时候，就能知道数据在哪些服务器上了，解决了数据路由的问题

当发起写请求时，client提供一个id，然后先将数据路由到对应的服务器上，在该服务器上先追加到log中，然后内存中记录一下，就返回给client。如果是用异步调用的方法，client可以通过回调函数及id来确定数据是否写成功。由于write ahead log是顺序写，所以速度很快。同时，server端会定期将内存中的数据flush到磁盘（默认100ms）。这个过程中会生成索引，索引是以id的ascii码来排序建立两级目录，在二级目录下存放相应数据对应的数据文件中的offset。读请求会通过该id获取索引目录，从而获取数据的offset，来读到相应的数据。

当一台server挂掉时，如果replication为2,那么client会在第一次读失效时，自动路由到它的备机去读取数据。因此bookkeeper有一定的故障恢复保障。提高replica因子，数据安全性就随之提高了。恢复数据会根据sequenceId从log中恢复到data中，这一点和大多数系统，比如hbase都是类似的。