010.Redis 主从架构搭建及原理详解

在redis主从架构中，Master节点负责处理写请求，Slave节点只处理读请求。对于写请求少，读请求多的场景，例如电商详情页，通过这种读写分离的 *** 作可以大幅提高并发量，通过增加redis从节点的数量可以使得redis的QPS达到10W+。

Master节点接收到写请求并处理后，需要告知Slave节点数据发生了改变，保持主从节点数据一致的行为称为主从同步，所有的Slave都和Master通信去同步数据也会加大Master节点的负担，实际上，除了主从同步，redis也可以从从同步，我们在这里统一描述为主从同步。

redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了 (偏移量，这是redis-28之后才有的特性)。从节点同步数据的时候不会影响主节点的正常工作，也不会影响自己对外提供读服务的功能，从节点会用旧的数据来提供服务，当同步完成后，需要删除旧数据集，加载新数据，这个时候才会暂停对外服务。

因为内存的 buffer 是有限的，所以 redis 主节点不能将所有的指令都记录在内存 buffer 中。redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满

了，就会从头开始覆盖前面的内容。

如果节点间网络通信不好，那么当从节点同步的速度不如主节点接收新写请求的速度时，buffer 中会丢失一部分指令，从节点中的数据将与主节点中的数据不一致，此时将会触发快照同步。

快照同步是一个非常耗费资源的 *** 作，它首先需要在主节点上进行一次 bgsave 将当前内存的数据全部快照到RDB文件中，然后再将快照文件的内容全部传送到从节点。从节点将RDB文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以需要配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。

主节点在进行快照同步时，会进行大量的文件 IO *** 作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync *** 作时如果发生快照复制，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。

从 Redis 2818 版开始支持无盘复制。所谓无盘复制是主节点会一边遍历内存，一遍将序列化的内容发送到从节点，而不是生成完整的 RDB 文件后才进行 IO 传输从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

(1) 在从节点的配置文件中的 slaveof 配置项中配置了主节点的IP和port后，从节点就知道自己要和那个主节点进行连接了。

(2) 从节点内部有个定时任务，会每秒检查自己要连接的主节点是否上线，如果发现了主节点上线，就跟主节点进行网络连接。注意，此时仅仅是取得连接，还没有进行主从数据同步。

(3) 从节点发送ping命令给主节点进行连接，如果设置了口令认证（主节点设置了requirepass），那么从节点必须发送正确的口令（masterauth）进行认证。

(4) 主从节点连接成功后，主从节点进行一次快照同步。事实上，是否进行快照同步需要判断主节点的 run id ，当从节点发现已经连接过某个 run id 的主节点，那么视此次连接为重新连接，就不会进行快照同步。相同IP和port的主节点每次重启服务都会生成一个新的 run id ，所以每次主节点重启服务都会进行一次快照同步，如果想重启主节点服务而不改变 run id ，使用 redis-cli debug reload 命令。

(5) 当开始进行快照同步后，主节点在本地生成一份rdb快照文件，并将这个rdb文件发送给从节点，如果复制时间超过60秒（配置项：repl-timeout），那么就会认为复制失败，如果数据量比较大，要适当调大这个参数的值。主从节点进行快照同步的时候，主节点会把接收到的新请求命令写在缓存 buffer 中，当快照同步完成后，再把 buffer 中的指令增量同步到从节点。如果在快照同步期间，内存缓冲区大小超过256MB，或者超过64MB的状态持续时间超过60s（配置项： client-output-buffer-limit slave 256MB 64MB 60 ），那么也会认为快照同步失败。

(6) 从节点接收到RDB文件之后，清空自己的旧数据，然后重新加载RDB到自己的内存中，在这个过程中基于旧的数据对外提供服务。如果主节点开启了AOF，那么在快照同步结束后会立即执行BGREWRITEAOF，重写AOF文件。

