分布式算法学习笔记---ACID

单机上实现ACID可以通过锁，时间序列等机制实现。
分布式系统由于需要协调多个节点，单机的实现方案就不能保证多个节点之间的ACID特性。
此时就需要分布式事务协议。比如二阶段提交，TCC。
二阶段提交协议
1 选举协调者
2 客户端发消息给协调者
3 协调者发消息给其他事务的参与者，进入提交请求阶段(投票阶段)
4 投票节点根据自己的情况进行投票决定是否执行提交事务。如果一个节点发送了提交事务，那么就必须要保证即使机器故障或者被替换了，都能保证提交协议中自己的一部分，需要在代码实现是保障的
5 协调者统计投票结果，按照“要么全部执行，要么放弃”的原则进行事务的提交或值回滚。
最早是用来实现数据库分布式事务的，现在常用的是XA。
存在的问题：
1 在提交请求阶段，需要预留资源，在资源预留期间，其他人不能操作（比如，XA 在第一阶段会将相关资源锁定）；
2 数据库是独立的系统。
无法调整锁的粒度，影响数据的并发性能。
TCC（Try-Confirm-Cancel）
TCC 是 Try（预留）、Confirm（确认）、Cancel（撤销） 3 个操作的简称。
1 预留阶段，客户端分别给参与事务的节点发送预留信息，如果所有的节点都恢复了OK信息，则进入确认阶段，否则进入撤销阶段
2 确认阶段，客户端发送给参与事务的节点确认操作，等待确认操作的返回
3 撤销阶段，客户端发送给参与事务的节点撤销操作，等待撤销操作的返回
核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作（也就是撤销操作）。
可以理解为编程模型，必须是在业务层保证的，所以必须要保证确认和补偿操作是等幂。
能减轻数据库的压力，但是对业务的侵入性很强，优先考虑二阶段提交。当不能满足业务要求的时候，使用TCC。
开发实现分布式系统，如果不是必须，尽量不要实现事务，可以考虑采用最终一致性。