数据库集群系列（十）：Redis集群模式小结与数据持久化技术的实现

艺帆风顺 发布于 2025-04-02 16 次阅读

写在前面：

redis有三种集群方式：主从复制，哨兵模式和集群。

 一，集群的三种方式

1.1，主从复制

主从复制原理：

  • 从服务器连接主服务器，发送SYNC命令； 

  • 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 

  • 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 

  • 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 

  • 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 

  • 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）

  • 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

初始化完成之后，主从服务器之间会保持缓存区写命令的同步。

主从复制优缺点：

优点：

  • 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

  • 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成

  • Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。

  • Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

  • Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

  • Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

  • 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

  • Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

 1.2，哨兵模式

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

    （1）监控主服务器和从服务器是否正常运行。 
    （2）主服务器出现故障时自动将从服务器转换为主服务器。

 

哨兵的工作方式：

  • 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。

  • 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）

  • 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态

  • 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）

  • 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。

  • 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

  • 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

 哨兵模式的优缺点

优点：

  • 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

  • 主从可以自动切换，系统更健壮，可用性更高。

缺点：

  • Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

1.3，Redis-Cluster集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

 Redis-Cluster采用无中心结构,它的特点如下：

  • 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

  • 节点的fail是通过集群中超过半数的节点检测失效时才生效。

  • 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式：

    在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。一致性哈希算法解决分布式热点问题。

    为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

 

二，持久化

问题：

Redis作为一个键值对内存数据库(NoSQL)，数据都存储在内存当中，在处理客户端请求时，所有操作都在内存当中进行，如下所示：

这样做有什么问题呢？

其实，只要稍微有点计算机基础知识的人都知道，存储在内存当中的数据，只要服务器关机(各种原因引起的)，内存中的数据就会消失了，不仅服务器关机会造成数据消失，Redis服务器守护进程退出，内存中的数据也一样会消失。

对于只把Redis当缓存来用的项目来说，数据消失或许问题不大，重新从数据源把数据加载进来就可以了，但如果直接把用户提交的业务数据存储在Redis当中，把Redis作为数据库来使用，在其放存储重要业务数据，那么Redis的内存数据丢失所造成的影响也许是毁灭性。

为了避免内存中数据丢失，Redis提供了对持久化的支持，我们可以选择不同的方式将数据从内存中保存到硬盘当中，使数据可以持久化保存。

Redis提供了RDB和AOF两种不同的数据持久化方式，下面我们就来详细介绍一下这种不同的持久化方式吧。

2.1，RDB

RDB是一种快照存储持久化方式，具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。

开启RDB持久化方式：

开启RDB持久化方式很简单，客户端可以通过向Redis服务器发送save或bgsave命令让服务器生成rdb文件，或者通过服务器配置文件指定触发RDB条件。

①，save命令

