type
status
date
slug
summary
tags
category
icon
password
本篇文章我想大家分享下 Redis 的主从机制。Redis 是怎么实现的主从机制，想要实现 Redis 主从机制会存在哪些问题：主从机制怎么保持数据的一致性？主库挂了怎么保持数据数据正常的访问？主从机制很完美吗？如果带着以上的问题我们来 读取这篇文章收获会更加多哦。
创建主从实例
为了更好介绍 Redis 的主从机制，我们首先需要创建实例。俗话说的好：纸上谈兵不如实际的操作（我说的，哈哈）。话不多数直接操作：
首先创建两个 redis 实例：
然后，查询 docker redis-master 的 ip 地址。之后再 redis-slave 上绑定主从关系：
确认是否绑定成功，查看 redis-slave 日志：
执行完以上的命令你就成功的创建了 redis 的主从，接下来我们就具体的讲解下他链接的原理，还有他是怎么保持数据主从一致性的呢？
主从机制怎么保持数据的一致性？
Redis 主从是怎么保持数据一致性，主要是通过主从读写分离来保证数据的一致性。
为什么读写分离能保持数据的一致性？试想如果主从都可以写入数据，那么数据间的流动就变得很乱，谁应该同步谁的数据。这样就无法保证在某一台机器上获取到完整的数据了。
当从机执行了 SLAVEOF 之后发生了什么呢？
首先，从 redis 发送建立主从连接的请求。主 redis 接受到请求后就会执行 bgsave 生成当前主 redis 的 RDB 日志。之后主 redis 会发送自身的节点信息给从 redis。当 RDB 文件生成完毕后，主 redis 会将文件传输给从 redis。从 redis 接收到文件后首先会清除自身的所有数据之后才会加载文件。主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作，最后同步这些数据。这样就一来主从数据库的数据就一致。
主库网络断了恢复之后数据怎么同步？
想要解决上面这个问题那么，我们就需要知道主从同步建立之后他们的数据是怎么同步的？
增量复制，这是一个很巧妙地设计
（这里像 redis 大佬致敬）是怎么完成增量复制的呢？请看下图：
首先有这样一个环形存储结构 repl_backlog_buffer， 新增的命令顺时针的写入这个内存，然后有两个指针会记录主库新增数据写到的位置和从库读取到位置。如果主库网络断了再次恢复从库只需要查看上次读取位置继续读写即可。
主从模式的进阶
当前主从模式是存在一个问题就是：如果一个主 redis 下面存在过多的 从 redis 时候在每次同步数据的时候都需要 fork 一个进程执行 bgsave 命令生成 RDB 文件。如果从 redis 过多就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量同步。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。而且在传输 RDB 文件的时候也会占用带宽，导致正常的请求进不来。
那我们怎么解决这个问题呢？我们采用 主 - 从 - 从 的模式来解决这个问题。什么是主 - 从 - 从 请看下图：
通过以上的 主 - 从 - 从 就将 fork 和 带宽的问题完美的解决了。到这里我们讲解了主从是连接的数据是怎么进行同步的。但是想要保证 redis 的高可用还是远远不够，比如：如果主库挂了从库怎么办，redis 服务还能继续使用吗？本篇文章就不再继续讲解避免贪多嚼不烂，下一篇文章我会详细的讲解如果主库挂了之后怎么能让 redis 服务继续使用。
- Author:iLikeBug
- URL:http://ilikebug.blog/Redis/redis-master-slave
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!