首页  思维导图  详情

mysql、redis、zk、kafka、es同步机制横

2023-07-05 09:39:48   0  举报





仅支持查看

AI智能生成

为你推荐

查看更多



Kafka

知识要点和原理解析，详细信息和图片均在黄色图标的注释中，鼠标移动到黄色图标上即会显示，图片加载有时较慢。

同步机制

副本同步

存储机制

数据库

作者其他创作

大纲/内容

备份、主备、主主、主从同步

作用

记录的内容是SQL语句原文

优点

缺点

statement

仅需记录哪条数据被修改了

row

基于 STATMENT 和 ROW 两种模式的混合复制

mixed

三种格式

write

fsync

流程：写入binlog、binlog cache、page cache、磁盘日志

由参数sync_binlog控制

write和fsync时机

刷盘时机

binlog

图示

redolog与binlog两阶段提交

基于语句的复制

基于行的复制

混合类型的复制

MySQL支持的复制类型

复制的工作过程

Master的binlog dump线程

Slave的IO线程

Slave的SQL线程

3个线程

异步复制

同步复制

半同步复制

主从复制同步方式

原因

解决方案

主从同步延时

主从复制

mysql

通过RDB + replication_buffer

异常情况

1、从节点与主节点建立连接时进行全量同步

2、主节点与从节点正常运行时的同步

环形数组repl-backlog-buffer

master-repl-offset

slave-repl-offset

实现方式

增量同步

特别注意

默认 1MB

repl_backlog_buffer：复制积压缓冲区

3、主节点与从节点连接断开后又重连时会进行增量同步或全量同步

分类

心跳

数据延迟

读到过期数据

规避全量复制

单一主节点

单一机器

规避复制风暴

注意问题

总结

主从同步

redis

Leader

Follower

Observer

集群角色

选举（election）

发现（discovery）

同步（sync）

广播(Broadcast)

四个阶段

Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。

Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。

针对以上的两个要求，在进行 Leader 选举时，只需要选举出集群中 ZXID 最大的事务 Proposal 即可，这样就可以省去 Leader 服务器检查 Proposal 的提交和丢弃工作了。因为 Leader 服务器的事务是最大的，一切以 Leader 服务器的数据为标准即可。

ZAB的保证

流程

SNAP

DIFF

TRUNC

TRUNC+DIFF

数据同步策略

恢复（Recovery）

崩溃恢复模式

交互图

过程

二阶段提交

请求的按序处理

广播流程图

消息广播模式

高可靠性

AR（Assigned Repllicas）

ISR是AR中的一个子集

ISR（In-Sync Replicas）

OSR（Out-Sync Relipcas）

公式：AR = ISR + OSR

定义消息可见性

帮助 kafka 完成副本机制的同步

作用主要

高水位

相应 clients 端读写请求的副本

leader 副本

被动的备注 leader 副本的内容，不能响应 clients 端读写请求

Follower 副本

包含了 leader 副本和所有与 leader 副本保持同步的 Followerer 副本

ISR 副本

三种角色

LEO

概念

repcation机制

replica.lag.time.max.ms：延迟时间

replica.lag.max.messages：延迟条数

延迟

ISR (In-Sync Replicas)：副本同步队列

最后选择了时间，去掉消息数差异

replica.lag.time.max.ms理解

ISR机制选择

follower故障

leader故障

副本不同的异常情况

follower故障及leader故障

true（默认）

false

unclean.leader.election

如果leader crash时，ISR为空怎么办?

ISR机制

远程副本的主要作用

更新部分

不会更新部分

运行过程中哪些数据会发生变更

高水位更新机制

follower的LEO更新时间

leader端的follower副本的LEO更新时间

follower和leader更新follower的LEO的时间

更新流程图

follower默认每500ms从leader拉取一次数据

leader 副本和 Follower 副本更新流程

1、初始状态

1、Leader 副本处理生产者的逻辑

2、Leader 副本处理 Follower 副本拉取消息的逻辑

3、Follower 副本从 Leader 拉取消息的处理逻辑

经过这一次拉取，我们的 Leader 和 Follower 副本的 LEO 都是 1，各自的高水位依然是0，没有被更新。

2、第一次同步

1、Leader 副本处理 Follower 副本拉取消息的逻辑

2、Follower 副本从 Leader 拉取消息的处理逻辑

至此，一次完整的消息同步周期就结束了。事实上，Kafka 就是利用这样的机制，实现了 Leader 和 Follower 副本之间的同步。

3、第二次同步

副本同步机制举例

更新时机

HW保证消费者消费数据一致性，是否丢数据由ack保证。

HW和LEO更新机制

单纯的多副本可以保证kafka高可用，但是并不能保证kafka数据的不丢失

如果要保证写入kafka的数据不丢失

副本同步过程中一致性保证

推荐采用默认值，即不配置该配置，交由操作系统自行决定何时落盘，以提升性能。

针对 broker 配置

针对 topic 配置

查看 Linux 后台线程执行配置