ceph monitor paxos的实现(一)

ceph monitor的一个主要功能是使用paxos分布式式协议维护一个key/value数据库的一致性。所使用的数据库引擎一般是leveldb。

为了适应不同的数据库引擎， ceph定义一个monitordbstore类来抽象对k/v数据库的操作。对后端数据库要求是支持事务或者原子性的key/value批量更新。它定义个一 transaction类来说明一个事务包含的所有操作，并且这个类是可以序列化和反序列化的，以便在服务器之间传送：

例如它定义个put、erase的成员函数操作:

而序列化、反序列化函数：

ceph 主要用这个monitordbstore来为各个需要使用paxos的模块提供存储，为了各个模块不相互干扰，每个模块会选择一个前缀， 所有属于这个模块的数据都使用这个prefix再加上 一个key，才构成后端数据库真正的key, 具体结构时这样的:

monitordbstore的api 主要是

负责把transaction的每一条操作以原子方式在后端数据库执行，是一个同步操作，而

是一个异步操作，事务完成后会回调一个从context导出的类对象，类似于c语言中的回调函数。

除此以外，monitordbstore还有get操作

定义迭代器用来批量获取数据，它可以指定几个prefix， 并批量把数据追加到一个transaction里面，以便在服务器见批量传数据, 可以预见加进去的数据操作是put操作

ceph内部使用了log来记录最近一段时间的操作，log存放在leveldb中，key的前缀‘paxos’被paxos核心模块保留。每一条log一个key, key的组成是paxos前缀+

index, index是用整数来表示的，顺序增加。为了加快log的查询， 还用"first_committed" "last_committed", 两个key来表示这段log， 前者是第一条log，后者是最后一条log。

每次monitor server启动时都会按照monmap中的服务器地址去连接其他monitor服务器，并同步数据。这个过程叫做bootstrap(). bootstrap的第一个目的是补全数据，从其他服务拉缺失的paxos log或者全量复制数据库，其次是在必要时形成多数派建立一个paxos集群或者加入到已有的多数派中。

启动时将自己加入到一个外部法人集合，因为刚开始自己肯定不是在多数派中：

然后给其它所有它知道的服务器发送探测包：

任何一个服务器收到探测包都会比较自己的最后一次修改数据的版本是否落后于正在探测的服务器的数据：

对于被探测的服务器，如果最后一条log的index number都跟不上对方的第一条记录的index number，意味着已经落后太多了，中间log记录已经缺失，不可能让paxos核心部分通过log来传播数据到本进程以获得数据的最终版本，本进程需要重启bootstrap从对方主动拉数据。此时不会带对方的探测包返回应答。正常情况，我们会报告本服务器的paxos状态:

主要内容包括我们是否是多数派的一员（通过返回多数派成员列表），以及我的paxos log的第一条记录号和最后一条记录号。

一旦一个发出探测包的服务器收到一个应答也会检查paxos log是否过时：

一种情况是我的最后一条log记录和对方的第一条log记录之间有空隙，中间有缺失，只能主动从对方拉数据，道理与上面相同。还有一种是根据配置变量paxos_max_join_drift，数据并没有缺失，但是要传的log超过一个阀值，不如全量从对方复制数据。

输入探测方发现不需要在这个阶段复制数据，并且对方就是多数派的一员，那么可以肯定它的数据是和其他服务器同步的，至少应该乐观的认为,:-) ,所以直接加入到多数派去:

ceph monitor通过bootstrap过程，探测服务器列表中的各个服务器，比对log的最小记录号和最大记录号，直到本机数据的log历史（第一条记录和最后一条记录）都与所有其他服务器有交集，说明本机没有漏掉数据，从而进入多数派的形成过程，为paxos核心部分只通过传播log就可以同步数据创造条件。在boostrap阶段，服务器分析是否存在一个多数派，必要是通过进入竞选形成多数派。在这个阶段的全量同步和部分数据传输，没有介绍，因为相对简单，可以通过阅读ceph源码获得。

本章并未涉及ceph paxos设计最核心部分，有时间再介绍。