

首页  思维导图  详情



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控制

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

心跳

注意问题

数据延迟

读到过期数据

规避全量复制

规避复制风暴

单一主节点

单一机器

总结

集群角色

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

图示

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 日志刷盘机制

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