Redis 缓存数据库

Redis 高可用方案

高可用概念

  高可用（High Availability，既HA），指的是通过尽量缩短日常维护操作和减少突发系统奔溃锁导致的停机时间来提高系统和应用的可用性。如果一个业务系统全年都在提供服务，那么它的可用性可达100%。
  那么什么样的系统可以称之为高可用呢？
  业界一般用几个九来衡量系统的可用性，当系统运行时间达到4个九既99.99%时的系统称之为高可用，全年宕机时间为52分钟左右。

高可用一般来说有两个含义：

• 一是数据尽量不丢失。
• 二是保证服务尽可能可用。

Redis 中的

• AOF 和 RDB 数据持久化保证了数据尽量不丢失。
• 让多个节点来保证服务尽可能提供服务。

这里说一下单个节点系统的明显缺陷，一旦发生故障会导致服务不可用，而且，单个节点处理所有的请求，吞吐量有限，容量也是有限的。

Redis 高可用的实现方案

  Redis 实现高可用，在于采用集群的方式，提供多个节点，通过有是那种部署模式：主从模式、哨兵模式、集群模式。

1、主从模式

  Redis 的主从模式，我们可以把它想象成我们数据库高可用方案中的 主从复制，读写分离。主从模式就是，我们部署多台 Redis 节点，其中一台节点是主节点，其他的节点都是从节点。主从模式实现读写分离，只有master 节点提供数据的事务性操作，slave 节点只提供读操作。所有 slave 节点的数据都是从 master 节点同步过来的，该模式的结构如下：
 

 

  如果我们使用简单的主从模式架构方式，既所有 slave 节点都挂载在 master 节点上，这样做的优点是 slave 节点与master 节点的数据延迟较小。缺点是 master 同步一次数据的时间较长。
  改进方案是：我们可以只在 master 节点下只挂载一个 slave 节点，其他的节点挂载在这个 slave 节点，让数据同步经过传递完成。如图所示，Redis 和大部分中间件的主从模式中的数据同步都是由 slave 节点主动发起的，这样可以减少 master 的性能消耗。

 

 

主从模式的优缺点
优点：
1、主从模式做到了数据冗余，数据拥有备份，当主节点发生故障时，可以选择一个 slave 继续提供服务。
2、实现读写分离，减低了 master 节点读数据的压力，提高了系统的性能。
3、配置简单，容易搭建。只需要在slave 节点上维护master 节点的地址信息即可实现。

 
缺点：
1、当 master 节点宕机时，由于无法选择哪一个 slave 节点当 master 节点，无法保证高可用。
2、所有写数据的压力都集中在 master 节点，没有解决 master 节点写的压力。

 
 

2、哨兵模式

  哨兵模式是基于主从模式的，哨兵（sentinel）模式是为了解决主从模式中的问题而提出来，既当 master 节点宕机时，由于无法选择哪一个 slave 节点当 master 节点，导致 Redis 无法保证高可用。
  哨兵模式在主从模式的基础上，增加哨兵对主从模式中的每个节点进行监控，当 master 节点出现故障时通知投票机制，选择新的 master 节点，并将所有的 slave 节点连接到新的 master 节点上，如图所示：

 

 

哨兵模式有三个作用：监控、通知和自动故障转移。

• 监控：不断地检测 master 和 slave 是否运行正常。包括 master 存活检测、master 和 slave 运行状况的检测。
• 通知：当被监控的某个节点出现问题时，Sentinel 可以通知 API 向管理员或者其他应用程序发送通知。
• 自动故障转移：断开 master 与 slave 之间的连接，选取一个 slave 作为一个新的 master ，将其他的 slave 连接到新的 master 中，并告知客户端新的节点地址。

 
哨兵模式的优点
优点：哨兵模式，可以保证 Redis 的高可用，监控各个节点的运行状态，通知客户端节点出现问题，并进行自动故障转移。
 

哨兵模式的缺点
缺点：
1、基于主从模式，数据写的操作都集中在 master 上，仍然没有解决 master 写数据的压力。
2、在切换主节点的时候，会发生数据的丢失。
3、集群里面每个节点都存储相同的内容，很浪费内存空间，没有真正实现分布式存储。

 
 

3、集群模式

  哨兵模式基本已经实现了高可用，但是每个节点都存储相同的内容，很浪费内存。而且，哨兵模式没有解决master写数据的压力。为了解决这些问题，就有了集群模式，实现分布式存储，每个节点存储不同的内容。集群部署的方式能自动将数据进行分片，每个master上放一部分数据，提供了内置的高可用服务，即使某个master宕机了，服务还可以正常地提供，架构如下图所示：
 

 
集群模式中数据通过数据分片的方式被自动分割到不同的master节点上，每个Redis集群有16384个哈希槽，进行set操作时，每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽。数据在集群模式中是分开存储的，那么节点之间想要知道其他节点的状态信息，包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等是通过建立TCP连接，使用gossip协议来进行集群信息传播。

 

​ 故障判断方法：判断故障的逻辑其实与哨兵模式有点类似，在集群中，每个节点都会定期的向其他节点发送ping命令，通过有没有收到回复来判断其他节点是否已经下线。具体方法是采用半数选举机制，当A节点发现目标节点疑似下线，就会向集群中的其他节点散播消息，其他节点就会向目标节点发送命令，判断目标节点是否下线。如果集群中半数以上的节点都认为目标节点下线，就会对目标节点标记为下线，从而告诉其他节点，让目标节点在整个集群中都下线。

 

集群模式的优点
1、拓展性强，可扩展 master 节点，释放单个 master 节点写数据的压力，节点可动态添加或者删除。
2、能够实现自动故障转移，节点之间通过 gossip 协议交换状态信息，用投票机制完成 slave 到 master 的角色转换。
3、无中心结构，所有的Redis节点通过(PING-PONG机制)彼此互联。