本文作者：刻晴，对同步协议、事务并发处理有着丰富理解的 OceaBase 开发工程师。
OceanBase 的 clog 日志类似于传统数据库的 REDO 日志，这个模块负责在事务提交时持久化事务数据，并实现了基于 Multi-Paxos 的分布式一致性协议。
日志模块的设计理念
与传统关系型数据库的日志模块相比，OceanBase 的日志服务主要有如下几点挑战：
- 通过
Multi_Paxos替换传统的主备同步机制，进而实现系统的高可用和数据的高可靠。
需要支持全球部署，多个副本之间的网络时延达到几十甚至数百 ms。
作为分布式数据库，OceanBase 以 Partition 作为数据同步的基本单位。
单机要求支持十万量级的 Partition，在此基础上，需要支持日志数据的高效写入和读取。
同时，任何功能本身均需要考虑操作的批量化，以加速执行速度。日志服务维护副本的成员列表、Leader 等状态信息，需要为分布式系统的丰富功能提供高效的支持。
日志的一生
OceanBase 的日志模块实现了一套标准的Multi_Paxos，保证在未发生多数派永久性故障的前提下，所有提交成功的数据均可恢复。
同时实现了乱序日志提交，保证事务之间无依赖。在下面关于 OceanBase 对Multi_Paxos的工程实现介绍前，我们默认读者已经了解Multi_Paxos的核心思想，如果你还不了解Multi_Paxos，可以在微信中关注 OceanBase 官方账号【OB小话痨】，看看我们的paxos小剧场。
以一个分区的一条事务日志为例，正常的流程大致如下：
1.事务层调用 log_service->submit_log() 接口提交日志（其中携带on_succ_cb回调指针）。
2.clog首先为它分配log_id和submit_timestamp，然后提交到滑动窗口中，生成一个新的log_task，本地提交写盘，通过RPC将日志同步给follower。
3.本地写盘完成时调用log_service->flush_cb()，更新log_task状态，标记本地持久化成功，follower写盘成功后给leader回ack。
4.leader收到ack更新log_task的ack_list。
5.leader在4、5两步中会统计多数派，一旦达成majority，按顺序调用 log_task->on_success() 回调事务，同时发送confirmed_info消息发送给follower并将此日志从滑动窗口中滑出。
6.follower收到confirmed_info消息后尝试将此日志从滑动窗口中滑出，在滑出动作中将日志提交回放。
在 Follower 上，会对已提交的日志实时进行回放。回放流程大致如下：
follower在滑出日志时会推大每个分区内记录回放位点的submit_log_task的对应值，这个任务会被异步的提交到一个全局线程池中等待消费。
当全局线程池消费某分区的submit_log_task时，会将其中记录的所有待回放日志以此读盘并分配到所在分区的对应的4个回放任务队列中，分配的方式主要是按照trans_id进行哈希，确保同一事务的日志被分配到一个队列中，被分配到新任务的队列将队列task_queue作为一个任务再次异步提交到1中提到的全局线程池中等待消费。
当全局线程池消费task_queue时，依次遍历队列中所有子任务并根据日志类型执行相应的应用逻辑。至此，一个日志真正的同步到了follower中，在follower上也可读了。
————————————————
（未完待续）
附录：前十篇可参考：
1、OceanBase 数据库源码解读（一）引言
2、OceanBase 数据库源码解读（二）目录结构
3、OceanBase 源码解读（三）SQL 的一生
4、OceanBase 源码解读（四）分区的一生
5、OceanBase 源码解读（五）事务的一生
6、OceanBase 源码解读（六）租户的一生
7、OceanBase源码解读（七）带你看透虚拟表
8、OceanBase源码解读（八）OB高性能执行引擎
9、OceanBase源码解读（九）tableAPI和OB多模型
10、OceanBase 源码解读（十）分布式事务
11、OceanBase 源码解读（十一）：表达式和函数
最后的最后，您有任何疑问都可以通过以下方式联系到我们～
联系我们
欢迎广大 OceanBase 爱好者、用户和客户随时与我们联系、反馈，方式如下：
社区版官网论坛
社区版项目网站提 Issue
钉钉群：33254054
