10 | 原子性：如何打破事务高延迟的魔咒？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
分布式数据库的事务原子性一直是一个挑战，传统的两阶段提交协议（2PC）虽然能保证原子性，但性能一直是一个问题。研究表明，跨两个节点的XA事务的延迟时间总是单机事务的10倍以上，这种性能差距对于企业使用分布式数据库是无法接受的。因此，分布式数据库必须进行优化以打破高延迟的魔咒。 文章介绍了2PC协议的事务延迟估算，指出整个2PC的事务延迟由准备阶段和提交阶段组成。在讨论优化方法时，提到了缓存写提交（Buffering Writes until Commit）的方式，TiDB的事务处理中采用了这种方式，能够压缩第一阶段的延迟，将整个事务延迟缩短至大约一轮共识算法的时间。 然而，缓存写提交也存在一些缺点，如在某些业务场景下可能成为瓶颈，以及对于事务竞争的处理方式与传统的First Write Win有所不同。因此，读者需要在实际应用中权衡利弊。 文章还介绍了CockroachDB采用的Pipeline方式，能够缩短准备阶段的延迟，将整体事务延迟降至一轮共识算法的时间。另外，并行提交（Parallel Commits）也是一种优化手段，可以进一步压缩整体延迟至一轮共识算法的开销。 通过分析事务延迟的计算和优化方法，本文为读者提供了关于分布式数据库事务原子性和性能优化的深入了解，为读者在实际应用中做出决策提供了有益的参考。
《分布式数据库 30 讲》，新⼈⾸单¥59
全部留言(22)
- 最新
- 精选
- OliviaHu目前听下来，感觉分布式系统的主要优化方法就是攒批+异步(事后补偿)。
作者回复: 我觉得叫事后补偿有点不准确，异步线程并不会改变事务的状态，只是追溯出来并落盘。所以叫事后追溯可能更准确些。
2020-08-31217 
春风老师，如果在异步commit之前，客户端又发起查询，查到的数据是怎样的作者回复: 这个处理方式和Percolator类似，如果异步线程还没来得及处理，读取操作也要承担异步线程的工作，确认事务状态，从而判断读取哪个版本的数据。
2020-08-31417
星之柱并行提交这块看的不是很明白，是指prepare阶段即写数据，又将标记设置为staging吗，然后再读的时候来校验staging是否是大多数？作者回复: 事务状态置为staging，是表示事务已经开始但状态未知，而后在所有写入执行完毕后，事务的状态是明确的。但是，如果此时更新事务状态会带来一轮多副本写入的开销，增加延迟。所以，协调者直接向调用方返回事务处理的结果，再由异步线程来更新持久化的事务状态。这个更新过程，不需要考虑多副本的问题，因为所有写入操作都已经完成了多副本的一致性投票。只是要确认每个写入都成功，则可以判定事务成功，否则事务失败。
2020-11-0410
平风造雨如果客户端没有在一定的时间内得到所有意向写的反馈（不知道反馈是成功还是失败），要如何处理？作者回复: 这个问题其实和2PC的优化没有直接关系了，经典2PC也面临这个问题，参与者没有反馈怎么办。这时有两种策略，一是努力成功型，重发指令，也许就还能成功；二是撤销，直接向所有节点发送回滚指令。
2020-09-027
南国老师，我的上一条留言有点小小的问题，就是应该是第二阶段的优化，也就是并行提交可能考虑到了BASE，因为异步提交后，不做其他措施的话可能出现数据不一致的问题，不知道对于并行提交上一条留言说法还对不对。 还有老师，在Pipeline中事务状态的落盘操作理解为准备阶段每一个写操作的落盘，事务状态的确定理解为每一个写操作的确定，还是不同事务之间状态的确定同步完成呢？这里感觉有脑子有点乱。作者回复: 并行提交不是BASE，仍然强一致的。因为，负责发起Pipeline写入的线程是明确知道这些写入都成功了，注意，这个成功是说事务涉及的每个Raft组都写入成功了，那么此时线程可以判定事务已经提交成功了。但是，如果接下来它写盘记录事务的最新状态，就会带来新一轮共识算法开销，而不写盘也不会影响事务状态，所以它直接返回客户端，使得延迟更短。
2020-09-016- 有铭如果异步线程没有任何补偿和回滚操作，那它在check状态时如果发现状态有异常时不做处理吗
作者回复: 事务参与者达成一致状态（成功或失败）主要是同步线程的工作。比如，当网络故障无法获得返回时，同步线程可以根据倾向性选择重试或回滚。不排除网络始终有问题，同步线程无法确定状态，但换作异步线程也同样面临这个问题，没有差异化的处理手段。所以我觉得异步线程的主要职能就是回溯，而不是对状态做实质性干预（包括补偿或回滚），如果真的有这么严重的网络问题，导致所有参与者都无法通讯，那么还是要人工介入解决。
2020-09-043 - 南国第二种优化方法感觉就比较贴近于BASE了，因为效率放弃强一致性而选择最终一致性，这个最终一致性是系统角度的一致性，可以采取像zk一样的方法支持用户角度强一致性，也就是读前先写得到最新的事务号，读取节点被同步前阻塞就可以了；或者就直接维护一个较弱的一致性模型，当然这都是异步线程做的事情了。到头来还是效率和一致性的取舍，所以感觉不同的系统中这个异步线程的实现就至关重要了
作者回复: 这个说法不对，异步化的只是事务状态的落盘操作，而事务状态的确认仍然是同步完成的。再体会体会：）
2020-09-0123 
wy并行提交那个思路有点像悲观锁切换到乐观锁的思路。prepare阶段就像加锁阶段，以往的做法是先prepare，锁住资源再commit，而优化的手段就像乐观锁，先并行执行，有冲突再返回错误作者回复: 我觉得还是有些区别的。并行提交下，在事务执行过程中，协调者节点对参与者节点的状态判断和处理逻辑并没有发生变化。只是对落盘记录的方式做了调整，让两次落盘引发的投票过程可以同时发生，并相应的增加了事后对事务状态追溯的逻辑。而乐观锁和悲观群则在处理逻辑上有明显的变化。你想想是不是这样：）
2021-01-121
花晨少年缓存写提交的耗时为什么不是一轮共识的时间呢，而是两轮呢？不是提交时把多个写操作和提交操作一起并行执行吗？作者回复: 你好，第二轮共识的时间是用来处理事务commit状态落盘。在确认所有写成功后，再次通讯写入事务状态。
2021-06-14- Jenvid目前看下来，感觉分布式系统的主要优化方法就是攒批+异步(事后补偿)。
作者回复: 嗯，也可以这么讲。但异步的具体设计方法还是很巧妙的，也体现了不同产品的水准差异。
2021-04-15
