redis高可用是怎么实现的 redis生产环境下的高可用

redis高可用的几种方法

Redis实现高可用相关的技术。它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是：

持久化 持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。

复制 复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

哨兵 在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡；存储能力受到单机的限制。

集群 通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

哨兵机制

具体请参考官网文档：http://www.redis.cn/documentation.html

哨兵是由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器.

Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是Redis官方文档对于哨兵功能的描述：

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移（Automatic Failover）：当主节点不能正常工作时，
哨兵会开始自动故障转移操作，它会将失效主节点的其中一
个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

配置提供者（Configuration Provider）：客户端在初始化时，
通过连接哨兵来获得当前Redis服务的主节点地址。

通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

Redis-cli使用的是Redis提供的底层接口，而客户端则对这些接口、功能进行了封装，以便充分利用哨兵的配置提供者和通知功能。

实验：
server2作为主，server3和server4作为备。上个实验已经做了server2和server3。在此基础上做好server2与server4之间的主从复制。

server4

scp -r redis-5.0.3 root@172.25.0.4:/root#将已经做好的server2的复制一份到server3
 [root@server4 redis-5.0.3]# make install
 [root@server4 redis-5.0.3]# cd utils/
 [root@server4 utils]# ./install_server.sh
 [root@server4 utils]# vim /etc/redis/6379.conf
 [root@server4 utils]#/etc/init.d/redis_6379 restart

在主master的server2中：

写入切换策略：

在/etc/redis/下，编辑vim sentinel.conf

然后将该配置文件复制到其他两台slave的/etc/redis下

在三个redis上分别开启监控：

redis-server /etc/redis/sentinel.conf --sentinel

在server2中重新开启一个shell查看是否成功

replication中可以查看到两台slave的信息，说明哨兵模式成功

测试：

让主机server2宕机，此时主机变为server3