save命令是一个同步操作。

    1. # 同步数据到磁盘上> save
    当客户端向服务器发送save命令请求进行持久化时，服务器会阻塞save命令之后的其他客户端的请求，直到数据同步完成。
    如果数据量太大，同步数据会执行很久，而这期间Redis服务器也无法接收其他请求，所以，最好不要在生产环境使用save命令。
     ②，bgsave
    与save命令不同，bgsave命令是一个异步操作。
      # 异步保存数据集到磁盘上> bgsave
      当客户端发服务发出bgsave命令时，Redis服务器主进程会forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
      所以，与save命令相比，Redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但forks子进程是同步的，所以forks子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
      ③，配置文件
      除了通过客户端发送命令外，还有一种方式，就是在Redis配置文件中的save指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写操作】就开启RDB数据同步。
      例如我们可以在配置文件redis.conf指定如下的选项：
        # 900s内至少达到一条写命令save 900 1# 300s内至少达至10条写命令save 300 10# 60s内至少达到10000条写命令save 60 10000
        之后在启动服务器时加载配置文件。
          # 启动服务器加载配置文件redis-server redis.conf
          这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
          rdb文件
          前面介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：
          1. 生成临时rdb文件，并写入数据。
          2. 完成数据写入，用临时文代替代正式rdb文件。
          3. 删除原来的db文件。
          RDB默认生成的文件名为dump.rdb，当然，我可以通过配置文件进行更加详细配置，比如在单机下启动多个redis服务器进程时，可以通过端口号配置不同的rdb名称，如下所示：
            1. # 是否压缩rdb文件rdbcompression yes# rdb文件的名称dbfilename redis-6379.rdb# rdb文件保存目录dir ~/redis/
            RDB的几个优点
            1. 与AOF方式相比，通过rdb文件恢复数据比较快。
            2. rdb文件非常紧凑，适合于数据备份。
            3. 通过RDB进行数据备，由于使用子进程生成，所以对Redis服务器性能影响较小。
            RDB的几个缺点
            1. 如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。
            2. 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
            3. 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。
            2.2，AOF
            聊完了RDB,来聊聊Redis的另外一个持久化方式：AOF(Append-only file)。
            与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。
            开启AOF持久化方式:
            Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redis.conf文件：
              # 开启aof机制appendonly yes # aof文件名appendfilename "appendonly.aof" # 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或noappendfsync always # 默认不重写aof文件no-appendfsync-on-rewrite no # 保存目录dir ~/redis/
              三种写入策略
              在上面的配置文件中，我们可以通过appendfsync选项指定写入策略,有三个选项 
              ①，always
              客户端的每一个写操作都保存到aof文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
              ②，everysec
              appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s的数据。
              ③，no
              Redis服务器不负责写入aof，而是交由操作系统来处理什么时候写入aof文件。更快，但也是最不安全的选择，不推荐使用。
               
              AOF文件重写
              AOF将客户端的每一个写操作都追加到aof文件末尾，比如对一个key多次执行incr命令，这时候，aof保存每一次命令到aof文件中，aof文件会变得非常大。
                incr num 1incr num 2incr num 3incr num 4incr num 5incr num 6...incr num 100000
                aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
                set num 100000
                aof文件是一个二进制文件，并不是像上面的例子一样，直接保存每个命令，而使用Redis自己的格式，上面只是方便演示。
                 
                两种重写方式
                ①，通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性以，因此默认值为no，不推荐使用。
                  # 默认不重写aof文件no-appendfsync-on-rewrite no
                  ②，客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
                    # 让服务器异步重写追加aof文件命令> bgrewriteaof
                    AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
                    重写aof文件的好处
                    1. 压缩aof文件，减少磁盘占用量。
                    2. 将aof的命令压缩为最小命令集，加快了数据恢复的速度。
                    AOF文件损坏
                    在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
                    1. 备份现在aof文件，以防万一。
                    2. 使用redis-check-aof命令修复aof文件，该命令格式如下：
                      # 修复aof日志文件$ redis-check-aof -fix file.aof
                      重启Redis服务器，加载已经修复的aof文件，恢复数据。
                      AOF的优点
                      AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
                      AOF的缺点
                      1. AOF方式生成的日志文件太大，即使通过AFO重写，文件体积仍然很大。
                      2. 恢复数据的速度比RDB慢。
                      2.3，选择RDB还是AOF呢？
                      通过上面的介绍，我们了解了RDB与AOF各自的优点与缺点，到底要如何选择呢？
                      通过下面的表示，我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。
                      当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
                      小结
                          上面讲了一大堆Redis的持久化机制的知识，其实，如果你只是单纯把Redis作为缓存服务器，那么可以完全不用考虑持久化，但是，在如今的大多数服务器架构中，Redis的单单只是扮演一个缓存服务器的角色，还可以作为数据库，保存我们的业务数据，此时，我们则需要好好了解有关Redis持久化策略的区别与选择。
                        版权声明：本文内容始发于CSDN>作者:EQuaker，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行可。始发链接:https://menard.blog.csdn.net/article/details/121509878?在此特别鸣谢原作者的创作。此篇文章的所有版权归原作者所有，商业转载建议请联系原作者，非商业转载请注明出处。