Redis的高可用(HA)

本文参考 [https://www.jianshu.com/p/501c9c3b1b36] [https://www.jianshu.com/p/3b9054d3894b]

八大特性

1.速度快

正常情况下，Redis执行命令的速度非常快，官方给出的数字是读写性能可以达到10万/秒，当然这也取决于机器的性能，但这里先不讨论机器性能上的差异，只分析一下是什么造就了Redis除此之快的速度，可以大致归纳为以下三点：
• Redis的所有数据都是存放在内存中的，所以把数据放在内存中是Redis速度快的最主要原因。
• Redis是用C语言实现的，一般来说C语言实现的程序“距离”操作系统更近，执行速度相对会更快。
• Redis使用了单线程架构，预防了多线程可能产生的竞争问题。

2.基于键值对的数据结构服务器

几乎所有的编程语言都提供了类似字典的功能，例如Java里的map、Python里的dict，类似于这种组织数据的方式叫作基于键值的方式，与很多键值对数据库不同的是，Redis中的值不仅可以是字符串，而且还可以是具体的数据结构，这样不仅能便于在许多应用场景的开发，同时也能够提高开发效率。Redis的全称是REmote Dictionary Server，它主要提供了5种数据结构：字符串、哈希、列表、集合、有序集合。

3.丰富的功能

除了5种数据结构，Redis还提供了许多额外的功能：
• 提供了键过期功能，可以用来实现缓存。
• 提供了发布订阅功能，可以用来实现消息系统。
• 支持Lua脚本功能，可以利用Lua创造出新的Redis命令。
• 提供了简单的事务功能，能在一定程度上保证事务特性。
• 提供了流水线（Pipeline）功能，这样客户端能将一批命令一次性传到Redis，减少了网络的开销。

4.简单稳定

Redis的简单主要表现在三个方面。
• Redis的源码很少。
• Redis使用单线程模型，这样不仅使得Redis服务端处理模型变得简单，而且也使得客户端开发变得简单。
• Redis不需要依赖于操作系统中的类库（例如Memcache需要依赖libevent这样的系统类库），Redis自己实现了事件处理的相关功能。
Redis虽然很简单，但是不代表它不稳定。维护的上千个Redis为例，没有出现过因为Redis自身bug而宕掉的情况。

5.客户端语言多

Redis提供了简单的TCP通信协议，很多编程语言可以很方便地接入到Redis，并且由于Redis受到社区和各大公司的广泛认可，所以支持Redis的客户端语言也非常多，几乎涵盖了主流的编程语言，例如Java、PHP、Python、C、C++、Nodejs等。

6.持久化

通常看，将数据放在内存中是不安全的，一旦发生断电或者机器故障，重要的数据可能就会丢失，因此Redis提供了两种持久化方式：RDB和AOF，即可以用两种策略将内存的数据保存到硬盘中（如图所示）这样就保证了数据的可持久性。

RDB和AOF两种持久化的区别 
• RDB：原理是将Redis在内存中的数据库记录定时dump到磁盘的RDB持久化。   
• AOF：原理是将Redis的操作日志以追加的方式写入文件。   
RDB持久化是值在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。   
AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

7.主从复制

Redis提供了复制功能，实现了多个相同数据的Redis副本（如图所示），复制功能是分布式Redis的基础。

8.高可用和分布式

Redis从2.8版本正式提供了高可用实现Redis Sentinel，它能够保证Redis节点的故障发现和故障自动转移。Redis从3.0版本正式提供了分布式实现Redis Cluster，它是Redis真正的分布式实现，提供了高可用、读写和容量的扩展性。

高可用

一、Redis单实例

当系统中只运行一台Redis实例时，一旦该redis挂了，必然会导致系统不可用。

二、Redis主从同步(备份)

主从备份，即主服务器与从服务器之间数据备份的问题。Redis 支持简单且易用的主从复制（master-slave replication）功能， 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。
但是Redis配置主从同步，当redis master节点挂掉之后，slave节点只能提供只读服务，无法提供写服务，所以还需要想办法实现当主redis挂了之后，让从redis(slave节点)升级为主redis(主节点)。这里提到一个概念，自动故障转移，redis sentinel带有这个功能，当一个主redis(master节点)不能提供服务时，redis sentinel可以将一个从redis(slave节点)升级为主redis(master节点)，并对其他从redis(slave节点)进行配置，让它们使用新的主redis(master节点)进行复制备份。

主从备份的特点

• （1）一个主服务器可以有多个从服务器。
• （2）不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器。
• （3）Redis 支持异步复制和部分复制（这两个特性从Redis 2.8开始），主从复制过程不会阻塞主服务器和从服务器。
• （4）主从复制功能可以提升系统的伸缩性和功能，如让多个从服务器处理只读命令，使用复制功能来让主服务器免于频繁的执行持久化操作。

三、主从备份方案 Redis sentinel(哨兵模式方案)

哨兵的含义就是监控redis系统的运行状态。可以启动多个哨兵，去监控redis数据库的运行状态。其主要功能有两点:
• a、监控所有节点数据库是否在正常运行。
• b、master数据库出现故障时，可以自动通过投票机制，从slave节点中选举新的master，实现将从数据库转换为主数据库的自动切换。
在一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健。此时，不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会相互监控。在这里，建议大家哨兵至少部署3个，并且使用奇数个哨兵(奇数个哨兵是因为在决定中可以避免正反对等的结果出现)。
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节点。
哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master节点是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave节点作为新的Master节点。
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master节点、slave节点定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为 宕机 ” Subjective Down,简称sdown)。
若“哨兵群”中的多数sentinel,都报告某一master节点没响应,系统才认为该master节点"彻底死亡"(即:客观上的真正down机),通过一定的vote算法,从剩下的slave节点中,选一台提升为master节点,然后自动修改相关配置。
监控
sentinel会每秒一次的频率与之前创建了命令连接的实例发送PING，包括主服务器、从服务器和sentinel实例，以此来判断当前实例的状态。down-after-milliseconds时间内PING连接无效，则将该实例视为主观下线。之后该sentinel会向其他监控同一主服务器的sentinel实例询问是否也将该服务器视为主观下线状态，当超过某quorum后将其视为客观下线状态。
当一个主服务器被某sentinel视为客观下线状态后，该sentinel会与其他sentinel协商选出零头sentinel进行故障转移工作。每个发现主服务器进入客观下线的sentinel都可以要求其他sentinel选自己为领头sentinel，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元，每个纪元中只会选择一个领头sentinel。如果所有超过一半的sentinel选举某sentinel领头sentinel。之后该sentinel进行故障转移操作。
如果一个Sentinel为了指定的主服务器故障转移而投票给另一个Sentinel，将会等待一段时间后试图再次故障转移这台主服务器。如果该次失败另一个将尝试，Redis Sentinel保证第一个活性(liveness)属性，如果大多数Sentinel能够对话，如果主服务器下线，最后只会有一个被授权来故障转移。 同时Redis Sentinel也保证安全(safety)属性，每个Sentinel将会使用不同的配置纪元来故障转移同一台主服务器

故障转移

首先是从主服务器的从服务器中选出一个从服务器作为新的主服务器。选点的依据依次是：网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no ont将该从服务器升为新主服务器。通过slaveof ip port命令让其他从服务器复制该新主服务器。最后当旧主重新连接后将其变为新主的从服务器。注意如果客户端与就主服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。故障转移成功后会通过发布订阅连接广播新的配置信息，其他sentinel收到后依据配置纪元更大来更新主服务器信息。Sentinel保证第二个活性属性：一个可以相互通信的Sentinel集合会统一到一个拥有更高版本号的相同配置上。

哨兵机制图解如下：

• 正常集群系统

• master节点宕机

• 故障转移，选举新的master节点

哨兵机制性能缺点：

1.主从服务器的数据要经常进行主从复制，这样造成性能下降。

2.当主服务器宕机后，从服务器切换成主服务器的这段时间，服务是不可用的，实时用户场景不可接受。