标签:数据不一致 理论 可能性 执行 不可 状态 超时 alt 信息
1. 分布式
2. 对等性
3. 并发性
4. 缺乏全局时钟
5. 故障总是会发生
1. 网络不可靠
2. 网络分区
3. 节点故障
一致性
可用性
分区容错性
阶段1 提交事务请求
1. 事务询问
2. 写事务日志
3. 各参与者向协调者反馈事务询问的响应
阶段2 执行事务commit
1. 发送提交请求
2. 事务提交
3. 反馈事务提交结果
存在问题
1. 同步阻塞
参与者在等待其他参与者响应请求的过程中,不能进行其他操作。
2. 单点问题
协调者起到了重要的作用,如果在阶段一完成后,协调者出现问题,参与者将等待协调者响应,处于阻塞状态。
3. 数据不一致
当还只有部分参与者收到commit请求时,这时协调者宕机,可能导致部分提交。造成数据不一致。
4. 过于保守
协调者只能根据参与者是否超时,判断是否需要进行事务中断。
5. 无法解决的问题
协调者再发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。
阶段1 CanCommit
1. 事务询问
2. 反馈请求
阶段2 PreCommit
1. 发送事务预提交请求
2. 事务预提交
3. 各参与者向协调者反馈事务预提交结果
阶段3 doCommit
1. 发送提交请求
2. 事务提交
3. 反馈事务提交结果
3阶段提交相对于2阶段提交区别:
1. 3阶段提交解决了2阶段提交单点故障问题。一旦参与者无法及时收到来自协调者的信息超时之后,会默认执行commit,而不会一直持有事务资源并处于阻塞状态。
2. 减少阻塞发生的可能性。通过提交前询问,通过多一次确认,使参与者发生回滚概率变低。
缺点:
如果接收到PreCommit请求时,发生网络分区,导致协调者使部分参与者回滚,而另一部分参与者默认提交,导致不一致的出现。
标签:数据不一致 理论 可能性 执行 不可 状态 超时 alt 信息
原文地址:https://www.cnblogs.com/tomoka/p/10746212.html