Redis-集群架构剖析 | 逗哥-架构师之路

2019年2月14日10:33:16 发表评论 2,594 views

2019开工这几天浑浑噩噩，天气也是格外的冷，导致我身心疲惫，无心拟写新的文章，可昨晚深夜看到一篇关于redis的文章，这让我回想起了工作中的点点滴滴，故此，今天我也想分享一些，我们日常工作中最常见的架构，就算您没有接触过redis，也希望您尝试阅读，因为它至关重要。

此文重点：
1,剖析redis集群架构重点知识？
2,redis面试都会问哪些？

一、剖析redis日常集群架构

我只介绍我会的，剩下的有您来补充。

架构-1 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。
Twemproxy 是一种Redis代理2015年很多企业都在用，但它不支持集群的动态伸缩，而codis则支持动态的增减Redis节点；另外，官方的redis 3.0开始支持cluster，所以2019您可以考虑Codis了。

codis 与 twemproxy相比优势在哪里：

codis 支持动态水平扩展，对client完全透明不影响服务的情况下可以完成增减redis实例的操作；
codis 是用go语言写的并支持多线程，twemproxy用C并只用单线程。
codis 性能好，但如果内存过小就截然相反了。

Codis工作组件原理
1. Codis Proxy (codis-proxy)，处理客户端请求，支持Redis协议，因此客户端访问Codis Proxy跟访问原生Redis没有什么区别；
2. Codis Dashboard (codis-config)，Codis 的管理工具，支持添加/删除 Redis 节点、添加/删除 Proxy 节点，发起数据迁移等操作。codis-config 本身还自带了一个 http server，会启动一个 dashboard，用户可以直接在浏览器上观察 Codis 集群的运行状态；
3. Codis Redis (codis-server)，Codis 项目维护的一个 Redis 分支，基于 2.8.21 开发，加入了 slot 的支持和原子的数据迁移指令；
4. ZooKeeper/Etcd，Codis 依赖 ZooKeeper 来存放数据路由表和 codis-proxy 节点的元信息，codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy；

三、Redis Cluster

我经历这套架构的时间为2017年，在这个时间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. 资源隔离性较差，容易出现相互影响的情况。