

mysql、redis、zk、kafka、es可用性横评（详解在注释里面，图片加载需要时间）

首页  思维导图  详情



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的位置进一步定位到具体所在的实例，再将请求发送到对应的实例上

高性能高可用

三种角色

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

图示

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的选举

节点发现方式

单播（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 副本同步

 Collect

Get Started

hbase - zk

 Collect

Get Started

可用性测试流程

 Collect

Get Started

可用性测试

 Collect

Get Started

甘特图、时间进度、横道图





0 条评论

下一页

mysql、redis、zk、kafka、es可用性 横评（详解在注释里面，图片加载需要时间）

mysql、redis、zk、kafka、es可用性横评（详解在注释里面，图片加载需要时间）