(7) 主节点维护了一个backlog文件，默认是1MB大小，主节点向从节点发送全量数据（RDB文件）时，也会同步往backlog中写，这样当发送全量数据这个过程意外中断后，从backlog文件中可以得知数据有哪些是发送成功了，哪些还没有发送，然后当主从节点再次连接后，从失败的地方开始增量同步。这里需要注意的是，当快照同步连接中断后，主从节点再次连接并非是第一次连接，所以进行增量同步，而不是继续进行快照同步。

(8) 快照同步完成后，主节点后续接收到写请求导致数据变化后，将和从节点进行增量同步，遇到 buffer 溢出则再触发快照同步。

(9) 主从节点都会维护一个offset，随着主节点的数据变化以及主从同步的进行，主从节点会不断累加自己维护的offset，从节点每秒都会上报自己的offset给主节点，主节点也会保存每个从节点的offset，这样主从节点就能知道互相之间的数据一致性情况。从节点发送 psync runid offset 命令给主节点从而开始主从同步，主节点会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制。

(10) 主从节点因为网络原因导致断开，当网络接通后，不需要手工干预，可以自动重新连接。

(11) 主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。

(12) 从节点不会处理过期key，当主节点处理了一个过期key，会模拟一条del命令发送给从节点。

(13) 主从节点会保持心跳来检测对方是否在线，主节点默认每隔10秒发送一次heartbeat，从节点默认每隔1秒发送一个heartbeat。

(14) 建议在主节点使用AOF+RDB的持久化方式，并且在主节点定期备份RDB文件，而从节点不要开启AOF机制，原因有两个，一是从节点AOF会降低性能，二是如果主节点数据丢失，主节点数据同步给从节点后，从节点收到了空的数据，如果开启了AOF，会生成空的AOF文件，基于AOF恢复数据后，全部数据就都丢失了，而如果不开启AOF机制，从节点启动后，基于自身的RDB文件恢复数据，这样不至于丢失全部数据。RDB和AOF机制可以参考 详解 redis-4x 持久化机制

使用3个虚拟机搭建一主二从的redis主从架构集群。首先参考 redis-4012单节点安装 在每台机器上安装redis，然后修改redis配置文件，其中一个master节点的配置如下（未列出的保持默认即可）：

两个slave节点的配置如下：

启动3个redis服务：

查看master日志：

看日志发现一个问题，我们在原理中介绍说：

主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。

然而这里master的日志显示写了两次RDB文件，这里我查一些资料再来更新。（！！！待完善）

查看slave日志（这里只列出一个slave的日志）：

测试主从架构：

(1) 使用 redis-cli 访问3个redis服务

(2) 在 master 节点上 set 一个数据

(3) 从节点上获取数据

(4) 尝试在slave上写入数据

redis主从架构搭建成功！

wait 提供两个参数，第一个参数是从节点的数量 m，第二个参数是时间 t，以毫秒

为单位。它表示等待 wait 指令之前的所有写 *** 作同步到 n 个子节点 (也就是确保

m 个子节点的同步没有滞后)，最多等待时间 t。如果时间 t=0，表示无限等待直到

N 个从库同步完成达成一致。

假设此时某个子节点与主节点网络断开，wait 指令第二个参数时间 t = 0，主从同步无法继续

进行，wait 指令会永远阻塞，redis 服务器将丧失可用性。

当同时满足以下条件时，使用ziplist编码：

SpringBoot—实现n秒内出现x个异常报警

思路：

借助Redis的zSet集合，score存储的是异常时的时间戳，获取一定时间范围内的set集合。判断set个数是否满足条件，若满足条件则触发报警；

注意点：

相关API：

Redis实现延迟队列方法介绍

基于Redis实现DelayQueue延迟队列设计方案

相关API：

SpringBoot2x—使用Redis的bitmap实现布隆过滤器（Guava中BF算法）

布隆过滤器： 是专门用来检测集合中是否存在特定元素的数据结构。

存在误差率： 即将不在集合的元素误判在集合中。

