09｜原子性：2PC还是原子性协议的王者吗？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
分布式事务的原子性是分布式系统中的重要问题。事务的原子性要求事务要么全部成功，要么全部失败，不允许部分操作成功部分操作失败。在分布式系统中，实现事务的原子性需要采用特定的协议或算法。文章介绍了两种实现事务原子性的协议：面向应用层的TCC协议和面向资源层的两阶段提交协议（2PC）。TCC协议通过Try、Confirm和Cancel三个操作实现事务的原子性，适用于应用层的分布式事务框架，但需要业务编码实现，且操作指令必须具备幂等性。而2PC协议是数据库领域最常用的协议，通过两阶段提交来保证事务的原子性。总的来说，分布式事务的原子性是一个复杂的问题，需要根据具体场景选择合适的协议来实现。 2PC协议的处理过程分为准备和提交两个阶段，每个阶段都由事务管理器与资源管理器共同完成。在准备阶段，事务管理器向所有参与者发送待执行的SQL，并询问是否做好提交事务的准备；参与者记录日志、锁定账户并做出应答。在提交阶段，如果所有数据库的反馈都是Yes，则事务管理器会发出提交指令，数据库进行本地操作，然后向协调者返回Yes，事务结束。2PC协议存在同步阻塞、单点故障和数据不一致等问题，但已有改进模型在不同程度上解决了这些问题。 另一方面，文章还介绍了NewSQL阵营的Percolator模型和PGXC阵营的GoldenDB的一阶段提交。Percolator模型通过全局事务表和异步线程的方式解决了2PC协议存在的一致性问题和单点故障问题，提高了性能。而GoldenDB的一阶段提交则改变了资源的申请方式，采用时间戳排序，减少了网络不确定性的影响，提升了数据库的整体性能。 总的来说，分布式事务的原子性是一个复杂的问题，需要根据具体场景选择合适的协议来实现。2PC协议虽然存在一些问题，但在分布式数据库领域仍然被广泛应用，并且已经有改进模型在不同程度上解决了其存在的问题。同时，新的技术模型如Percolator和GoldenDB的一阶段提交也为分布式事务的原子性提供了新的解决思路和方法。
《分布式数据库 30 讲》，新⼈⾸单¥59
全部留言(24)
- 最新
- 精选
piboyepaxos是共识算法，是对同一份数据的达成共识。2pc更多是为了达成的多份不同数据修改的原子性。不知道这样理解对不？作者回复: 是的，赞。还有延伸内容，同样建议关注第15讲。
2020-08-2818
扩散性百万咸面包老师不是很理解为什么TCC就不用像2PC那样加锁和记日志了呢？TCC如何保证事务隔离性呢？如果有其他代码修改同一行数据怎么办？作者回复: TCC可使用的手段更灵活，不限于数据库锁了。比如，可以增加一个“未冻结余额”字段，初始值和余额一样，一阶段时直接在这个字段上扣减金额，这样后发生的事务如果发现剩下的“未冻结余额”不够，就会返回失败，这样多事务就可以协同了。
2020-08-2858
Eric请问老师，TCC 第二阶段 1. 如果向单元 A 发出 confirm 操作成功且收到成功应答，但向单元 B 发出 confirm 操作失败，这时是否需要通过其它手段来回滚（或者补偿） A 的变更呢？ 2. 如果向单元 A 发出 confirm 操作成功且收到成功应答，向单元 B 发出 confirm 操作成功，但没有收到成功应答，是否应该先确认 B 的状态，然后再决定是否需要回滚（或者补偿）A 的变更呢？ 对于上面2中情况，通常是怎么做的呢？通过分析日志发现异常然后处理吗？作者回复: 问题1，如果单元A成功，单元B失败，则面临一个选择。如果以努力成功为目标，则可以再次向单元B发送指令，有可能成功，这也是为什么要求操作具有幂等性。当然也可以直接撤销A操作，是A与B一样都是失败状态，这种就是失败回滚。 问题2，没有收到应答，其实也和问题1类似，重试争取成功，或者直接回滚。但这里面有个问题是，如果无论发送任何指令，单元B始终也没有返回，怎么办。这个时候基本上就是要人工干预了。当然，对于这种网络通讯故障也不是没有解决办法，有种协议叫做Paxos Commmit，可以极大缓解这个问题，我会在第15讲答疑篇详细介绍，你可以关注下。
2020-09-0337- daka老师的水平非常高啊，每看一讲都有收获，强推
作者回复: 谢谢你的肯定。这个专栏是跳出某个具体产品来讲原理，所以还是很挑听众的，能在每讲都有所收获，说明你也更厉害啊，点赞。
2021-03-173 - 扩散性百万咸面包感觉老师这里可以对Percolator的设计思想再阐述得更详细一些： 1. 为什么需要MVCC来实现percolator?或者说为什么要保存多个版本的key才能实现percolator? 2. 为什么要有个write指向实际数据存储的行？而不是直接存储对应数据？
作者回复: 第一个问题，如果只实现“用主锁来控制事务的原子性，从锁保留指向主锁的指针”这个设计，那确实不一定要用MVCC。Percolator是一个工业实现，它要解决自己的业务需求，除了原子性还有隔离性要处理，使用了MVCC还可以解决读写冲突嘛。 第二个问题，我觉得是设计细节，采用其他形式应该也是可以的。
2020-09-103 - myrfy老师，GlodenDB如何避免全局管理器成为瓶颈呢？
作者回复: 从公开资料看，也没有太特别的设计，就是把这个进程独立部署，这样不会与其他任务竞争资源。
2020-09-032 
南国感觉2PC和Basic-Paxos的过程好像啊，第一阶段的区别是2PC需要全部的回复，而Paxos只需要一半以上的Acceptor回复；第二阶段就几乎一模一样了。至于为什么第一阶段有这样的区别，大概是2PC的每一个节点职能（包括数据）都不相同，要满足一致性约束必须全部的节点的同意；而Paxos抛去每个节点角色不同，它们存储的数据都一样（理想中一致，实际不一致，Paxos会出现日志空缺），为了全局一致，一次同意一半以上就可以了，因为两次一半以上一定是有交集的，这保证了paxos需要的一致性。 至于它们的关系，我觉得它们都是共识算法（consensus），适用前提区别在于节点职能是否相同。作者回复: 我觉得2PC还不是共识算法，因为参与者并不是对一件事情（一个状态）投票，而是要让多个独立的状态要保持一致，且参与者并不了解这种一致性。可以参照15讲的Paxos Commit协议再体会下。
2020-09-011
qinsi关于Percolator，文中提到“在 lock 字段上写入了标识信息的记录就是私有版本，只有当前事务能够操作”，而在例子中又有其他事务读到了私有版本的数据，这是为什么呢？作者回复: 如果加了secondary锁，其他事务确实会读取到，是为了追溯事务状态，再决定读取哪个版本。而在异步线程或第一个读操作维护好状态后，就不再是私有版本了，所以我们说“通常其他事务不能读写”
2020-08-301
李鑫磊2PC 解决的是： 1）小明账户 - 100； 2）小红账户 + 100； 3）小明和小红账户信息存储在不同的数据库实例中； Basic Paxos 解决的问题： 1）客户端不停的有 a=xxx 这样的操作； 2）Basic Paxos 就是让多个节点就 x 的值达成一致； 3）说白了就是数据在多副本之间的复制； 不知道我的理解对不对？作者回复: 是的，点赞。不过两者也可以联系起来看，我在第15讲会有详细说明。
2020-08-281- piboyetcc和goden的方式隔离性有问题吧？ 都可能出现读中间状态的情况
作者回复: 理论上是不会的。GoldenDB是通过全局事务列表统一控制，数据节点（也就是单体数据库）基于日志实现回滚。TCC只要三个操作都正确实现，理论上也不会出现中间状态。
2020-09-06
