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的频道信息，并自动链接新的主节点。通常来讲这种方式几乎无人使用。