作者：leobhao，腾讯CSIG研发工程师。

1. Redis 概览

Redis 和 memcache 的区别，Redis 支持的数据类型应用场景

redis 支持更丰富的数据结构（字符串、哈希、列表、集合、zsets）。 Memcache仅支持键值存储。 redis原生支持集群，但是memcache没有原生集群模式。

2. Redis 单线程模型

redis 单线程处理请求流程

redis使用IO复用机制来处理请求。使用反应堆IO 模型。处理过程如下：

首先，接收来自客户端的套接字请求，并且多路复用器将套接字转发到连接响应处理器。连接响应处理器将AE_READABLE 事件与命令请求处理器（其中套接字事件排队）相关联。命令请求处理处理器从套接字读取指令，在内存中执行它们，并将AE_WRITEABLE 事件与命令响应处理器相关联。命令响应处理器将结果返回到套接字并解除关联。

redis 单线程效率高的原因

非阻塞IO多路复用（流程如上图），I/O多路复用调度事件，事件处理器处理事件（这是一个注册的函数，可以理解为一个函数（事件发生时的动作） ），但是这里派发事件和处理事件实际上是同一个线程，单线程避免了多线程切换。

3. Redis 过期策略

设置密钥有效期。 redis :的删除策略是定时删除+延迟删除。定期删除是指，默认情况下，redis每隔100ms随机选择几个设置了过期事件的key，检查它们是否过期，然后意味着将其删除。如果redis配置了10万个key，设置了过期时间，每隔几百毫秒检查10万个key，那么CPU负载会很高，所以redis会每隔100毫秒检查所有key，而不是检查，而是随机选择一些key进行检查。他们。但是这会导致一些key过期而无法删除，所以采用了惰性删除的方式。这意味着如果检索时发现密钥过期，则会将其删除并且不会返回。结合这两种策略可确保删除过期的密钥。

最大内存驱逐（maxmemory-policy） 如果Redis占用内存过多，则执行内存驱逐。有以下策略：

noeviction: 如果内存不足，无法写入数据，则新的写入操作会直接报错。 allkeys-random: 当内存不足时，一些键会被随机删除。 volatile-lru: 从过期密钥中删除最近最少使用的密钥。

4. Redis 主从模式保证高并发和高可用(哨兵模式)

读写分离

单台Redis服务器QPS在几万到几万范围内，无法承受更高的并发。

读写分离，保证高并发（10W+QPS）。缓存通常支持高并发读，写请求相对较小。采用读写分离架构（一主多从），主站负责接收写请求，数据同步到从站提供读服务。如果遇到瓶颈，只需添加一台从机即可。水平扩展。

主从复制机制

Redis复制机制：

Redis对从节点采用异步复制，从节点在执行复制操作时不会阻塞自身，并使用旧数据集提供服务和复制。完成后，删除旧数据集并加载新数据集。此时，服务将暂停（很短的时间）。如果采用主/从架构，则主设备必须启用持久性。如果master没有启用持久化（rdb和aof都关闭）。如果master崩溃并重新启动，数据将是空的，复制后所有slave数据将丢失。即使使用高可用哨兵机制，在哨兵检测到master故障之前，master也可能会自动重启，从而导致slave无法清除。

主从同步流程

从设备在启动时向主设备发送psync 命令。当master重新连接时，如果master节点是第一次连接master，那么master节点会将丢失的数据复制到slave上。触发副本（完全重新同步）。当您启动完全重新同步时，主服务器会生成一个rdb快照并将客户端命令缓存在内存中。 rdb生成后，slave将其写入磁盘，然后加载到内存中。然后主设备将缓存的命令发送到从设备。

哨兵(sentinal)模式介绍

Sentinel是Redis集群架构的关键组件，主要提供以下功能：

集群监控：监控master和slave是否正常工作。消息通知：如果Redis实例发生故障，Sentinel会发送消息通知故障转移：如果主节点出现故障，会自动切换到：从属；配置中心：如果发生故障转移并且客户端收到新的主地址通知。

