数据分片持久化日志流
事务提交前需要先持久化WAL日志，已经checkpoint的WAL说明已经持久化到数据页面中，可以删除，数据页面+redo日志就是全部数据（如下图，data表示已经刷盘的data page，redo表示WAL日志，虚线后面的redo为尚未checkpoint的部分）。按照数据持久化日志流，每个数据分片有自己独立的日志流，redo日志可以认为是数据分片的一部分。
ACID 问题
既然按照数据分片进行持久化，那么对全部数据进行sharding是自然而然的，所有数据对相同分片的修改都推到对应的sharding节点进行，每个分片节点都是唯一的，相当于是单机，直接采用单机的逻辑来解决数据访问冲突，对分片上的并发修改进行定序。
但是，单机的逻辑复用不能解决所有的ACID问题。单机的提交流程是以写提交日志成功来保证AD特性的，在按数据持久化日志的模式下，数据sharding到不同的分片上，一个事务会修改多个分片，进而写多个日志流，多个日志流直接持久化不能保证是原子的，会出现部分修改持久化成功而部分修改持久化失败的情况，破坏AD特性。
为了解决多日志流（针对于同一个事务而言）造成的非原子提交的问题，引入了两阶段提交，其本质是引入一个存疑阶段，对数据的修改进行了持久化，使得明确事务提交前，任何修改都已经写入了redo，但是不表示已经提交，从而不会出现一部分修改认为提交而另一部分修改不被记录的情况。在这种架构下，任何挑战都是sharding和分布式事务引入的新增战场，而分片处理部分几乎沿用单机处理的全部逻辑。
