redis的主从复制、哨兵和集群部署

Redis的主从复制

主从复制引言

实际生产环境下，单机的redis服务器是无法满足实际的生产需求的。

第一，单机的redis服务器很容易发生单点故障，即使redis提供了各种持久化的方法来避免数据的丢失，但是物理上的故障(硬盘损毁等)还是无法完全避免的。

第二，如果对单台机器的性能进行纵向拓展，无论是CPU，内存还是磁盘容量都很容易达到瓶颈，无法满足实际需求。

针对这些问题，redis提供了复制(replication)的功能，通过"主从(一主多从)"和"集群(多主多从)"的方式对redis的服务进行水平扩展,用多台redis服务器共同构建一个高可用的redis服务系统。

搭建步骤

在Redis的主从模型下，主服务器既可以读也可以写，而从服务器原则上只允许读操作。接下来我们讲解一下主从复制的搭建。

1. 克隆2台Redis机器,并编辑redis.conf

   另外2台机器都要编辑绑定ip地址
   bind 0.0.0.0    # 可以被外部访问

2. 主机正常启动,并关闭防火墙

   systemctl stop firewalld
   ​
   redis-server /etc/redis/redis.conf

3. 配置从机,编辑redis.conf

   在 port 6379 后添加如下配置
   slaveof 主机ip  redis端口号，示例如下：
   slaveof 192.168.146.21 6379

4. 启动从机

   redis-server /etc/redis/redis.conf

5. 查看主从信息

   #登录主库
   info replication

Redis的哨兵模式

哨兵模式引言

主从复制解决了数据备份的问题，但是如果主节点宕机，仍需要运维手动进行主从切换。要在主从复制下实现故障恢复的自动化，就需要使用Redis的哨兵(Sentinel)模式。

哨兵是一个独立于数据服务器的进程，用于监控redis数据服务器的状态，当主从模式下最关键的主服务器出现故障时，能够被哨兵自动的察觉。同时哨兵会在剩余的从服务器中"选举"出新的主服务器，达到自动化恢复系统服务的目的。

 

哨兵本身也要考虑单点故障的问题，所以Redis Sentinel一般由3~5个节点组成，这样即使挂了个别哨兵节点，哨兵整体还可以正常工作。

客户端来连接集群时，会首先连接 sentinel，通过 sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 sentinel 要地址，sentinel 会将最新的主节点地址告诉客户端。如此应用程序将无需重启即可自动完成节点切换。

通过如下2图，演示故障切换的过程：

从上图可以看到主节点挂掉了，原先的主从复制也断开了，客户端和损坏的主节点也断开了。从节点被提升为新的主节点，其它从节点开始和新的主节点建立复制关系。客户端通过新的主节点继续进行交互。