所以布隆过滤器适合查询准确度要求没这么苛刻，但是对时间、空间效率比较高的场景。

实现方式：Redis实现布隆过滤器——借鉴Guava的BF算法：

SpringBoot2x中使用Redis的bitmap结构（工具类）

注意：bitmap使用存在风险，若仅仅计算hash值，会导致bitmap占用空间过大。一般需要对hash值进行取余处理。

根据Redis是否存在key，判断锁是否被获取；

锁应该是一个对象，记录持有锁的线程信息、当前重入次数。所以应该使用Redis的Hash结构来存储锁对象。

31 网络波动造成释放锁失败怎么解决？

需要为锁加上超时时间；

32 任务未执行完毕时，锁由于超时时间被释放？

线程一旦加锁成功，可以启动一个后台线程，每隔多少秒检查一次，如果线程还持有锁，可以不断延长锁的生存时间。

主从切换时，从服务器上没有加锁信息，导致多个客户端同时加锁。

list结构底层是ziplist/quicklist（可看着一个双端队列）。常用命令：

使用list作为对象的缓存池。通过rpush放入对象，通过lpop取出对象。

若是阻塞取，可以使用blpop命令实现。

Redis和Lua脚本(实现令牌桶限流)

数据结构选择hash。

hash里面维护：最后放入令牌时间、当前桶内令牌量、桶内最大数量、令牌放置速度（元数据）。

被动式维护：

命令：incr原子累加；

对一段固定时间窗口内的请求进行计数，如果请求数超过了阈值，则舍弃该请求；如果没有达到设定的阈值，则接受该请求，且计数加1。当窗口时间结束，重置计数器为0。

优点：实现简单，容易理解；

缺点：流量曲线可能不够平滑，有“突刺现象”。

1 一段时间内（不超过时间窗口）系统服务不可用。 比如窗口大小1s，限流为100，恰好某个窗口第1ms来了100个请求，然后2ms-999ms请求都会被拒绝。这段时间用户会感觉系统服务不可用（即不够平滑）。

2 窗口切换时可能会出现两倍于阈值流量的请求。 比如窗口大小1s，限流大小100，然后在某个窗口的第999ms有100个请求，窗口前期没有请求。所以这100个请求都会通过。然后下一个窗口的第1ms又来100个请求，然后全部通过。其实也是1ms内通过的200个请求。

命令：Redis的incr命令

是对固定窗口计数器的优化，解决的是切换窗口两倍阈值流量的场景。

具体解决方案是：将限流窗口分为多个小的限流窗口，各个限流窗口分别计数。当前时间大于窗口最大时间时，将头部的小窗口数据舍弃，尾部新增小窗口来处理新请求。

优点：本质上是对固定窗口的优化

阿里云、腾讯云云数据库Redis版有256个DB，从DB0到DB255。

数据库是由一个整数索引标识，而不是由一个数据库名称。默认情况下，一个客户端连接到数据库0。

每个数据库都有属于自己的空间，不必担心之间的key冲突。

每个DB没有单独的内存占用量限制，DB可以使用的内存容量受Redis实例的总内存限制。

您可以使用SELECT命令在不同DB之间切换。

需求:

开发一个风控系统，系统包括, 规则引擎和计算引擎, 主要的内容如下:

1 规则的增删改和实时生效, 规则的分类执行

2 按照一定的纬度计算累计值，比如按照 IP, 用户 id, 账户 等纬度。

3 需要支持滑动窗口，滚动窗口，长度窗口等

遇到的问题主要有以下几点:

1 redis 做流计算太过勉强，一是根据业务上的需求，需要统计的key 至少有几亿个，最多也有几十亿个，另外redis 中需要存储少量的交易的信息。估算下来量也是非常可观

2 redis 中 hot key 特别明显，比如按照商户的纬度去统计，如果不对商户的key 进行拆封，像盒马那种流量的商户，对redis 的压力是非常大的。