哨兵的核心知识：

至少需要三个Sentinel 才能实现高可用性。采用Sentinel+主从的部署架构来保证Redis集群的高可用，但Sentinel不需要持续测试。监控以确保高可用性。

为什么哨兵只有两个节点无法正常工作

假设Sentinel 集群仅部署两个Sentinel 实例（仲裁=1）。

如果master 宕机了，只要s1 和s2 上有哨兵认为master 宕机了，它们就可以进行切换，并且会选择s1 或s2 进行故障转移。此时，必须满足多数意见。所以两个Sentinel的多数是2。如果两个哨兵都在运行，则允许故障转移。如果M1所在的机器宕机了，s1哨兵也会宕机，并且没有多数允许故障转移。即使集群中存在另一台机器R1，也不会发生故障转移。

对于经典的3 个哨兵集群来说，它是：

此时，多数也是2。如果M1所在的机器宕机了，还剩下两个Sentinel，s2和s3，如果它们拥有多数，就可以允许它们进行故障转移。

哨兵核心底层原理

有两种故障情况：sdown 和odown。 sdown 是主观停机时间。也就是说，当哨兵ping master 的时间超过指定的毫秒数时，就会发生这种情况。 is-master-down-after-milli Seconds 被视为主观停机时间。如果在指定时间内收到大多数哨兵，odown 也会认为master 已关闭。这就是客观的停机时间。 Sentinel之间的相互检测：Sentinels在redis中是通过pub/sub实现的。

5. Redis 数据的恢复(Redis 的持久化)

RDB

RDB 原理

Redis 数据库(RDB) 是将特定时刻的内存快照以二进制格式写入磁盘的过程。

RDB有两个方法：save和bgsave:

运行save:会触发Redis持久化，但在RDB持久化完成之前，Redis不会响应其他客户端的命令。 bgsave: bgsave forks() 子进程来执行持久化。总体流程是，子进程创建后，Redis主进程就可以响应其他客户端的请求了。

RDB 配置

除了使用save和bgsave命令触发外，RDB还支持自动触发。

自动触发策略允许您配置Redis在指定时间段内数据发生多次变化时自动运行bgsave命令。在Redis配置文件中配置：

如果Redis数据在m秒内至少发生n次变化，则BGSAVE命令会自动执行。 save m n

RDB 优缺点

RDB :RDB 优点每个数据文件代表特定时间点的Redis 数据总量。该文件可以上传到远程安全存储。定期备份Redis 数据的主动策略。 Redis通过fork出来的主进程的子进程进行磁盘IO来实现持久化。直接基于RDB恢复REID数据速度更快。 RDB 的缺点： 使用RDB 恢复数据时，一些数据会丢失，因为RDB 是每次fork 出子进程时定期生成的快照文件。如果您的数据文件特别大，您可能会受到影响。运行外部服务配置并暂停几秒钟（主进程必须将其内存表复制到子进程；如果实例很大，此复制过程可能会很长）。 latest_fork_usec 表示由于fork 造成的延迟。如果您的RDB比较大，您应该在Redis上运行INFO命令并在非高峰时段进行备份。

AOF

AOF 原理

redis 记录每个写入命令，并以仅追加方式将其写入日志文件。当redis重新启动时，数据集通过重放日志文件来恢复。 （AOF 文件随着时间的推移变得越来越大，因此Redis 提供了重写机制，可以根据内存中当前的数据集构建更小的AOF 文件，并删除旧的、巨大的AOF 文件。） rewrite 压缩日志文件并使用bgrewriteaof 触发重写。 AOF重写后台运行的方式和RDB类似：你fork一个子进程，主进程继续运行服务，子进程进行AOF持久化，数据转储到磁盘。与RDB不同的是，在后台子进程的持久化过程中，主进程会记录该期间的所有数据更改（主进程仍在处理它们），并在后台子进程完成后将它们发布到服务器保存到.aof_rewrite_buf_blocks。 Redis更新缓存添加到AOF文件中，但不可用于RDB持久化。

