Zookeeper以及分布式事务概要

一，ZooKeeper：

1. Zookeeper集群中的角色
   1. Leader领导者
   2. Learner学习者：
      1. Follower跟随者
      2. Observer观察者
         3.集群节点的状态：
         1.LOOKING;还未选主
         2.FOLLOEING;选主为folloer节点
         3.LEADING:已选主，为leader节点
         2． Zookeeper的读写机制：
   3. 每个zookeeper节点都有一个内存数据库用于持久化数据，保存了整个data tree，视图。
   4. 读请求：
      Client直接读取对应的server节点，由server节点的本地副本直接返回。
      3．写请求：
      Client->ZkServer->Leader->更新投票->半数以上follower修改（先持久化，再存本地内存）
      3．ZAB协议（Zookeeper Atomic Broadcast Protocal）：
      广播模式和恢复模式：
2. 广播模式：
   写流程（两阶段提交）：
   Client->Zkserver(转发请求)->leader(持久化本地，发送提议，广播给followers)->follower(持久化，发送ACK给leader)->Leader(半数以上ack,在本地存储该消息，并广播commit消息)->follower（deliver该消息）->完成事物
3. Zookeeper选举机制：
4. 全新集群选举：
5. 服务器1启动，给自己投票，其他服务器没启动，无法收到反馈信息，服务器状态LOOKING；
6. 服务器2启动，先给自己投票，与1交换结果，服务器1对比结果ID小于服务器2，投票给服务器2，由于2<5/2,两服务器都处于LOOKING状态。
7. 服务器3启动，与1,2交换投票结果，1,2对比ID投票给服务器3，服务器3有票数：3>5/2,服务器3改为LEADING，服务器1,2改为FOLLOWERING
8. 服务器4，先投票给自己，然后交换1,2,3的投票结果，发现服务器3投票较多，则4状态改为FOLLOWERING
9. 同4

二：分布式事务
1．分布式事务：
CAP理论：一致性，可用性，分区容错性；CAP不能同时满足，理解可用性，表示写数据可以立刻访问，一致性理解为强一致性。一般牺牲一致性满足AP，或者牺牲可用性保证强一致性CP,zookeeper偏CP.
BASE理论：基本可用，软状态，最终一致性。
基本可用：出错时，允许部分功能可用。
软状态：不要求强一致性时，允许存在中间状态，保证数据最终一致性。
最终一致性：经过一段时间后，数据最终一致性。
2．分布式事务的解决方案：
1．两阶段提交（2pc）:
准备阶段：事务管理器->参与者->本地事务->写日志
提交阶段:本地事务失败->事务管理器->参与者->回滚->释放锁资源
XA方案：AP,TM,RM;TM与RM通过XA接口规范进行通信保证分布式事务
Seata方案：TC，TM,RM
2．TCC事务：
Try,Confirm,Cancel.每个分支事务实现三个操作：预处理Try,确认Confirm,撤销Cancel。TM发起所以分支事务的try操作，任意一个分支事务try失败，则发起Cancel，当所有Try成功，执行Confirm操作。 （Try,Cancel，Confirm要实现幂等）
3.可靠消息最终一致性：
事务发起->本地事务->发送消息->中间件->参与方接受消息并处理事务
问题点：
本地事务与发送消息的原子性问题；
事务参与方接受消息的可靠性，接受消息失败可以重复接受消息；
消息重复消费问题
处理流程：
1.主动方预发消息至MQ;MQ收到消息后返回确认收到；
2.主动方执行本地事务；
3.若事务执行成功，发送Commit至MQ,MQ对被动方提供数据;若失败，发送RollBack至MQ，MQ删除该数据；
4.MQ若没收到主动方的消息（网络等原因），MQ的消息恢复子系统定时反查本地消息服务（本地消息服务通过查询本地事务是否执行成功），根据事务状态是否删除MQ中消息，保持可靠数据最终一致性。
4.最大努力通知：
发起方通过一定的机制最大努力将业务处理结果通知到接收方。
接收方通知可能没接收到通知，有一定的机制对消息重复通知，接收方主动向通知方查询消息信息满足需求。