2019-10-04
疑问不少
1. 2pc和3pc的第一步到底是不是“类似”？从本文中看，2pc corhort 收到CanCommit已经开始执行事务但不提交，3pc则写着在PreCommit阶段开始预提交。文中说二者第一步“类似”，但其实是非常不类似的吧？
2. 我看到的资料里，3pc出现的目的，并不是文中说的为了解决那两个问题，因为这两个问题的解决方案在2pc中也可以引入。同步阻塞问题和本地事务隔离性相关。数据不一致在两者也都会出现。3pc多了一步，这些就能避免了么？
3pc很多机制在这里没提到，这些才是真正对比2pc的改进。比如只要coordinator收到大多数ack，第三阶段即进入commit状态。本质上3pc并不能像共识算法那样保证一致性，而是比起2pc，增加了在一些未知状态下，“状态可能是成功”的判断依据。
3. 分布式消息中间件实现事务，重点是回查，这点没提啊。展开作者回复: 从你的提问中，可以看出你很爱思考。首先，非常抱歉，因为要忙每周的上线稿子定稿和后续新章节，所以没能及时回复，后面我会注意这个问题，尽量及时回复，希望理解。下面看一下这三个问题：
1. 2pc和3pc的第一步在文中的类似是指，均是通过协调者询问参与者是否可以正常执行事务提交操作，参与者也都会给协调者回复。在2pc中，如果所有参与者都返回结果后，会进入第二阶段的提交阶段，也可以说是执行阶段，根据第一阶段的投票结果，进行提交或取消。在3pc中，进入真正的提交阶段前，会有一个预提交阶段，这个预提交阶段不会做真正的提交，会将相关信息记录到事物日志中，当所有参与者都返回YES后，才会进入真正的提交阶段或执行阶段。
2. 3pc通过在协调者和参与者均引入了超时机制（2pc只是在协调者引入了超时）减少了整个集群的阻塞时间，在一定程度上减少或减弱了2pc中出现的同步阻塞问题；3pc中引入了预提交阶段，相对于2pc来讲，相当于增加了一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
3. 不知道你说的回查是不是指的“失败重试”？如果是的话，这个和业务设计有关系，在介绍ebay系统中有提到，但本文主要是针对基于分布式消息的最终一致性方案的原理进行介绍，所以没有展开介绍。 7 29
2019-10-16
不太明白基于消息队列的方法如何解决数据不一致的问题 如果现在我有四个功能模块 前三个都成功了 按照文中所示协调者已经将前三个模块数据作出修改 但此时如果第四个模块数据更新失败的话 前三个模块如何做到回滚 因为前三个模块都没有锁定数据库资源 2 6
2019-10-10三阶段为什么就不阻塞了？没明白作者回复: 不阻塞的主要原因是在三阶段中引入了超时机制，有了超时机制协调者不用死等其它节点，其它节点也无需死等协调者，从而不会造成堵塞。
1 6
2019-10-04分布式互斥是访问某一个共享资源防止产生不一致现象。分布式事务，是保证一组命令的完整执行或完全不执行。过程来看，都是保证数据一致性的手段。但是两者又不一样，互斥不可以回退（除非发起反向新操作），事务可以回退。 2 4
2019-11-222pc和3pc都会存在数据不一致问题，为什么属于强一致性方案？ 3
2019-11-16基于消息的分布式事务，所给的例子中，如果支付失败或者出货，如何触发“订单系统”回滚？此外，这里的订单，支付和仓库三个节点更像是流水线，而不是事务的概念 2
2019-10-12分布式消息中间件咋解决分布式事务回滚呢，觉得只是搞了个中间件把同步调用改成异步了，记录了状态。 2
2019-10-09三阶段也有一个协调者，为什么就不会有单点故障了？作者回复: 不是绝对地没有单点故障问题了，是一定程度上减少了单点故障带来的问题。三阶段协议中，参与者也引入了超时机制，如果长时间没有得到协调者的响应，在默认情况下，参与者会自动将超时的事务进行提交，不会像两阶段提交那样被阻塞住。
2
2019-10-06可靠消息这种方式必须采用mq吗？使用db是不是也可以，看起来只是一个事务状态的存储和管理，是多个两阶段提交的组合啊！作者回复: 你这个问题提的很好！没有说必须采用MQ，但是MQ天生就是为了高效信息交互而生，所以我在这里是以MQ进行讲解的。使用DB自然是可以的，不过考虑到DB为了保证各种约束而产生的开销，性能上肯定会打一定的折扣。
2
2019-10-05老师能不能放一些参考链接放出来，或者一些引申的链接 2
2019-12-11上节说到分布式共识算法是保障系统满足不同程度一致性的核心算法，那这里的2pc,3pc可以认为是一种分布式共识算法吗？
还有paxos,2pc,3pc等等，这些一致性算法都用在哪些场景呢？最主要的是paxos的应用场景有哪些？ 1
2019-11-11两阶段提交或者三阶段提交的应用场景一般只在数据库之间吧，而且数据库要能支持相关的协议。 比如记录回滚日志，如果不是数据库本身🈶️实现，其他资源要实现很复杂 1
2019-10-12总结了很久，总结出来我的问题是，文中提到的两阶段提交或者三阶段提交应该算是协议层的抽象，想知道具体实现这些协议的项目中协调者和参与者分别是哪些，和他们的关系。 1- 2019-10-04个人感觉应该是分布式事务在并发时会用到分布式互斥，比如基于XA协议，在多个分布式事务并发时，哪个会占用事务管理器资源，这时就会用到分布式互斥;基于分布式消息，消息中间件是不用互斥占用的，但是与消息中间件交互的其他资源管理模块（比如订单模块，支付模块等）在多个事务并发的情况下，就需要有互斥机制了 1
2020-01-20老师 三阶段提交对如下情况是怎么处理的（只考虑协调者挂了的情况，不考虑参与者挂了，并且一阶段完成的情况下）。
2.1、 协调者未发出preCommit 挂了 ，参与者 超时未收到 doCommit/doAbort ,回滚事务。
2.2、协调者发出部分preCommit 挂了 ，参与者 超时未收到 doCommit/doAbort ,回滚事务。
2.3、协调者发全部 preCommit 挂了 ，参与者 超时未收到 doCommit/doAbort ,?。
3.1、协调者收到了 所有 preCommit 的ACK ,协调者未发出doCommit/doAbort 挂了，参与者超时未收到 doCommit/doAbort ,?。
3.2、协调者收到了 所有 preCommit 的ACK ,协调者发出部分doCommit/doAbort 挂了，参与者超时未收到 doCommit/doAbort ,?。
3.3、协调者收到了 所有 preCommit 的ACK ,协调者发出全部doCommit/doAbort 挂了，参与者超时未收到 doCommit/doAbort ,提交/回滚事务。展开
2020-01-133PC的第一步为什么感觉上没什么用。。。
2020-01-072PC和3PC的目标都是维护强一致性，但由于网络分区的存在，实际上是无法完全实现强一致性的，因此采用消息队列的方式，索性不要强一致性了，最终一致性就好- 2020-01-07“三阶段提交协议（Three-phase commit protocol，3PC），是对二阶段提交（2PC）的改进。为了解决两阶段提交的同步阻塞和数据不一致问题”
这一句应该是“为了解决两阶段提交的同步阻塞和单点故障问题“吧，在网络隔离情况下，数据不一致问题并没有解决 - 2020-01-07新增加的预提交阶段，就是为了让参与者知道投票阶段的结果：
1. 如果投票阶段后参与者没能顺利进入下一个阶段，参与者可知协调者可能宕机，会放弃提交或选出新的协调者
2. 如果投票阶段后参与者进入了预提交阶段，参与者可知其他参与者也在打算commit。此时即便协调者宕机，导致在超时结束后参与者还未收到协调者的提交命令，参与者也会默认提交 1 
2020-01-07老师 基于 XA 协议的二阶段提交方法，三阶段方法以及基于分布式消息的最终一致性方法 都有哪些成熟的系统 能给举几个例子吗 想了解一下