AOF的工作流程如下：

Redis执行写入命令后，会将命令写入AOF文件内存（write系统调用）。 Redis根据配置的AOF刷新策略（fsync系统调用）将AOF内存数据刷新到磁盘。配置触发重写过程。

AOF 配置

appendonly: 是否启用AOF（是| 否）、appendfsync: 磁盘刷新机制： 始终：主线程在每次写入操作后立即刷新磁盘。该方案占用磁盘IO资源较大，但数据安全性最高。 Everysec：主线程只是写入内存并在每次写入后返回，然后后台线程每秒执行一次磁盘刷新操作（触发fsync 系统调用）。该解决方案对性能的影响相对较小。如果Redis宕机，你将丢失1秒的数据。否：主线程写入内存并在每次内存数据刷新到磁盘时返回。该分辨率由操作系统决定。它对性能的影响最小，但如果Redis宕机，数据丢失取决于操作系统flush的时机。 auto-aof-rewrite-percentage: 当达到aof文件大小相对于之前版本的aof文件大小的百分比时，触发AOF重写。例如，如果auto-aof-rewrite-percentage 选项设置为100，且上一版本aof 文件大小达到100M，则会触发AOF 重写。 min-size：允许的最小AOF 文件大小。如果超过这个大小，则必须重写AOF。 no-appendfsync-on-rewrite: 表示重写时不会进行fsyncd，而是暂时存放在内存中，重写完成后写入。默认为否。

AOF 优缺点

AOF : 的优点是避免数据丢失。通常，AOF 通过后台线程每秒执行一次fsync（强制刷新磁盘页面缓存），从而导致最多一秒的数据被写入。由于它是仅追加方法（顺序追加），因此没有磁盘寻址开销，即使对于大型AOF 文件，性能也非常高。在后台触发重写操作通常不会影响客户端的读写。请创建恢复所需的最小数量的日志，因为它们将在重写期间被压缩）。创建新的日志文件时，旧文件正常写入，新文件创建后新旧日志交换。但是，它可能会影响主线程写入，例如：

当磁盘上的IO 负载非常高时，后台线程在执行AOF fsync 磁盘刷新操作（fsync 系统调用）时被阻塞，而主线程必须将数据写入文件内存（write 系统）。 call），但是此时，由于磁盘负载较高，后台子线程会阻塞fsync，而当主线程执行write系统调用时，就会阻塞，直到后台线程的fsync完成。然后主线程执行写入并恢复正常。此时主线程无法响应客户端请求，这可能会导致你客户端的Redis请求超时。具体类似于： https://blog.csdn.net/mmgithub123/article/details/124507846。

AOF 日志文件以非常可读的方式记录。此功能适用于致命操作错误的紧急恢复，例如当您不小心使用Flash All清除所有数据时。只要不发生重写，就可以立即复制AOF 并刷新最后的数据。删除flashall命令并重放AOF以恢复数据。 AOF的缺点：对于相同的数据，AOF记录的命令比RDB快照文件大。当AOF开启时，支持写入的QPS低于RDB支持写入的QPS。将操作写入磁盘。

总结

如何在AOF 和RDB 之间进行选择的摘要：同时使用两者并将AOF 配置为每秒fsync 一次。 RDB用作冷备份，如果AOF文件损坏或不可用，AOF可以作为恢复的首选，以避免数据丢失。 RDB 还可以用于快速恢复。

6. Redis 集群模式(redis cluster)

主从部署模式提供了一定的高并发并保证了高可用性，但有以下限制：

主数据与从数据完全相同。主数据量成为集群瓶颈，Redis集群的写入能力也受到主节点单机限制。较高版本的Redis 原生支持集群模式，允许您部署多个主服务器和多个从服务器来水平扩展Redis 集群的功能。 Redis集群支持N个主节点，每个主节点可以挂载多个从节点。

redis cluster 介绍

