mysql、redis、zk、kafka、es可用性 横评（详解在注释里面，图片加载需要时间）
2023-07-05 09:41:42 0 举报AI智能生成
知识要点和原理解析，详细信息和图片均在黄色图标的注释中，鼠标移动到黄色图标上即会显示，图片加载有时较慢。
作者其他创作
大纲/内容
mysql
主从复制
MySQL支持的复制类型
基于语句的复制
基于行的复制
混合类型的复制
复制的工作过程
3个线程
Master的binlog dump线程
Slave的IO线程
Slave的SQL线程
主从复制同步方式
异步复制
同步复制
半同步复制
主从同步延时
原因
解决方案
redis
哨兵模式
组成
哨兵节点
数据节点
工作机制
心跳检查
每隔 10 秒，每个 Sentinel 节点会向已知的主从节点发送 info 命令获取最新的主从架构。
每隔 2 秒，Sentinel 节点都会向主从节点的 _sentinel_:hello 频道发送自己的信息。
每隔一秒，哨兵会每个主从节点、Sentinel 节点发送 PING 命令。该定时任务是哨兵心跳机制中的核心，它涉及到 Redis 数据节点的运行状态监控，哨兵领导者的选举等细节操作。当哨兵节点发送 PING 命令后，若超过 down-after-milliseconds 后，当前哨兵节点会认为该节点主观下线。
主观下线
客观下线
注意
Sentinel 选举
故障转移
哨兵机制下的数据丢失
异步复制同步丢失
集群产生脑裂数据丢失
如何保证尽量少的数据丢失
min-slaves-to-write:从节点最小数量，默认0
min-slaves-max-lag：从节点最大延迟，默认10
解释
集群Cluster模式
数据复制过程和故障转移
数据复制
故障检测
主从故障转移
1、如果只有一个slave节点
2、多个slave节点
3、新的主节点会撤销所有对已下线主节点的slots指派，并将这些slots全部指派给自己
4、新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。
5、新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成
client 访问 数据集群的过程
定位数据所在节点
1、客户端连接任一实例，获取到slots与实例节点的映射关系，并将该映射关系的信息缓存在本地
2、将需要访问的redis信息的key，经过CRC16计算后，再对16384 取模得到对应的 Slot 索引
3、通过slot的位置进一步定位到具体所在的实例，再将请求发送到对应的实例上
zk
高性能高可用
三种角色
Leader(领导者）
Leader在集群中只有一个节点
作用
在ZAB崩溃恢复之后，消息广播之前，进行集群中的数据同步
维持与Follower的心跳，接收Follower请求消息，并据不同的消息类型，进行不同的处理
消息类型
PING消息
REQUEST消息
ACK消息
REVALIDATE消息
Follower（跟随者）
作用
与Leader保持心跳连接
当Leader挂了的时候，经过投票后成为新的leader
向Leader发送请求（PING请求、REQUEST消息、ACK请求、REVALIDATE消息）
处理leader发来的消息与请求
接收Client的请求，如果为写请求，发送给Leader
返回Client请求结果
Observer（观察者）
作用
提高zookeeper集群的读性能
提高伸缩性，同时还不影响吞吐率
Observer不参与投票过程，只同步 leader的状态
Observers 接受客户端的连接，并将写请求转发给 leader节点
四个阶段
选举（election）
两种情况
集群启动期间Leader选举
集群运行期间Leader故障
选举投票规则
根据事务ID（zxid）
zxid相同时看myId
syncLimit时间限制
选举算法
1、每个服务器给自己投票
2、比较投票
3、票数是否过半
步骤总结
发现（discovery）
同步（sync）
广播(Broadcast)
Zab 模式
崩溃恢复
崩溃恢复模式
ZAB的保证
Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。
Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。
针对以上的两个要求，在进行 Leader 选举时，只需要选举出集群中 ZXID 最大的事务 Proposal 即可，这样就可以省去 Leader 服务器检查 Proposal 的提交和丢弃工作了。因为 Leader 服务器的事务是最大的，一切以 Leader 服务器的数据为标准即可。
流程
恢复（Recovery）
数据同步策略
SNAP
DIFF
TRUNC
TRUNC+DIFF
广播模式
kafka
副本同步机制
高可靠性
概念
ISR（In-Sync Replicas）
ISR是AR中的一个子集
高水位
作用主要
定义消息可见性
帮助 kafka 完成副本机制的同步
三种角色
leader 副本
相应 clients 端读写请求的副本
Follower 副本
被动的备注 leader 副本的内容，不能响应 clients 端读写请求
ISR 副本
包含了 leader 副本和所有与 leader 副本保持同步的 Followerer 副本
LEO
HW
图示
repcation机制
ISR机制
ISR (In-Sync Replicas)：副本同步队列
延迟
replica.lag.time.max.ms：延迟时间
replica.lag.max.messages：延迟条数
ISR机制选择
最后选择了时间，去掉消息数差异
replica.lag.time.max.ms理解
follower故障及leader故障
follower故障
leader故障
副本不同的异常情况
如果leader crash时，ISR为空怎么办?
unclean.leader.election
true（默认）
false
控制器组件（Controller）
控制器是如何被选出来的？
启动时选举
leader异常选举
控制器是做什么的？
1、主题管理（创建、删除、增加分区）
2、分区重分配
3、Preferred 领导者选举
4、集群成员管理（新增 Broker、Broker 主动关闭、Broker 宕机）
5、数据服务
控制器保存了什么数据？
这里面比较重要的数据有
所有主题信息
所有 Broker 信息
所有涉及运维任务的分区
控制器故障转移（Failover）
控制器故障转移的过程
epoch防止脑裂
每个和控制器交互的请求都会携带controller_epoch字段
分区Leader的选举
消费组Leader的选举
es
节点发现方式
单播（unicast）
配置
ping
unicast
通俗理解
主要步骤
基于文件
配置
基于文件的发现插件会增强单播主机列表 elasticsearch.yml
示例
选举原理之Bully算法
触发选举的两种情况
当master-eligible（候选master）节点数量小于法定票数
当主节点宕机
选举流程
选举时间点
集群启动初始化
集群的Master崩溃的时候
任何一个节点发现当前集群中的Master节点没有得到n/2 + 1节点认可的时候，触发选举
选举流程图
1、筛选activeMasters列表
从activeMasters列表选举Master节点
2、筛选masterCandidates列表
从masterCandidates列表选举Master节点
选举流程
示例
Elasticsearch编号比较
Master假死
Elasticsearch是如何解决这个问题的呢？
脑裂问题
Elasticsearch脑裂解决方案-Quorum算法
Master更新集群状态时的防护
Master降级
异常检测
1、Master
NodesFaultDetection事件处理
2、非Master
MasterFaultDetection事件处理
ping参数
分片管理
基本概念
主分片（primary shard）
副本分片（replica shard
部署
分片管理官方建议
1、分片大小在 10GB 到 50GB 之间
大分片需要更长的恢复时间
小分片会带来更多的开销并且搜索效率较低
2、每 GB 堆内存 20 个或更少的分片
3. 分配管理小结
避免使用非常大的分片
分片数不是越多越好
分片最大容量限制
当数据量可以合理预测并且变化缓慢时，具有固定时间间隔的基于时间的索引很有效。
跨索引查询
为什么需要跨索引查询
技术限制
技术便利
ES提供两个维度的拆分方式
ES查询示意图：多索引+多分片
跨索引查询应用场景
示例1：实时数据与历史数据业务场景
示例2：大数据平台写数据到Elastic平台
日志
跨索引查询应用方式
直接型
模糊型
计算型
跨索引查询技术原理
索引分片
查询过程
跨索引查询注意事项
索引与分片等价关系
协调节点分离
路由机制
一主多副架构
Primary、Replica 副本同步
0 条评论
下一页
![[ES]vivo Elasticsearch集群 - 可用性-多机房双活架构](https://www.processon.com/chart_image/template/thumb/61570feb1efad4243d43fd04.png?tid=61570feb1efad4243d43fd02)
