一致性协议

一致性协议

分布式的好处

1. 提高系统的可用性，避免单点故障
2. 通过负载均衡不同的副本，提高性能

分布式带来的问题

1. 不同副本间数据同步需要时间,数据一致性 可用性的问题，也就是CAP理论

分布式一致性级别

如何保证数据的一致性，同时不影响性能，是分布式系统需要权衡的，进而提出：

1. 强一致性(读写一致)
2. 弱一致性(不承诺读写一致时间，但尽快读写一致，时间未定)
3. 最终一致性(是弱一致性的特例，保证在一定的时间内，达到数据一致，业界推荐)

分布式环境的问题

1. 通信异常(数据传输，路由过程中，硬件和系统不可用导致)
2. 网络分区(分布式系统中部分节点之间不能通信)
3. 三态(成功，失败，超时)
4. 节点故障

2PC和3PC

参考

角色如下 协调者：全局事务 参与者：本地事务

2PC(two-phase commit)

一阶段:

1. 协调者向所有参与者发送提交请求
2. 参与者执行本地事务
3. 参与者反馈执行是否成功，或者超时(失败)

二阶段:

1. 协调者根据一阶段的反馈，向所有参与者发送commit或者rollback
2. 参与者对本地事务执行commit或者rollback，释放资源
3. 反馈回滚结果

缺点：

1. 单点问题(协调者挂了，参与者没接到通知，处于阻塞)
2. 同步阻塞(参与者听从协调者统一调度，不能从事其他操作)
3. 数据不一致(网络问题，只有部分参与者收到commit操作，其他参与者阻塞，产生数据不一致)

3PC

一阶段(can_commit)

协调者向参与者发送是否可以执行事务，并收到反馈

二阶段(pre_commit)

协调者向参与者发送执行事务，并收到反馈，如果参与者等待超时，中断事务

三阶段(commit)

根据事务执行情况，commit或者rollback

2PC和3PC比较

3PC引入了参与者超时机制，假设协调者挂掉，不会一直阻塞等待协调者的通知，但仍然无法避免数据的不一致性 所以一般分布式系统最求最终一致性

MQ事务

利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性

TCC事务

TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现