zookeeper以及分布式事物一致性杂记

zookeeper分布式协调

这个其实是zk很经典的一个用法，简单来说，好比你A系统发送个请求到mq，然后B系统消费。那么A系统如何知道B系统的处理结果？用zk就可以实现分布式系统之间的协调工作。A系统发送请求之后可以在zk上对某个节点的值注册个监听器，一旦B系统处理完了就修改那个节点的值，A立马就可以收到通知

分布式锁

对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行另外一个机器再执行。那么此时就可以使用zk分布式锁，再某个目录下，比方说lock节点下创建一个节点，看自己是不是最小的，是就执行呗，不是就监听比自己次小的节点

元数据/配置信息管理

zk可以用作很多系统的配置信息的管理，比如数据库，kafka、storm等等很多分布式系统都会选用zk来做一些元苏剧、配置信息的管理，包括dubbo注册中心不也支持zk吗

HA高可用

es（选取一个master进行节点协调，primary shard、replica shard）、kafka（topic partition 1 leader，topic partition replica）、redis、dubbo都可以依赖zk来开发HA高可用机制，就是一个重要进行会做主备两个

分布式session

spring+redis

分布式事物

订单系统：TCC强一致性分布式事物

流程图生成流程文件，生成截图：最终一致性

TCC分为三个阶段：

1. Try阶段：对各个服务的资源做检测以及对资源进行锁定或预留
2. Confirm阶段：各个服务中执行实际的操作
3. Cancel阶段：任何一个服务的执行出错，执行回滚

可靠消息最终一致性方案：

1. A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了
2. 如果这个消息发送成功过去了，就执行本地事物，如果成功就告诉mq发送确认消息，如果失败就钙塑mq回顾消息
3. 如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地事物
4. mq会自动定时轮询所有prepared消息回调接口，一般来说这里就可以查下数据库之前本地事物是否执行，如果回滚了，那么这里就回滚吧，这个就是避免可能本地事物执行成功了，别确认消息发送失败了
5. 要是系统B的失败了咋办？重试咯，自动不断重试直到成功，实在不行就B系统执行回滚操作，A系统也执行回滚操作，或者发送报警由人工来手动回滚和补偿