# 主从复制 Redis 的复制功能是支持多个数据库之间的数据同步。主数据库可以进行读写操作，当主数据库的数据发生变化时会自动将数据同步到从数据库。从数据库一般是只读的，它会接收主数据库同步过来的数据。一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。 **数据的复制是单向的，只能由主节点到从节点。 Master以写为主，Slave 以读为主。** 默认情况下，每台Redis服务器都是主节点； 且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 ## 作用 1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。 3. 负载均衡衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载 4. 高可用的基础 ## 原理 1. 当启动一个从节点时，它会发送一个`PSYNC`命令给主节点； 2. 如果是从节点**初次连接到主节点，那么会触发一次全量复制**。此时主节点会启动一个后台线程，开始生成一份 RDB 快照文件； 3. 同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， 主节点会将 RDB 文件发送给从节点，**从节点会先将 RDB 文件写入本地磁盘，然后再从本地磁盘加载到内存** 4. 接着主节点会将内存中缓存的写命令发送到从节点，从节点同步这些数据； 5. 如果从节点跟主节点之间网络出现故障，连接断开了，会自动重连，连接之后主节点仅会将部分缺失的数据同步给从节点。 ## 配置 例：开启三个 redis 服务，配置一主二从。端口号分别是 6379、6380、6381 ~~~shell 127.0.0.1:6379> info replication # 查看当前库的信息 # Replication role:master # 角色 master connected_slaves:0 # 没有从机 master_failover_state:no-failover master_replid:9a6cd17bac5608f98698b2ff808f001eeecfdc42 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 ~~~ > 只配置从库，不用配置主库！ ~~~shell # 从机 1 127.0.0.1:6380> slaveof 127.0.0.1 6379 OK 127.0.0.1:6380> info replication # Replication role:slave # 当前角色是从机 master_host:127.0.0.1 # 主机的信息 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 slave_repl_offset:1 master_link_down_since_seconds:jd slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 ------------------------------------------------------------------------------ # 从机 2 127.0.0.1:6380> slaveof 127.0.0.1 6379 ------------------------------------------------------------------------------ # 在主机中查看！ 127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 # 多了从机的配置 slave0:ip=127.0.0.1,port=6380,state=online,offset=0,lag=4 slave1:ip=127.0.0.1,port=6381,state=online,offset=0,lag=1 master_failover_state:no-failover master_replid:d270c363e7eea2ada10075696d6c99c0149a597f master_replid2:0000000000000000000000000000000000000000 master_repl_offset:434 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:434 127.0.0.1:6379> set name 1 OK ------------------------------------------------------------------------------ # 从机查看 127.0.0.1:6380> get name "1" 127.0.0.1:6381> get name "1" ~~~ ### 在配置文件配置 ~~~ replicaof 127.0.0.1 6379 masterauth 123456 # 主服务器密码 ~~~ > 详细配置：https://redis.io/docs/manual/replication/ # 哨兵 Sentinel 主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工 干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题 :-:  客户端连接 Redis 的时候，先连接哨兵，哨兵会告诉客户端 Redis 主节点的地址，然后客户端连接上 redis 并进行后续的操作，当主节点宕机的时候，哨兵监测到主节点宕机，会重新推选出某个表现良好的从节点成为新的主节点，然后通过发布订阅模式通知其他服务器，让他们切换主机。 > 官网详细：https://redis.io/docs/manual/sentinel ## 工作原理 * 每个**Sentinel**以每秒钟一次的频率向它所知道的Master，Slave以及其他 **Sentinel**实例发送一个`PING`命令。 * 如果一个实例距离最后一次有效回复 `PING` 命令的时间超过指定值， 则这个实例会被 **Sentine** 标记为**主观下线**。 * 如果一个 Master 被标记为主观下线，则正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认 Master 是否真正进入主观下线状态 * 当有足够数量的 Sentinel（大于等于配置文件指定值）在指定的时间范围内确认 Master 的确进入了主观下线状态， 则 Master 会被标记为**客观下线** 。若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被解除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。 * 哨兵节点会选举出**哨兵 leader**，负责故障转移的工作。 * **哨兵 leader** 会推选出某个表现良好的从节点成为新的主节点，然后通知其他从节点更新主节点信息。 ## 配置 sentinel.conf ~~~shell sentinel monitor mymaster 127.0.0.1 6379 2 # Redis 监控一个名为*mymaster*的主服务器，该主服务器位于地址 127.0.0.1 和端口 6379，投票机制为 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 ~~~ sentinel monitor <master-group-name> <ip> <port> <quorum> 例如，如果您有 5 个 Sentinel 进程，并且给定主进程的法定人数设置为 2，则会发生以下情况： * 如果两个 Sentinel 同时同意 master 不可访问，则两个 Sentinel 中的一个将尝试启动故障转移。 * 如果总共至少有三个 Sentinel 可达，则故障转移将被授权并实际启动 sentinel <option_name> <master_name> <option_value> * `down-after-milliseconds`是以毫秒为单位的时间，Sentinel 开始认为它已关闭，因此实例不应到达（不回复我们的 PING 或回复错误）。 * `parallel-syncs`设置在故障转移后可以重新配置以同时使用新主服务器的副本数。数字越小，完成故障转移过程所需的时间就越长，但是如果将副本配置为服务旧数据，您可能不希望所有副本同时与主服务器重新同步。虽然复制过程对于副本来说大部分是非阻塞的，但有时它会停止从主服务器加载批量数据。您可能希望通过将此选项设置为值 1 来确保一次只能访问一个副本。 ## 优点 * 主从可以切换，故障可以转移，系统的可用性就会更好 * 哨兵模式就是主从模式的升级，手动到自动，更加健壮！ ## 缺点 * 配置麻烦 # Redis cluster 哨兵模式解决了主从复制不能自动故障转移、达不到高可用的问题，但还是存在主节点的写能力、容量受限于单机配置的问题。而 cluster 模式实现了 Redis 的分布式存储，每个节点存储不同的内容，解决主节点的写能力、容量受限于单机配置的问题 Redis cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用