从15年3月接触Ceph分布式存储系统，至今已经5年了；因为工作的需要，对Ceph的主要模块进行了较深入的学习，也在Ceph代码层面做了些许改进，以满足业务需要（我们主要使用M版本）。最近得闲，将过往的一些学习心得、改进以及优化思路记录下了，希望能对后来者有所帮助。
这是第三篇：Ceph中IO的一致性
不仅仅是Ceph，所有的分布式存储系统都会涉及到多个层面的数据一致性，具体到Ceph层面，我们从如下几个方面来说明：
- 网络一致性
- 不同对象间的一致性
- 相同对象的并发一致性
- 副本间的一致性
网络一致性
这里的网络一致性是指：Ceph网络消息层面的顺序性；Ceph通过tid将客户端回话（Session）与发送的消息关联起来，这样收到应答后就知道是哪个请求的应答；
总结：通过tid来标识客户端请求
不同对象间的一致性
Ceph采用Crush一致性伪随机算法将对象分配存储到不同的PG中，在OSD层面，采用ShardedOpWQ队列及其关联的OSDShard结构暂存IO请求，各IO请求根据PG id取模暂存到相应的OSDShard中，显然相同PG的不同请求映射到同一个OSDShard；之后OSD通过ShardedThreadPool线程池来处理队列中的请求，各线程根据OSDShard个数取模处理不同的OSDShard中的IO请求，因此不同的PG中的请求可以并行处理，而同一个PG中的对象串行处理，因为OSD在处理PG时会持有PG锁直到IO的元数据提交。
总结：不同PG中的不同对象的请求可以并行处理
相同对象的并发一致性
前面一节中提到，OSD在处理某PG的IO请求过程中，会持有该PG锁直到该IO的元数据提交，因此同一个PG中的对象请求是串行执行的，同一个对象的IO很自然就是串行执行的了，具体点：在bluestore接收到来自OSD的IO请求事务后，会为该事务分配一个OpSequencer（请求序列号），并与新生成的bluestore 事务关联，这样同一个对象的不同请求按照请求序列号排序执行。
总结：PG中同一个对象的请求串行执行
副本间的一致性
Ceph是强一致性分布式对象存储系统，需要等所有的副本都完成IO后才会给客户端返回应答。 那么在异常情况下，是怎么处理的呢？
- 如果IO过程中，主副本没有在规定的时间内收到副本应答，那么主OSD会先发起heartbeat，通过心跳确认副本失联后，主OSD会将 副本OSD down的信息同步给MON，而后主OSD会发起Peering，在peering前，主OSD会将未完成的IO请求requeue，副本选好后，主OSD会重新发起IO。
- 如果IO过程中，主副本挂了，副本也会检测到主副本down，然后会有peering，（某个副本被临时选为主副本）requeue IO请求，然后重新发起IO。
- 如果是客户端在发送IO请求前主OSD挂了，那么等peering完成后，客户端会重新获取OSDMap，再次发送请求。
总结：Ceph是强一致的，副本故障后都会将IO requeue，然后重新执行