事务优化1 : 提前响应客户端, 在precommit 之后就响应了客户端, 减少了一次日志持久化的延迟, ob能够保证在任何场景下, 在prepare 只要成功, 后面的事务一定是提交的, 这怎么保证的?
事务的状态由参与者的持久化状态决定，OceanBase 数据库将Paxos 分布式一致性协议引入到两阶段提交，使得分布式事务具备自动容错能力。两阶段提交的每个参与者包含多个副本，副本之间通过Paxos 协议实现高可用，
如果事务处于commit阶段，由于clog已经落盘，即使发生宕机场景，事务都会执行完成，只是业务端可
能会收到事务unknown的回复，需要业务端confirm事务的状态
您好, 我还问了另外一个问题, 和这个问题是相似的问题, 我就直接在这里请教您吧.
传统2阶段4次日志延迟, 1 协调者写prepare日志; 2 参与者写prepare日志; 3 协调者写commit日志; 4 参与者写commit 日志; 共4次.
而ob的2阶段共3次日志延迟; 1 参与者写prapare 日志; 2 参与者写commit 日志; 3 参与者写clear req 日志;
但是ob在参与者事务提交后, 未写 ccommit日志时就想客户端返回了 commit ok; 所以客户端感知的只有1 次日志延迟;
上面的我的理解有没有什么错误?
但是这样有问题吗? 事务提交后, 未落盘 commit 日志时 参与者宕机; 重启后的事务数据状态怎么判断呢? 由于没有commit日志, 只能回滚? 但这时已经向客户端返回commit ok了, 这样是矛盾的; 请问这个问题怎么解决的?
我理解分布式事务才是解决 ACID的问题; paxos 不太了解, 而 raft只是多副本共识, 做到高可用.
raft 并不能保证事务在 prepare 只要成功, 后面的事务一定是提交的.
只要所有参与者都写了prepare日志，那么重启后是可以根据prepare日志还原事务状态的，可以推进commit和clear，最终还是能提交成功。
感谢;
prepare 成功后, 相当于所有要写的数据信息都无丢失的落盘了; 直接返回返回客户端commit ok; 然后clear req, 相当于异步释放锁, 让数据可见.
请问我理解的对吗?
是的
crdb的提交和 这个clear req 这个机制其实有些地方类似; crdb 也是异步线程解析意图; 并且可以访问者驱动完成最终提交或回滚