Redis主从复制、集群

逃离我推掉我的手 2022-03-01 12:24 239阅读 0赞

## 什么是主从复制（Master/Slave）？ ##

我们的数据一般是存储在数据库中，为了保证数据的高可用，我们一般使用多台数据库服务器做集群。选则其中的一台作为主服务器（Master），其余的作为从服务器（Slave）。Master 上的数据更新后根据配置文件配置的策略，自动同步到 Slave 上，这就是主从复制。

### 主从复制有什么作用？ ###

*   保证了数据的高可用。因为数据在多台服务器上存储了多份，即使一台机器宕掉了，其余的机器还可以顶上。
 *   实现了读写分离。什么叫读写分离？写数据在 Master 上，读数据是在 Slave 上，这就叫读写分离。它缓解了以往 Master 既要处理读数据又要处理写数据的压力，Master 上负责写，Slave 上负责读，大大提升了数据库服务器的性能。
 *  容灾恢复。当主机宕掉了之后，就没有办法向数据库中写数据了，怎么办？其余的 Salve 根据配置的策略，选出一台晋升为 Master，其余的 Slave 成为新 Master 的从机，当原来宕掉的 Master 恢复后，自动成为 Slave，实现了容灾

### 复制命令 ###

*  info replication      查看当前主机是master还是slave（默认为master）。
 *  slaveof  主机的ip  端口号       将当前机器设置为从机。

### Redis 实现主从复制的原理是什么？ ###

知其然还要知其所以然。  
**一、master 复制数据给 slave 的原理如下：**

*  slave 启动成功之后连接到 master 后会发送一个 sync 命令。
 *  master 接收到这个同步命令之后启动后台的存盘进程，即将内存的数据持久化到 rdb 或 aof。
 *  持久化完毕之后，master 将整个数据文件传送给 slave。

**二、slave 接收 master 复制过来的数据方式有两种：**

**    全量复制：**

*  slave 刚与 master 建立连接的时候，会将接收到的 master 发来的整个数据库文件存盘并加载到内存。

**    增量复制：**

*  slave 已经与 master 建立好连接关系的时候，master 会将收集到的修改数据的命令传送给 slave，slave 执行这些命令，完成同步。而不是再一次重新加载整个数据文件到内存。

**当然，如果 slave 与 master 断开连接，再次重连的时候还是要加载整个数据文件的，需要重新slaveof。**

### Redis 的主从复制的缺点 ###

*  当 master 需要同步发送到 slave 上的数据量非常大的时候，会存在一定的时延。
 *  当系统很繁忙或者 slave 机器数量非常多的时候也会使这个问题更加严重。

# 几种模式 #

###  一、一主二仆 ###

一个 Master 两个 slave。

这种模式会遇到一些问题，再次记录一下：

*  slave 在连接 master 之前，master 就已经添加了一些 key，那么 slave 连接进来的时候之前的 key 是否也会复制？

答：全部都会复制，即全量复制。

*  是否可以向 slave 里面写数据？是否可以 set key？

答：不可以，slave 只可以 read，master 既可以 read 又可以 write。

*  主机 shutdown 后从机情况如何？从机是上位（变 master）还是原地待命？

答：原地待命，依旧是 slave，等待 master 上位。

*  主机又回来了后，主机新增记录，从机能否顺利复制？

答：必须能。

*  其中一台 slave 宕机后，再次上线还能跟的上大部队吗？

答：不能，必须再次使用 slaveof host port 命令指定主机才可以继续复制数据。

### 二、薪火相传 ###

*  master 和 slave 之间以链表的形式连接起来，上一个 slave 是下一个 slave 的 master。
 *  这样 master 就多了，可以有效的缓解主 master 的写压力。
 *  如果其中的一个节点宕掉了，后续节点将无法得到之前节点的数据。

### 三、反客为主 ###

*  使用 slaveof no one 命令，将原本的 slave 转成 master，停止与其他数据库的同步。

### 四、哨兵模式 ###

它是[反客为主][Link 1]的自动版，能够在后台自动监控主机是否故障，如果主机故障了，其余的从机会自动进行投票选举，得票数最多的从机将转换为 master。

**Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:**

*  监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
 *  提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
 *  自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

**如何实现哨兵模式**

1.  开启三个 redis 服务：6379，6380，6381。
2.  先让 6379 成为 master，其余两个服务成为它的 slave。
3.  在自定义的 /myconf 目录下新建 sentinel.conf 文件，必须是这个名字。
4.  在里面填写内容：sentinel  monitor  被监控的数据库名字(随意)  192.168.198.130  6379  1 。上面最后一个数字 1，表示 master 宕掉后，slave 投票看让谁接替成为主机，得票数最多的成为主机。
5.  启动哨兵：redis-sentinel   /myconf/sentinel.conf，这个 /myconf 目录根据自己的实际情况进行配置。
6.  这样当我们把 master shutdown 之后，开启的哨兵服务会自动从剩余的两个 slave 投票选出一个当 master，而当原来的 master 上线之后会成为 从机

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]

### 集群 ###

redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做`哈希槽 (hash slot)`的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用`CRC16`算法来取模得到所属的`slot`，然后将这个key 分到哈希槽区间的节点上，具体算法就是：`CRC16(key) % 16384。`

Redis 集群会把数据存在一个 master 节点，然后在这个 master 和其对应的salve 之间进行数据同步。当读取数据时，也根据一致性哈希算法到对应的 master 节点获取数据。只有当一个master 挂掉之后，才会启动一个对应的 salve 节点，充当 master 。

需要注意的是：必须要`3个或以上`的主节点，否则在创建集群时会失败，并且当存活的主节点数小于总节点数的一半时，整个集群就无法提供服务了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1][]

从这种redis cluster的架构图中可以很容易的看出首先将数据根据hash规则分配到6个slot中（这里只是举例子分成了6个槽），然后根据CRC算法和取模算法将6个slot分别存储到3个不同的Master节点中，每个master节点又配套部署了一个slave节点，当一个master出现问题后，slave节点可以顶上。这种cluster的方案对比第一种简单的主从方案的优点在于提高了读写的并发，分散了IO，在保障高可用的前提下提高了性能。

[Link 1]: https://www.baidu.com/s?wd=%E5%8F%8D%E5%AE%A2%E4%B8%BA%E4%B8%BB&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20220301/217a5ad75f7245baaebf40f6a2bc6223.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1]: /images/20220301/7297655669ef4c58bb0db6af737fa5ce.png