共计 1562 个字符，预计需要花费 4 分钟才能阅读完成。
此前，带你读源码第七篇：《一文读懂数据库索引实现原理》尝试从代码导读的角度，简要介绍了 OceanBase 的索引构建流程，率领大家读懂索引构建的相干代码。
本期“源码解读”由 OceanBase 开发工程师刻晴为大家带来“事务日志的提交和回放”。OceanBase 的日志（clog）相似于传统数据库的 REDO 日志，这个模块负责在事务提交时长久化事务数据，并实现了基于 Multi_Paxos 的分布式一致性协定。
日志模块的设计理念
与传统关系型数据库的日志模块相比，OceanBase 的日志服务次要有如下几点挑战：
- 通过 Multi_Paxos 替换传统的主备同步机制，进而实现零碎的高可用和数据的高牢靠。
- 须要反对寰球部署，多个正本之间的网络时延达到几十甚至数百 ms。
- 作为分布式数据库，OceanBase 以 Partition 作为数据同步的根本单位。单机要求反对十万量级的 Partition，在此基础上，须要反对日志数据的高效写入和读取。
- 同时，任何性能自身均须要思考操作的批量化，以减速执行速度。日志服务保护正本的成员列表、Leader 等状态信息，须要为分布式系统的丰盛性能提供高效的反对。
日志的毕生
OceanBase 的日志模块实现了一套规范的 Multi_Paxos，保障在未产生多数派永久性故障的前提下，所有提交胜利的数据均可复原。
同时实现了乱序日志提交，保障事务之间无依赖。在上面对于 OceanBase 对 Multi_Paxos 的工程实现介绍前，咱们默认读者曾经理解 Multi_Paxos 的核心思想，如果你还想理解更多，欢送在社区问答区对 Multi_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 上也可读了。
学完本篇源码解读，心愿你对“事务日志的提交与回放”有了相应理解，下期咱们将为大家带来 OceanBase 存储层代码解读的相干内容，敬请期待！