Redis高可用方案

要做到redis的高可用，可以从以下几个方面实现

1 持久化

Redis持久化定义：redis是一个内存数据库，所以在服务器进程退出之后，redis数据库内的数据就会丢失。持久化就是保证服务重启后依然保证数据不丢失，持久化将redis在内存中的数据通过持久化方式存入磁盘。Redis持久化方式分为两种：RDB持久化和AOF持久化。

1.1 RDB持久化

RDB持久化根据一下方式实现：
配置规则： 在Redis的配置文件 redis.conf中默认配置了redis持久化规则

#
#Save the DB on disk:
#
#save <seconds> <changes>
#
#Will save the DB if both the given number of seconds and the given
#number of write operations against the DB occurred.
#
#In the example below the behaviour will be to save:
#after 900 sec (15 min) if at least 1 key changed
#after 300 sec (5 min) if at least 10 keys changed
#after 60 sec if at least 10000 keys changed
#
#Note: you can disable saving completely by commenting out all "save" lines.
#
#It is also possible to remove all the previously configured save
#points by adding a save directive with a single empty string argument
#like in the following example:
#
#save ""

save 900 1
save 300 10
save 60 10000

save 900 1 规则表示：在900秒内执行了一次redis更新操作则RDB持久化一次。

执行命令： 在手动迁移备份的时候，使用SAVE/BGSAVE命令都可以进行redis磁盘备份。两个命令的区别在于SAVE命令在执行的时候会阻塞所有来自客户端的请求，如果redis内数据较多，持久化时间就会相对较长，这段时间内redis就无法相应客户端请求。BGSAVE 是在后台异步地执行持久化操作，这时候执行该操作同时也能及时相应客户端请求。所以在手动执行redis持久化操作的时候应当尽量避免使用save命令。此外：执行FLUSHALL也会出发自动持久化redis数据库

执行复制： 当Redis使用集群模式，在主从服务器复制时也会进行RDB持久化操作。

1.2 AOF持久化

RDB持久化是在特定配置或者操作执行时才会触发，如果在这些条件触发之前服务中断就可能造成数据丢失。因此AOF持久化操作就可以解决这样的问题：
AOF持久化将每一条写命令追加到硬盘文件当中，在持久化过程中存在一个问题就是如果同一个key，对他更新了很多次，每一次操作AOF持久化都会记录，但是我们需要的只是最后一次的更新。那么对于这种情况下数据的冗余，AOF持久化采用了自动重写AOF文件。，当达到一定条件的时候自动给重写。
AOF持久化 在redis配置中是默认不开启的，可以通过redis配置文件去修改，也可以修改文件名。

appendonly  yes
appendfilename filename 

2 主从复制

功能： 实际生产过程中，单以服务的redis是不可行的，1，当这个机器服务宕机，那么redis作为的服务器也就没有作用了。2，单个机器的机器容量有瓶颈限制。
持久化保证了数据不丢失， 但是如果这个机器硬盘也出现故障，机会造成数据丢失，这对于很多有大量数据的系统来说会造成灾难性后果。所以一般的做法就是将数据库数据复制多个副本，其中一台机器故障也能保证服务的可用性。
主从复制概念： 在Redis使用中，当使用多台服务器。就会将这些服务器分为两类，一类是主数据库，另一类是从数据库，主数据库可以进行读写操作，当对主数据库进行写操作的时候自动将数据同步给从数据库备份。而从数据库一般来说就是只读的，接受主数据库同步传入的数据。主从数据库之间的关系是一对多，即一个主数据库可以拥有多个从数据库，但是一个从数据库只能有一个主数据库。
实现主从数据库的复制只要在从数据库指定是哪一个主数据库的从库即可：

slaveof   amsterip  masterport
slaveof   127.0.0.1  6379

3 集群

**集群，即Redis Cluster，**是Redis 3.0开始引入的分布式存储方案。
集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。

4 哨兵

功能：
1 自动故障转移： 主节点不能正常工作的时候，就会实现自动故障转移，从已经失效的主节点下的从节点当中找出其中一个节点成为新的主节点，并且让其他的节点去复制这个节点。
2.监控： 哨兵会不断地检查主节点和从节点是否运作正常，检查周期1s。
3.通知： 哨兵可以将故障转移的结果发送给客户端。
4.配置提供者： 客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。

每一个数据节点都应该配置一个哨兵节点
哨兵系统的搭建过程，有几点需要注意：
（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
（2）哨兵节点本质上是redis节点。
（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。
（5）本章的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。

哨兵判断节点是否可用将其下线分为主观下线和客观下线
**主观下线：**在定时检测的时候，如果目标节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。
**客观下线：**哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

总结

本文针对redis作为缓存数据库，如何让其实现高可用性做了简单介绍。要实现redis的高可用性，redis提供了，持久化、主从复制、集群、哨兵来让使用redis的服务更加可靠与安全。

参考

《Redis入门指南》
《Redis设计与实现》