Redis集群与高可用性技术小结

• 客户端分片，这种方式需要实现特定的客户端，需要手工配置redis实例并根据算法进行访问，对于redis实例的增减，调整灵活性很差，一般不推荐。
• 代理分片，常见的有Twemproxy架构（豆瓣创建了codis，未测试过，在此从略）：
• 优点
  • sharding逻辑对开发透明，读写方式和单个redis一致。
  • 可以作为cache和storage的proxy（by auto-eject）。
• 缺点
  • 架构复杂，层次多。包括lvs、twemproxy、redis、sentinel和其控制层程序。
  • 管理成本和硬件成本很高。
  • 2 * 1Gbps 网卡的lvs机器，最大能支撑140万pps。
  • 流量高的系统，proxy节点数和redis个数接近。
  • Redis层仍然扩容能力差，预分配足够的redis存储节点。对于redis实例的增减同样缺乏应对灵活性。

  

  这是twemproxy的架构，客户端直接连接最上面的lvs（LB），第二层是同构的twemproxy节点，下面的redis master节点以及热备的slave节点，另外还有独立的sentinel集群和切换控制程序，twemproxy先介绍到这里。

• Redis Cluster架构

  在这种机制下，没有中心节点（和代理模式的重要不同之处）。Redis Cluster将所有Key映射到16384个Slot中，集群中每个Redis实例负责一部分，业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。

• 优点
  • 无中心架构。
  • 数据按照slot存储分布在多个redis实例上。
  • 增加slave做standby数据副本，用于failover，使集群快速恢复。
  • 实现故障auto failover。节点之间通过gossip协议交换状态信息；投票机制完成slave到master角色的提升。
  • 亦可manual failover，为升级和迁移提供可操作方案。
  • 降低硬件成本和运维成本，提高系统的扩展性和可用性。
• 缺点
  • client实现复杂，驱动要求实现smart client，缓存slots mapping信息并及时更新。
  • 目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的"max redirect exception"。
  • 客户端的不成熟，影响应用的稳定性，提高开发难度。
  • 节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout），被判断下线。这种failover是没有必要，sentinel也存在这种切换场景。

  cluster的架构如下：

  

  图上只有master节点（slave略去），所有节点构成一个完全图,slave节点在集群中与master只有角色和功能的区别。

• 基于keepalived和redis-Sentinel集群的高可用性方案

  Sentinel是一个管理多个redis实例的工具，它可以实现对redis的监控、通知、自动故障转移。sentinel不断的检测redis实例是否可以正常工作，通过API向其他程序报告redis的状态，如果redis master不能工作，则会自动启动故障转移进程，将其中的一个slave提升为master，其他的slave重新设置新的master实例。也就是说，它提供了：

  监控（Monitoring）： Sentinel 会不断地检查你的主实例和从实例是否正常。

  通知（Notification）： 当被监控的某个 Redis 实例出现问题时， Sentinel 进程可以通过 API 向管理员或者其他应用程序发送通知。

  自动故障迁移（Automatic failover）： 当一个主redis实例失效时， Sentinel 会开始记性一次failover， 它会将失效主实例的其中一个从实例升级为新的主实例， 并让失效主实例的其他从实例改为复制新的主实例； 而当客户端试图连接失效的主实例时， 集群也会向客户端返回新主实例的地址， 使得集群可以使用新主实例代替失效实例。

  Redis Sentinel自身也是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程， 这些进程使用流言协议（gossip protocols)来接收关于主Redis实例是否失效的信息， 然后使用投票协议来决定是否执行自动failover，以及评选出从Redis实例作为新的主Redis实例。

  Sentienl工具提供了redis主-从方式的实现，那么借助基于VRRP的keepalived，就能实现在redis主-从切换时外部可见的redis实例不变性。除了在切换过程中，客户端不会明显的感知到redis的服务实例变化。

  • 当 Master 与 Slave 均运作正常时, Master负责服务，Slave负责Standby；
  • 当 Master 挂掉，Slave 正常时, Slave接管服务，有写权限，同时关闭主从复制功能；
  • 当 Master 恢复正常，则从Slave同步数据，同步数据之后关闭主从复制功能，恢复Master身份，同时Slave等待Master同步数据完成之后，恢复Slave身份。

  但是redis也支持客户端与sentinel直接交互来实现高可用性，但是与1.相似，同样需要特定客户端，因为客户端需要监控sentinel的频道信息，并自动连接新的主节点。一般来说这种方式几乎无人使用。