分布式事务和分布式锁笔记

-----分布式事务------
单系统事务ACID特性不适用分布式系统&＃xff0c;建议把需要事务的微服务聚合成一个单机服务&＃xff0c;使用数据库的本地事务。不论任何一
种方案都会增加系统的复杂度&＃xff0c;这样的成本实在是太高&＃xff0c;千万不要因为追求某些设计&＃xff0c;而引入不必要的成本和复杂度。

CAP 定理&＃xff0c;又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)的架构师来说&＃xff0c;CAP 就是你的入门理论。
C (强一致性)&＃xff1a;对某个指定的客户端来说&＃xff0c;读操作能返回最新的写操作。对于数据分布在不同节点上的数据来说&＃xff0c;如果在某个
节点更新了数据&＃xff0c;那么在其他节点如果都能读取到这个最新的数据&＃xff0c;那么就称为强一致&＃xff0c;如果有某个节点没有读取到&＃xff0c;那就是
分布式不一致。
A (可用性)&＃xff1a;非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间&＃xff0c;
一个是合理的响应。合理的时间指的是请求不能无限被阻塞&＃xff0c;应该在合理的时间给出返回。合理的响应指的是系统应该明确返
回结果并且结果是正确的&＃xff0c;这里的正确指的是比如应该返回50&＃xff0c;而不是返回40。
P (分区容错性)&＃xff1a;当出现网络分区后&＃xff0c;系统能够继续工作。打个比方&＃xff0c;这里集群有多台机器&＃xff0c;有台机器网络出现了问题&＃xff0c;但是
这个集群仍然可以正常工作。

CAP不可能共存&＃xff0c;P是必然性&＃xff0c;所以只能选择CP或AP架构。但是也不是说完全放弃C或A。于是提出以下&＃xff1a;
BASE解决了CAP中理论没有网络延迟&＃xff0c;在BASE中用软状态和最终一致&＃xff0c;保证了延迟后的一致性。

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写&＃xff0c;
是对 CAP 中 AP 的一个扩展。
基本可用&＃xff1a;分布式系统在出现故障时&＃xff0c;允许损失部分可用功能&＃xff0c;保证核心功能可用。
软状态&＃xff1a;允许系统中存在中间状态&＃xff0c;这个状态不影响系统可用性&＃xff0c;这里指的是 CAP 中的不一致。
最终一致&＃xff1a;最终一致是指经过一段时间后&＃xff0c;所有节点数据都将会达到一致。

1、2PC(两阶段提交):采用XA Transactions的预提交和提交。
保证了一致性(还是有可能不一致)&＃xff0c;容易形成阻塞性能较低。

2、TCC 补偿功能和重试
Try阶段&＃xff1a;尝试执行&＃xff0c;完成所有业务检查&＃xff08;一致性&＃xff09;&＃xff0c;预留必需业务资源&＃xff08;准隔离性&＃xff09;。
Confirm 阶段&＃xff1a;确认真正执行业务&＃xff0c;不作任何业务检查&＃xff0c;只使用Try阶段预留的业务资源&＃xff0c;Confirm 操作满足幂等性。要求具备幂等
设计&＃xff0c;Confirm 失败后需要进行重试。
Cancel 阶段&＃xff1a;取消执行&＃xff0c;释放Try阶段预留的业务资源&＃xff0c;Cancel操作满足幂等性。Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。

3、MQ事务
异步确保&＃xff0c;向银行转账就可以。
转账放扣钱后向MQ消费方发送一个消息&＃xff0c;如果收款方失败可以不断重试直到成功。

-------分布式锁---------------
可以保证在分布式部署的应用集群中&＃xff0c;同一个方法在同一时间只能被一台机器-上的一个线程执行。
这把锁要是一把可重入锁&＃xff08;避免死锁&＃xff09;。
这把锁最好是一把阻塞锁&＃xff08;根据业务需求考虑要不要这条&＃xff09;。
这把锁最好是一把公平锁&＃xff08;根据业务需求考虑要不要这条&＃xff09;。
有高可用的获取锁和释放锁功能。
获取锁和释放锁的性能要好。

乐观锁
基于表字段做分布式锁

悲观锁
Redis的setnx()、 delete()和expire()方法
1)setnx 的含义就是 SET if Not Exists&＃xff0c;其主要有两个参数setnx(key,value)。该方法是原子的&＃xff0c;
如果key不存在&＃xff0c;则设置当前ke 成功&＃xff0c;返回1&＃xff1b;如果当前key已经存在&＃xff0c;则设置当前key失败&＃xff0c;返回0。
2)expire 设置过期时间&＃xff0c;要注意的是 setnx 命令不能设置 key 的超时时间&＃xff0c;只能通过 expire() 来对 key 设置。

ZooKeeper
zk一般由多个节点构成&＃xff08;单数&＃xff09;&＃xff0c;采用zab一致性协议。因此可以将zk看成一个单点结构&＃xff0c;对其修改数据其内部自动将所有节点数据进行修改而后
才提供查询服务。zk的数据以目录树的形式&＃xff0c;每个目录称为znode&＃xff0c;znode中可存储数据&＃xff08;一般不超过1M&＃xff09;&＃xff0c;还可以在其中增加子节点。子节点有
三种类型。序列化节点&＃xff0c;每在该节点下增加一个节点自动给该节点的名称上自增。临时节点&＃xff0c;一旦创建这个znode的客户端与服务器失去联系&＃xff0c;这个
znode也将自动删除。最后就是普通节点。Watch 机制&＃xff0c;client 可以监控每个节点的变化&＃xff0c;当产生变化会给 client产生一个事件。