眼下OceanBase中还存在updaeserver单点，下一步的开发任务是使得OB支持多点写入，支持多个UPS(及updateserver)。
当中难点是怎样设计两阶段提交的失败恢复以及多机的快照读写，和同事讨论后，形成一个能够work的简单设计版本号，记录在此。
为分布式事务的两阶段提交细化详细流程，拟採用primary record方式实现失败恢复，即在进入commit阶段之前。先写入primary record 记录当前事务的状态（commit/rollback）。Primary record起到一个全局日志的作用。可供全部參与者读取。须要注意的是，为了保证一致性，读写primary record 都须要加锁，须要使用select update语句。
採用primary record 方式的优势是，协调者在整个事务处理过程中能够是无状态的，不须要记录操作日志。宕机重新启动后不须要做失败处理。而參与者宕机重新启动或超时失败后，能够无需与协调者以及其它參与者通信，实现独立恢复，实现简单。
其缺点是每次分布式事务中都会记录一次primary record，会添加写入数据量以及事务延迟。
将两阶段提交的流程分为下面子流程描写叙述：
Ø 协调者处理流程
Ø 參与者处理流程
Ø 未决事务处理流程
为支持长事务、长事务中长语句以及两阶段提交，文档还简单描写叙述了对UPS日志的改动目标。
最后。文档简单记录了组内讨论实现多UPS快照读写的一些讨论结果。
1. 两阶段提交具体流程
Ø 协调者处理流程
详细流程例如以下图所看到的：
在上图中。当准备写入rollbackprimary record时候，假设已经存在同样的记录，即有可能參与者写入了rollback primary record，是正常情况，详细看后面參与者的处理流程；但假设准备写下commit primary record时候发现已经存在rollback primary record。或者准备写下rollback时候发现存在commitprimary record。这是有问题的，须要报警。人工干预。
Ø 參与者处理流程
參与者处理流程指的是收到协调者发来的start session 请求直到收到end session请求或者失败。
协调者发送startsession时候须要携带primary record 的rowkey。參与者须要将其记录到prepared日志和commit日中。用于失败恢复时候查验primary record和日志回放时候串接prepare日志和commit日志。
因为协调者在開始期间无法得知哪些參与者须要写入数据，哪些參与者仅仅须要读取数据。因此參与者最初的session都是READ ONLY，当收到写入请求后，原先的ROSession升级为RWSession。
同一时候。协调者须要记录相关信息。用于发送prepare消息。
对于开启ROSession的參与者，没有两阶段提交的问题，处理流程和UPS现有逻辑保持一致。对于开启了RWSession的參与者，两阶段提交流程例如以下：
在上述流程中，參与者出现消息超时或者写入失败后，是有权限写rollback primary record的。这种优点是，假设协调者在写primary record前宕机。而參与者在写入prepare日志也宕机，在參与者重新启动处理未决事务时候能够查primary record判定事务状态，无需等到超时就可以终止未决事务。及时完毕回放。
參与者仅仅能写rollbackprimary record。不能写commit primary record。
当写rollback primary record时候。能够同意已经存在rollbackprimary record的情况出现，而不应该存在commit primary record。
另外，另一种情况没有在图中画出来，读写事务開始后，必须沿着一下顺序进行：
处理读写请求->处理prepared请求->处理commit/rollback请求。对于错序请求（即未prepare前收到commit请求），须要异常处理。
Ø 未决事务的处理流程
未决事务来源于下面两种情况：
l 參与者在处理事务请求的过程中出现等待超时；
l 宕机重新启动后回放日志。回放完成全部日志后，还有未提交事务。
对于这两种情况，都採用下面的处理流程：
宕机重新启动后，回放日志时假设出现未决事务（即仅仅有prepare 日志，没有commit日志）。而且未读到primary record，则须要等到此事务超时后。再去尝试写rollback primary record ，其原因是为了防止这样情况的出现：
在一个分布式事务中，一个參与者写下prepared并回应协调者后宕机，但迅速重新启动，重新启动后这个分布式事务还在prepare阶段，在这样的情况下，这个分布式事务还是能够正确提交的。须要注意的时候，超时时间须要将记录在prepare日志中
每一个參与者尝试结束未决事务时，先要读取或写primary record成功primary。假设出错，是会堵塞未决事务的提交或者回滚的。此时须要报警，并保持重试。
在两阶段提交协议中。一旦全部參与者都prepare成功。则要求这个事务一定能提交。但在这个文档所描写叙述的方案中是存在反例的：协调者假设在写commit primary record前宕机，全部參与者超时后走恢复流程，是会将这个事务回滚的。
2. UPS日志改造目标
眼下受限于2MB的网络包最大长度，UPS不支持日志大于2MB的长事务。在两阶段提交的流程中，对于一次分布式事务。至少须要写入两条日志，在这个驱动下，准备改动UPS写入和回放日志的方式。使得其支持长事务以及两阶段提交对日志的要求。
基本想法例如以下：
Ø UPS在运行事务的过程中，假设日志内容超过一定阈值。则异步提交一次日志任务，同一个事务的多条日志之间，使用唯一的事务ID进行关联
Ø 在事务中。UPS支持一条语句写多条日志。使用唯一的语句ID进行关联
Ø ups支持事务内部，单条语句级别的提交和回滚须要记录提交或回滚的日志
对于两阶段提交的日志：
Ø 协调者收到prepare请求时，无需写专用的prepare日志，可是要堵塞等待确认prepare之前运行的语句日志都已经刷盘。
Ø 事务commit/rollback要记录日志，但异步运行，不堵塞协调者，即收到commit请求后。可直接回复协调者，无需等待commit日志落盘。这是由于即便此时commit日志写入失败。也可通过读取primary record又一次完毕提交或者回滚操作。
3. 多UPS快照读和写
多UPS进行分布式事务时。在没有全局时钟的情况下，每一个UPS使用本地时钟独立维护自己的多版本号数据。当一次读写事务涉及多个UPS时候，须要协调者在prepare阶段获取到每一个參与者的本地prepare时间戳，然后使用当中的最大值作为此次分布式事务的时间戳，在commit阶段发给全部參与者，每一个參与者都使用此时间戳作为此次事务写入数据的版本号时间戳。
运行快照读时候，协调者须要使用所涉及的多UPS中时间戳最小作为统一的时间戳。以免读到未提交数据。出现幻读。讨论中。针对快照读。提出一下优化方式：
Ø 每一个UPS中，本地最大事务版本（CV）是在有读写事务提交时后才会更新的，为了避免有的UPS在长时间没有读写事务提交的情况下。CV得不到更新，导致其值远远落后其它UPS，採取定时写入NOP日志的方式。随着时间推移。不断更新CV。
Ø 快照读时。须要使用全部參与者中最小版本（即时间戳）作为本次快照读的时间戳，而因为事务的交互性，无法预知參与者有哪些。为了避免全局广播获取全部机器版本。能够採用以下做法：
快照读的发起者。採用本地版本V作为此次读的版本，发送读请求给其它參与者S。假设S本地的版本小于V，则堵塞等待，直到S的版本大于V后再进行读取。另外。假设S上存在状态为prepare的分布式事务。且这些事务prepare的版本小于S, 则须要等待这些分布式事务进入commit状态。才干继续读取。
这是由于这些状态为prepare的分布式事务转变为commit状态后，其版本既可能大于V也可能小于V。