Redis 的高可用之Redis 主从模式

一、何谓高可用

Redis 高可用回答包括两个层面，一个就是数据不能丢失，或者说尽量减少丢失;另外一个就是保证 Redis 服务不中断。

• 对于尽量减少数据丢失，可以通过 AOF 和 RDB 保证。

• 对于保证服务不中断✁话，Redis 就不能单点部署，这时候我们先看下 Redis 主从。

graph TD
A(Redis 高可用) --> B(数据不能丢失,或者说尽量减少丢失)
A(Redis 高可用) --> C(Redis 服务不中断)
B --> D(通过 AOF 保证)
B --> H(通过 RDB 保证)
C --> E(主从模式)
C --> F(哨兵模式)
C --> G(集群模式)

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px
style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px
style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px
style E fill:#98FB98,stroke:#98FB98,stroke-width:2px
style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px
style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px
style H fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

在实际项目中使用 Redis，肯定不会是单点部署 Redis 服务。因为，单点部署一旦宕机，就不可用了。

为了实现高可用，通常做法是，将数据库复制多个副本以部署在不同服务器上，其中一台挂了也可以继续提供服务。

Redis 实现高可用有三种部署模式：主从模式，哨兵模式，集群模式。

本篇文章详细说一下Redis 主从模式。

二、Redis 主从模式

2.1 Redsi 主从概念

Redis 主从复制通过将一个 Redis 服务器（主库）的数据复制到其他 Redis 服务器（从库），以实现数据的冗余备份和读写分离。

• Redis 主从模式，就是部署多台 Redis 服务器，有主库和从库，它们之间通过主从复制，以保证数据副本一致。（++数据同步通过主从复制来实现++）

• 主从库之间采用是读写分离方式，其中++主库负责读操作和写操作++，++从库则负责读操作++。

• 如果 Redis 主库挂了，++在从库中选举出新的主库++。

2.2 Redis 主从复制同步过程

Redis 主从复制可以整理为以下 5 个阶段：

1、主库写操作和命令日志记录阶段：

• 主库持续监听并接收客户端的写操作请求。

• 主库将这些写操作记录在内部的命令日志（command log）中。

flowchart LR
    subgraph 主库写操作和命令日志记录阶段
        A[持续监听并接收写操作请求]
        B[记录写操作到命令日志]
    end

    A --> B

2、从库连接和全量数据同步阶段：

• 从库连接到主库，并发送 SYNC 命令请求全量数据同步。

3、 主库全量数据同步阶段：

• 主库收到 SYNC 请求后，开始执行全量数据同步操作。

• 主库将自己的数据快照（snapshot）发送给从库，并继续将新的写操作记录在命令日志中。

4、从库加载快照和实时数据同步阶段：

• 从库接收到主库的快照后，将其加载到内存中。

• 从库开始接收并执行主库发送的实时写操作命令，以保持与主库的数据一致性。

flowchart LR
    
    subgraph 主从同步
        C[连接主库并发送 SYNC 命令]
        D[接收主库的数据快照]
        E[加载快照到内存]
        F[接收并执行实时写操作]
        Z[定期向主库发送 PING 命令]
    end

    C --> D
    D --> E
    E --> F
    Z -->|存活| C

5、从库健康检测和主库切换阶段：

• 从库定期向主库发送 PING 命令，以检测主库是否存活。

• 如果主库挂掉，从库会尝试连接其他可用的主库。

• 当主库挂掉或重新上线时，从库可以通过选举机制（例如 Sentinel 或 Redis Cluster）选择一个新的主库。

flowchart LR
    
    subgraph 从库健康检测和主库切换阶段
        G[定期向主库发送 PING 命令]
        H[尝试连接其他可用的主库]
        I[选举新的主库]
    end
  
    G -->|挂掉| H
    H --> I

2.3 Redis 主从的一些注意点

因为主从复制是异步进行，如果从库滞后执行，则会导致主从数据不一致。

2.3.1 主从数据不一致一般有什么原因?

graph LR
A(数据不一致原因) ---> E(主从库网路延迟)
A(数据不一致原因) ---> G(从库收到了主从命令,但是它正在执行阻塞性命令-如 hgetall等)

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px
style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

2.3.2 如何解决主从数据不一致问题呢？

graph LR
A(解决办法) ---> B(换更好硬件配置)
A(解决办法) ---> C(保证网络畅通)
A(解决办法) ---> D(监控主从库间复制进度)
A(解决办法) ---> E(读取过期数据)

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px
style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px
style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px
style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

2.3.3 Redis 本身如何保证主从数据一致性？

作为一个高性能的内存缓存数据库，Redis 本身也在保证主从数据同步方面做了很多工作。

graph TD
A(Redis 本身如何保证主从数据一致性) ---> B(全量同步)
A(Redis 本身如何保证主从数据一致性) ---> C(增量同步)
A(Redis 本身如何保证主从数据一致性) ---> D(指令同步)

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px
style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px
style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

全量同步

一般发生在第一次建立主从关系、或者跟主断开时间比较久的场景。

• 它的步骤为：

  • slave向master发起同步指令，master收到以后，会通过bgsave指令生成一个快照RDB文件，同步给slave，slave拿到后，会通过master同步的快照文件进行加载。这个时候，主生成rdb文件时候的所有数据都以及同步给了slave。

  • 但是bgsave指令是不会阻塞其他指令执行的，所以master在生成快照文件时，还是能接收新的指令执行。这些指令master会先保存到一个叫replication_buffer的内存区间，等slave加载完快照文件后会同步。

增量同步

slave发起同步的时候，还会带有上次同步的偏移量，然后跟master的最新的偏移量比较，如果相差的数据在master的积压缓存（一个专门存储master最新数据并且会覆盖的内存区间）能查询到的话，那么只需要把相差的数据同步给slave。

• 分析：为什么需要增量同步？

数据同步，slave是定时会发起的，假如每次同步，都把主的所有数据都进行同步，那么性能会很慢，大部分时候，slave可能只跟master相差一部分数据。那么只需要同步这部分数据。

指令同步

master输入的指令会异步同步给slave。

• 当主库接收到客户端发送的指令后，它会立即执行指令并返回结果给客户端，同时将执行的指令以命令传播（Command Propagation）的方式发送给所有从库。主库并不会等待从库完成指令的执行确认。

• 从库接收到主库发送的指令后，会在后台异步执行这些指令。从库会维护一个复制缓冲区（Replication Buffer），将接收到的指令缓存起来，然后按顺序执行。从库会周期性地向主库发送确认（ACK）信息，通知主库已经成功接收并执行了指令。

• 异步复制的特点是主从库之间的数据同步存在一定的延迟。主库和从库之间的网络延迟、从库的性能等因素都会影响同步的延迟时间。因此，在进行读取操作时，从库的数据可能会稍微滞后于主库。