mysql、redis、zk、kafka、es同步机制横
2023-07-05 09:39:48 0 举报AI智能生成
知识要点和原理解析，详细信息和图片均在黄色图标的注释中，鼠标移动到黄色图标上即会显示，图片加载有时较慢。
作者其他创作
大纲/内容
mysql
binlog
作用
备份、主备、主主、主从同步
三种格式
statement
记录的内容是SQL语句原文
优点
缺点
row
仅需记录哪条数据被修改了
优点
缺点
mixed
基于 STATMENT 和 ROW 两种模式的混合复制
刷盘时机
流程：写入binlog、binlog cache、page cache、磁盘日志
write
fsync
write和fsync时机
由参数sync_binlog控制
0
1
N
redolog与binlog两阶段提交
图示
主从复制
MySQL支持的复制类型
基于语句的复制
基于行的复制
混合类型的复制
复制的工作过程
3个线程
Master的binlog dump线程
Slave的IO线程
Slave的SQL线程
主从复制同步方式
异步复制
同步复制
半同步复制
主从同步延时
原因
解决方案
redis
主从同步
分类
1、从节点与主节点建立连接时进行全量同步
通过RDB + replication_buffer
异常情况
2、主节点与从节点正常运行时的同步
3、主节点与从节点连接断开后又重连时会进行增量同步或全量同步
增量同步
实现方式
环形数组repl-backlog-buffer
master-repl-offset
slave-repl-offset
特别注意
repl_backlog_buffer：复制积压缓冲区
默认 1MB
心跳
注意问题
数据延迟
读到过期数据
规避全量复制
规避复制风暴
单一主节点
单一机器
总结
zk
集群角色
Leader
Follower
Observer
四个阶段
选举（election）
发现（discovery）
同步（sync）
广播(Broadcast)
崩溃恢复模式
ZAB的保证
Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。
Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。
针对以上的两个要求，在进行 Leader 选举时，只需要选举出集群中 ZXID 最大的事务 Proposal 即可，这样就可以省去 Leader 服务器检查 Proposal 的提交和丢弃工作了。因为 Leader 服务器的事务是最大的，一切以 Leader 服务器的数据为标准即可。
流程
恢复（Recovery）
数据同步策略
SNAP
DIFF
TRUNC
TRUNC+DIFF
消息广播模式
二阶段提交
过程
交互图
广播 流程图
请求的按序处理
kafka
副本同步机制
高可靠性
概念
AR（Assigned Repllicas）
ISR（In-Sync Replicas）
ISR是AR中的一个子集
OSR（Out-Sync Relipcas）
公式：AR = ISR + OSR
高水位
作用主要
定义消息可见性
帮助 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
HW和LEO更新机制
高水位更新机制
远程副本的主要作用
运行过程中哪些数据会发生变更
更新部分
不会更新部分
更新时机
follower和leader更新follower的LEO的时间
follower的LEO更新时间
leader端的follower副本的LEO更新时间
leader 副本和 Follower 副本更新流程
更新流程图
follower默认每500ms从leader拉取一次数据
副本同步机制举例
1、初始状态
2、第一次同步
1、Leader 副本处理生产者的逻辑
2、Leader 副本处理 Follower 副本拉取消息的逻辑
3、Follower 副本从 Leader 拉取消息的处理逻辑
经过这一次拉取，我们的 Leader 和 Follower 副本的 LEO 都是 1，各自的高水位依然是0，没有被更新。
3、第二次同步
1、Leader 副本处理 Follower 副本拉取消息的逻辑
2、Follower 副本从 Leader 拉取消息的处理逻辑
至此，一次完整的消息同步周期就结束了。事实上，Kafka 就是利用这样的机制，实现了 Leader 和 Follower 副本之间的同步。
HW保证消费者消费数据一致性，是否丢数据由ack保证。
副本同步过程中一致性保证
单纯的多副本可以保证kafka高可用，但是并不能保证kafka数据的不丢失
如果要保证写入kafka的数据不丢失
拓展：Kafka 日志刷盘机制
推荐采用默认值，即不配置该配置，交由操作系统自行决定何时落盘，以提升性能。
相关配置
针对 broker 配置
针对 topic 配置
查看 Linux 后台线程执行配置
es
整体架构图
分片
Shard - 分片
Primary Shard(主分片）
ES中的shard用来解决节点的容量上限问题,，通过主分片，可以将数据分布到集群内的所有节点之上。
Replication- 副本
作用
1、服务高可用(容灾)
2、扩展性能
对于一个索引，除非重建索引否则不能调整主分片的数目（主分片数, number_of_shards），但可以随时调整replica数(number_of_replicas)。
分片的设定
分片数设置过小
分片数设置过大
ES层面写流程
整体的索引流程
路由规则
目标分片接收数据并refresh
flush
一主多副架构
Primary、Replica 副本同步
0 条评论
下一页
