piboye2020-08-28paxos是共识算法，是对同一份数据的达成共识。2pc更多是为了达成的多份不同数据修改的原子性。不知道这样理解对不？作者回复: 是的，赞。还有延伸内容，同样建议关注第15讲。
18
Eric2020-09-03请问老师，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讲答疑篇详细介绍，你可以关注下。
共 3 条评论7
扩散性百万咸面包2020-08-28老师不是很理解为什么TCC就不用像2PC那样加锁和记日志了呢？TCC如何保证事务隔离性呢？如果有其他代码修改同一行数据怎么办？作者回复: TCC可使用的手段更灵活，不限于数据库锁了。比如，可以增加一个“未冻结余额”字段，初始值和余额一样，一阶段时直接在这个字段上扣减金额，这样后发生的事务如果发现剩下的“未冻结余额”不够，就会返回失败，这样多事务就可以协同了。
共 5 条评论7- daka2021-03-17老师的水平非常高啊，每看一讲都有收获，强推
作者回复: 谢谢你的肯定。这个专栏是跳出某个具体产品来讲原理，所以还是很挑听众的，能在每讲都有所收获，说明你也更厉害啊，点赞。
3 - 扩散性百万咸面包2020-09-10感觉老师这里可以对Percolator的设计思想再阐述得更详细一些： 1. 为什么需要MVCC来实现percolator?或者说为什么要保存多个版本的key才能实现percolator? 2. 为什么要有个write指向实际数据存储的行？而不是直接存储对应数据？
作者回复: 第一个问题，如果只实现“用主锁来控制事务的原子性，从锁保留指向主锁的指针”这个设计，那确实不一定要用MVCC。Percolator是一个工业实现，它要解决自己的业务需求，除了原子性还有隔离性要处理，使用了MVCC还可以解决读写冲突嘛。 第二个问题，我觉得是设计细节，采用其他形式应该也是可以的。
3 
myrfy2020-09-03老师，GlodenDB如何避免全局管理器成为瓶颈呢？作者回复: 从公开资料看，也没有太特别的设计，就是把这个进程独立部署，这样不会与其他任务竞争资源。
2
南国2020-09-01感觉2PC和Basic-Paxos的过程好像啊，第一阶段的区别是2PC需要全部的回复，而Paxos只需要一半以上的Acceptor回复；第二阶段就几乎一模一样了。至于为什么第一阶段有这样的区别，大概是2PC的每一个节点职能（包括数据）都不相同，要满足一致性约束必须全部的节点的同意；而Paxos抛去每个节点角色不同，它们存储的数据都一样（理想中一致，实际不一致，Paxos会出现日志空缺），为了全局一致，一次同意一半以上就可以了，因为两次一半以上一定是有交集的，这保证了paxos需要的一致性。 至于它们的关系，我觉得它们都是共识算法（consensus），适用前提区别在于节点职能是否相同。作者回复: 我觉得2PC还不是共识算法，因为参与者并不是对一件事情（一个状态）投票，而是要让多个独立的状态要保持一致，且参与者并不了解这种一致性。可以参照15讲的Paxos Commit协议再体会下。
1
qinsi2020-08-30关于Percolator，文中提到“在 lock 字段上写入了标识信息的记录就是私有版本，只有当前事务能够操作”，而在例子中又有其他事务读到了私有版本的数据，这是为什么呢？作者回复: 如果加了secondary锁，其他事务确实会读取到，是为了追溯事务状态，再决定读取哪个版本。而在异步线程或第一个读操作维护好状态后，就不再是私有版本了，所以我们说“通常其他事务不能读写”
1
李鑫磊2020-08-282PC 解决的是： 1）小明账户 - 100； 2）小红账户 + 100； 3）小明和小红账户信息存储在不同的数据库实例中； Basic Paxos 解决的问题： 1）客户端不停的有 a=xxx 这样的操作； 2）Basic Paxos 就是让多个节点就 x 的值达成一致； 3）说白了就是数据在多副本之间的复制； 不知道我的理解对不对？作者回复: 是的，点赞。不过两者也可以联系起来看，我在第15讲会有详细说明。
1- piboye2020-09-06tcc和goden的方式隔离性有问题吧？ 都可能出现读中间状态的情况
作者回复: 理论上是不会的。GoldenDB是通过全局事务列表统一控制，数据节点（也就是单体数据库）基于日志实现回滚。TCC只要三个操作都正确实现，理论上也不会出现中间状态。