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