常用的Redis集群架构及对比

Redis集群架构，不同的公司可能又不同的架构实现，一般跑不出常用的哪几种，可能在自己的业务使用上有所改动。我所用过的Redis集群架构是Redis官方版本：Redis Cluster，这也是Redis4.0+版本的产物，资料显示，2015年的时候还是试用版本，但是到现在已经是一套非常成熟的Redis集群架构，又是官方版本，稳定性，维护性都非常高。
这篇文章主要是介绍几个Redis集群的架构方案，是在博客园中看到的一篇文章，所以转载过来，后面我会针对于Redis Cluster这一官方版的架构再写一篇文章，详细介绍一下，并做一个简单的实验来说明一下这个架构的优点，当然还有一些缺点。
正文~~~

Replication+Sentinel

这套架构使用的是社区版本推出的原生高可用解决方案，其架构图如下！

这里Sentinel的作用有三个:

• 监控:Sentinel 会不断的检查主服务器和从服务器是否正常运行。
• 通知:当被监控的某个Redis服务器出现问题，Sentinel通过API脚本向管理员或者其他的应用程序发送通知。
• 自动故障转移:当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点。
  工作原理就是，当Master宕机的时候，Sentinel会选举出新的Master，并根据Sentinel中client-reconfig-script脚本配置的内容，去动态修改VIP(虚拟IP)，将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可！
  故障发生后的转移情况，可以理解为下图
  
  缺陷:
• 主从切换的过程中会丢数据
• Redis只能单点写，不能水平扩容

Proxy+Replication+Sentinel

这里的Proxy目前有两种选择:Codis和Twemproxy。,这里以Twemproxy为例说明，如下图所示

工作原理如下:

• 前端使用Twemproxy+KeepAlived做代理，将其后端的多台Redis实例分片进行统一管理与分配
• 每一个分片节点的Slave都是Master的副本且只读
• Sentinel持续不断的监控每个分片节点的Master，当Master出现故障且不可用状态时，Sentinel会通知/启动自动故障转移等动作
• Sentinel 可以在发生故障转移动作后触发相应脚本（通过 client-reconfig-script 参数配置 ），脚本获取到最新的Master来修改Twemproxy配置

缺陷:

• 部署结构超级复杂
• 可扩展性差，进行扩缩容需要手动干预
• 运维不方便

Redis Cluster

redis官方推荐的集群解决方案,多个redis实例同行,采用slot（槽）分割数据，时CRC16与16384取模后分散，主从结构和选举算法，保证每个节点的可靠性，客户端可以连接任意一个node进行操作，而不需要像上面两种架构一样来实现集群。架构图：

工作原理如下：

• 客户端与redis节点直连，不需要中间proxy层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
• 根据公式HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作
• 如果一个M服务器挂掉，集群会通过在配置的监控时间超时后使用一个类似选举的算法立刻将一台S服务器升级为M服务器
• 整个集群节点的Fail是通过集群中超过半数的节点检测失效时才生效

具有如下优点:

• 无需Sentinel哨兵监控，如果Master挂了，Redis Cluster内部自动将Slave切换Master
• 可以进行水平扩容
• 支持自动化迁移，当出现某个Slave宕机了，那么就只有Master了，这时候的高可用性就无法很好的保证了，万一Master也宕机了，咋办呢？ 针对这种情况，如果说其他Master有多余的Slave ，集群自动把多余的Slave迁移到没有Slave的Master 中。

缺点:

• 批量操作是个坑
• 资源隔离性较差，容易出现相互影响的情况。