我们采用的是redis 的cluster 模式，这样的话redis hot key 对redis 影响会更大。对其进行拆分是非常必要的，比如 按照小时拆分。 

3 流式计算中，一个是乱序导致累加的计算不准确(有负值)，另外一个是消息延迟 当时我们尝试使用flink 中的水印的概念去解决问题，发现并不适合。这个坑也是我们实践过后才发现的。

最痛苦的经历是乱序和延迟消息的解决，现在是采取纠正的方式解决。

规则引擎

规则引擎我们选用了drools，简单的探索了drools core, drools DRL, drools CEP 等，但是回头看看，针对drools的使用缺点还是很多, 而且很明显，暂时还没有替换的打算 

1 使用 drools CEP 如何做分布式 我们发现drools CEP中的几种窗口都是内存计算的，应用到分布式中就没有很好的办法，几乎做不到，除非drools 也去集成redis等这种分布式缓存。

2 使用drools 觉得很笨重，因为依赖比较多，二是我们只用到了 drools 中的 if else 等判断，许多其它的功能基本就用不到，因为 1 中解决不了分布式的问题。所以从这点来说drools 已经废了，根本不用在创建kiesession 这种 重量级的东西。

3 drools中支持的运算符不是特别充分，比如像 log 运算，sum, max, avg 这种的运算等都是不支持的 DRL 语言对业务人员来说不是非常的友好。

4 另外drools 中的 连续，非连续的规则，没有看出来如何配置，至少flink cep 是有这样API的。

综上所描述，不得不吐槽下 drools真是无语，也许了解的很简单，还有别的方式，另外drools workbench 也是很无语，很复杂，估计drools 厂商想通过这种方式挣钱。

总体感觉，如果有别的选择，最好不要选用drools，分布式的问题没有解决，就等于废了，因为各种分布式窗口都需要我们自己去实现。怎么办呢 

规则引擎最后还是采用了drools，根据具体的业务含义创建不同的kiesession,  drools 起到了if else 判断的作用，至于滚动窗口，长度窗口和滑动窗口都通过redis来做计算。遇到头疼的问题，是

1 根据不同的统计纬度，大概计算了下，需要几十亿个key，在redis 中做计算

2 滑动窗口暂时靠 redis的zsort 的数据结构，性能不是非常好

3 热点key 的问题，特别对于大商户的热点key 的问题，需要做拆分，拆分起来是比较复杂的

4 消息延迟和消息乱序问题。

所以计算引擎的需求一般是

1 计算很快，大几百个规则，能够很快的计算出准确的结果来

2 计算准确率，当面对乱序和延迟消息的时候，如何计算的更加准确

3 计算的量的问题，正如前面提到的，几十亿个key，另外还需要存储一些信息，计算的中间状态等，如何在redis 中丢失，就会造成计算不准确。

基于以上的问题，关键是如何做的更好，优化的更好，说实话，我没有找到答案，可以做的就是不断的优化redis 计算(暂时不能上大数据，比如flink， spark 等)，减少redis 的 *** 作带来的网络开销。

其实最后还要提一下，如果能采用内存计算，不用分布式计算，会不会速度更快点，比如根据业务来做分片，这样在各个实例统计的中间值就不用汇总，那么每个实例只需要内存计算就好，不需要访问redis而带来的网络开销。但是这样做也会带来架构层面的调整，比如 如何做 fault tolerance， 如何做 状态持久化, 等一系列的问题。 

从使用redis结果来看，效果也不是那么差，不考虑非常热点key 的情况下，最高tps 也达到6000多(2 台机器，16core，32G 内存), 一般公司的业务其实是可以满足的，对于非常热点的key，后续的优化是继续拆分

一个好的风控系统是非常难的，做以笔记，以希望不断成长

以上就是关于010.Redis 主从架构搭建及原理详解全部的内容，包括:010.Redis 主从架构搭建及原理详解、Redis使用bitmap、zset、hash、list等结构完成骚 *** 作、redisdb容量使用情况等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！