Redis集群架构

Replication+Sentinel

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

这里Sentinel的作用有三个: 监控:Sentinel 会不断的检查主服务器和从服务器是否正常运行。 通知:当被监控的某个redis服务器出现问题，Sentinel通过API脚本向管理员或者其他的应用程序发送通知。 自动故障转移:当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系 的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点。

工作原理就是，当Master宕机的时候，Sentinel会选举出新的Master，并根据Sentinel中client-reconfig-script脚本配置的内容，去动态修改VIP(虚拟IP)，将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可！

故障发生后的转移情况，可以理解为下图

缺陷:

(1)主从切换的过程中会丢数据

(2)Redis只能单点写，不能水平扩容

Proxy+Replication+Sentinel

这里的Proxy目前有两种选择:Codis和Twemproxy。我经历这套架构的时间为2015年，当时我好像咨询过我的主管为啥不用Codis和Redis官网的Redis Cluster。原因有二:

据说是因为Codis开源的比较晚，考虑到更换组件的成本问题。毕竟本来运行好好的东西，你再去换组件，风险是很大的。

Redis Cluster在2015年还是试用版，不保证会遇到什么问题，因此不敢尝试。 所以我没接触过Codis，之前一直用的是Twemproxy作为Proxy。 这里以Twemproxy为例说明，如下图所示

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

缺陷: (1)部署结构超级复杂 (2)可扩展性差，进行扩缩容需要手动干预 (3)运维不方便

Redis Cluster

Redis Cluster已经很成熟了！你们在网上能查到的大部分缺点，在我接触到的时候基本已经解决!

比如没有完善的运维工具？可以参照一下搜狐出的CacheCloud。

比如没有公司在生产用过？我接触到的时候，百度贴吧，美团等大厂都用过了。

比如没有Release版？我接触到的时候距离Redis Cluster发布Release版已经很久。

而且毕竟是官网出的，肯定会一直维护、更新下去，未来必定会更加成熟、稳定。换句话说，Redis不倒，Redis Cluster就不会放弃维护。

工作原理如下 客户端与Redis节点直连,不需要中间Proxy层，直接连接任意一个Master节点 根据公式HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作

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

缺点: (1)批量操作是个坑 (2)资源隔离性较差，容易出现相互影响的情况。