自动对数据进行切片，并将一部分数据放置在每个母版上。它提供内置的高可用性支持，即使某些主节点不可用也能正常工作。每个Redis 必须打开两个端口（6379 和10000+）。端口（例如，16379）。 16379 用于使用集群总线的节点之间的通信。集群总线用于故障检测、配置更新和故障转移授权。

redis cluster 负载均衡

redis集群采用一致性哈希+虚拟节点进行负载均衡。 Redis 集群有固定的16384 个槽（2^14）来计算，并且有16384 个固定每个键的CRC16 值。您可以获得每个键的插槽。 Redis 集群中的每个主节点都拥有多个插槽。例如，如果您有3 个master，则每个master 拥有超过5,000 个槽位。哈希槽使得添加和删除节点变得非常容易，并且当添加主节点时，其他主节点的槽被分配给其他主节点。这使得集群扩展的成本非常低。

cluster 基础通信原理(gossip 协议)

与集中式集群（例如使用Zookeeper 进行分布式协调注册的集群）不同，Redis 集群使用gossip 协议进行通信。它们不是将集群元数据存储在特定节点上，而是不断地相互通信以保持集群范围内的元数据完整。 Gossip 协议中的每个节点都维护元数据的副本，并且随着各个节点的元数据发生变化，元数据会不断发送到其他节点，以便其他节点也可以更改其元数据。

集中化的优点：元数据的读取和更新非常及时。当元数据发生变化时，它会更新到集中存储，这会给元数据存储带来压力。

闲话：元数据更新延迟，减轻元数据负担。缺点是元数据更新可能会导致集群操作出现一些延迟。

redis cluster 主备切换与高可用

确定节点停机时间：如果一个节点认为另一个节点已停机，则为pfail（主观停机时间）。如果多个节点判定某个节点宕机，则属于故障，客观宕机。原理与Sentinel相同。如果主节点宕机，则选择其中一个从节点切换到主节点，并且在重新启动之前，运行过滤器并检查每个从节点与主节点之间的断开时间。集群节点超时* 无法切换为主节点，因为已超过集群从节点有效性因子。从节点选择：每个从节点根据从主节点复制的数据的偏移量来设置其选择时间。偏移量越大，选举时间越接近从节点。在此之前，当主节点开始投票选举从节点时，大多数主节点（n/2+1）投票给特定的从节点。 zk，选举时间与epochid类似）；整个过程与Sentinel类似，而且Redis集群集成了Sentinel的特性，可以说更加强大。与Redis集群部署、Redis机器配置、机器数量相关的问题。机器标准：8核+32G集群： 5个master+5个slave（每个master有一个slave）效果是：能达到多少Qps？每台机器的峰值约为每秒5W，最大为5W。每个主节点都有一个25W 从节点，如果任何节点挂掉，可以切换到主节点进行故障转移。在哨兵模式下，master 上安装了三个从站。当主节点由于网络抖动而被哨兵认为宕机时，就会执行失败。

转移，从 slave 里面选取了一个作为新的 master，这个时候老的 master 又恢复了，刚好又有 client 连的还是老的 master，就会产生脑裂，数据也会不一致，比如 incr 全局 id 也会重复。redis 对此的解决方案是：min-slaves-to-write 1 至少有一个 slave 连接 min-slaves-max-lag 10 slave 与 master 主从复制延迟时间如果连接到 master 的 slave 数小于最少 slave 的数量，并且主从复制延迟时间超过配置时间，master 就拒绝写入 12。client 连接 redis 多 tcp 连接的考量首先 redis server 虽然是单线程来处理请求， 但是他是多路复用的， 单 tcp 连接肯定是没有多 tcp 连接性能好， 多路复用一个 io 周期得到的就绪 io 事件越多， 处理的就越多。这也不是绝对的， 如果使用 pipeline 的方式传输， 单连接会比多连接性能好， 因为每一个 pipeline 的单次请求过多也会导致单周期到的命令太多， 性能下降多少个连接比较合适这个问题， redis cluser 控制在每个节点 100 个连接以内。 版权声明：本文转载于今日头条，版权归作者所有，如果侵权，请联系本站编辑删除