CAP理论
- C一致性:数据在分布式下的多个副本之间数据保持一致性
- A可用性:分布式系统一直处于可用状态
- P分区容错性:分布式系统在任何网络或者单点故障时,仍能对外提供满足一致性和可用性的服务
一个分布式系统,不可能同时满足这三个要求,最多只能满足其中两项,一般就是在A、C之间寻找平衡。
base理论/柔性事务
base理论就是不做强一致性,只保持最终的一致性。
它在事务开始前数据是一致的,数据进行中是非一致的,事务进行后是一致的
XA规范下的2pc(强一致性算法)
优点
- 原理简单、实现方便
缺点
- 同步阻塞。他每次prepare或者commit都会等待ok的返回
- 单点故障。
- 数据有可能不一致。如果提交的时候,当有一个资源挂掉的时候,那么两个资源就会出现数据不一致的问题。
示例
- 引入jar
-
配置xadatasource,下面这一段是关键,具体实现方法可以百度,百度上有很多,这里只说明方式
- 这样就可以实现分布式事务
这种方式的分布式事务缺点
- 必须要使用支持XA协议的datasource数据源
- 因为要同时锁定两个数据库的数据,事务锁定时间大大延长 ------ 现实中数据库性能欠佳
- 跨业务系统的情况下无法实现
XA规范下的3pc
-
第一阶段:CanCommit阶段。这个阶段类似于2PC中的第二个阶段中的Ready阶段,是一种事务询问操作,事务的协调者向所有参与者询问“你们是否可以完成本次事务?”,如果参与者节点认为自身可以完成事务就返回“YES”
-
第二阶段:PreCommit阶段。如果第一阶段所有参与者都返回yes,那么进入第二阶段。此时分布式事务协调者会向所有的参与者节点发送PreCommit请求,参与者收到后开始执行事务操作,并将Undo和Redo信息记录到事务日志中。参与者执行完事务操作后(此时属于未提交事务的状态),会返回yes.
-
第三阶段:DoCommit阶段。第二阶段如果都返回成功,那么就会进入第三阶段,向所有参与者发送docommit命令,参与者开始真正的提交事务,并且返回yes。如果有一个参与者节点未完成PreCommit的反馈或者反馈超时,那么协调者都会向所有的参与者节点发送abort请求,从而中断事务。
与2PC的区别
- 3PC对于协调者(Coordinator)和参与者(Partcipant)都设置了超时时间。当协调者宕机的时候,参与者自身拥有超时机制会在超时后,自动进行本地commit从而进行释放资源。而2pc只有协调者拥有超时时间
优点
- 优化了同步阻塞问题
- 改善了单点故障
缺点
同2pc,他虽然改善了,但是并没有完全解决
TCC两阶段、补偿式事务
它在try的时候,数据库数据就已经正式生效,在confrim阶段是去确认数据是否真正生效,如果没有生效那么会在cancel阶段抵消数据。当try失败,抛出异常的时候,也执行cancel阶段。
ZAB协议
ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性;
ZAB协议两种模式:消息广播和崩溃恢复
消息广播
- Leader 接收到消息请求后,将消息赋予一个全局唯一的 64 位自增 id,叫做:zxid,通过 zxid 的大小比较即可实现因果有序这一特性。
- Leader 通过先进先出队列(通过 TCP 协议来实现,以此实现了全局有序这一特性)将带有 zxid 的消息作为一个提案(proposal)分发给所有 follower。
- 当 follower 接收到 proposal,先将 proposal 写到硬盘,写硬盘成功后再向 leader 回一个 ACK。
- 当 leader 接收到合法数量的 ACKs 后,leader 就向所有 follower 发送 COMMIT 命令,会在本地执行该消息。
- 当 follower 收到消息的 COMMIT 命令时,就会执行该消息
崩溃恢复
- 当领导崩溃之后,每个Server会发出一个投票,第一次都是投自己。投票信息:(myid,ZXID)
- 收集来自各个服务器的投票
- 处理投票并重新投票,处理逻辑:优先比较ZXID,然后比较myid
- 统计投票,只要超过半数的机器接收到同样的投票信息,就可以确定leader
- 改变服务器状态