分布式一致性
2021-06-19 12:06:49 52 举报AI智能生成
登录查看完整内容
分布式一致性
作者其他创作
大纲/内容
分布式一致性
分布式一致性理论
ACID
Atomicity 原子性
Consitency 一致性
Isolation 隔离性
Durability 持久性
CAP
Consistent 一致性：强调数据正确
Availability 可用性：强调服务可用，但不保证数据正确
Partition Tolerance 分区容错性：强调集群对分区故障的容错能力
BASE
原理
Basic Available 基本可用
延迟响应
系统功能
实现基本可用的手段
流量削峰
体验降级
高清无码大图换成小图
服务降级
过载保护
Soft State 软状态
Eventually Consistent 最终一致性
实现最终一致性的手段
读时修复
写时修复
异步修复
基于消息中间件的最终一致性(消息中间件事务消息机制)
分布式一致性协议
PAXOS
RAFT(强领导者模型)
本质
成员身份
Leader
处理写请求
管理日志复制(同步数据)
发送心跳
Follower
接收和处理来自领导者的消息
等待领导者心跳信息超时的时候，就主动站出来，推荐自己当候选人
Candidate
向其他节点发送请求投票信息，通知其他节点投票，如果赢得了半数以上选票，就晋升为Leader
领导者选举
写数据
GOSSIP
Direct Mail 直接邮寄
Anti-entropy反熵
实现方式
推模式
拉模式
推拉模式
Rumor mongering谣言传播
ZAB
处理全部写请求
处理读请求
响应Leader心跳
参与领导者选举
Observer
不参与选举也不投票的Follower
成员状态
Looking：表明正在选举
Following：表明本节点是Follower节点
Leading：表明自己时Leader节点
Observing：表明自己是Observer节点
节点状态
Election：正在进行选举
Discovery：成员发现状态，确认领导关系
Synchronization：数据同步状态，以Leader节点数据为准，Follower节点修复数据副本的一致性
Broadcast：广播状态，集群各节点正常处理读写请求
Leader 选举
崩溃恢复
成员发现
数据同步
处理读写请求
读请求
与领导者失联的Follower，既不能处理写请求，也不能处理读请求
读请求可以在与Leader保持心跳的Follower上处理，实现的是最终一致性
写请求
写请求只能在领导节点上处理
与Raft协议的对比
ZAB：见贤思齐，相互推荐
Raft：一张选票，先到先得，想要通讯的消息数更少，选举也更快
日志复制
两者相同，都是以领导者的日志为准来实现一致，而且日志必须是连续的，也必须按照顺序提交
读操作和一致性
ZAB：操作的顺序性，读操作最终一致性
Raft：既可提供强一致性，也可以提供最终一致性
写操作
两者相同。写操作必须在Leader节点上处理
其他
Raft设计更为简洁。节点发起选举后，递增任期编号，在选举结束后，广播心跳，直接建立领导者关系，然后向各节点同步日志，来实现数据副本的一致性。
常见集群架构对分布式一致性问题的解决方案
CP集群架构
MySQL 主从同步复制集群
ZooKeeper 集群
Nacos CP模式
Kafka 集群(ack=-1 或 ack = all)
RocketMQ集群(同步刷盘模式)
AP集群架构
MySQL 主从异步复制集群
MySQL 主从半同步复制集群
Redis Cluster集群
Redis 哨兵 + 主从集群
RocketMQ集群(异步刷盘模式)
Eureka Server 集群
Nacos AP 模式
Kafka集群(ack=0 或 ack = 1)
分布式事务协议
两阶段提交协议
第一阶段(prepare)：投票阶段/提交请求阶段
第二阶段(commit)：完成阶段/提交执行阶段
缺陷
协调者单点故障，导致整个系统不可用
响应时间较长
数据不一致
不确定性
三阶段提交协议
目的：解决两阶段提交协议的单点故障问题
第一阶段(CanCommit)
第二阶段(PreCommit)
第三阶段(DoCommit)
协调者超时机制
参与者超时机制
TCC(补偿事务)
Try：预留
Confirm：确定
Cancel：撤销
针对每个操作，都要注册响应的确认和核销操作，导致接口数量增加
对业务侵入性强，维护难度大
Confirm 和 Cancel 失败重试，Confirm和Cancel接口必须实现幂等性
0 条评论
回复 删除
下一页
