redis：那些年用过的Redis集群架构

淩亂°似流年 2022-09-15 00:58 148阅读 0赞

# Replication+Sentinel #

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]  
这里的sentinel的作用有三个：

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

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

故障发生后的转移情况，可以理解为下图  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
缺陷：

*  主从切换的过程中会丢失数据
 *  redis只能单点写，不能水平扩容

# Proxy+Replication+Sentinel #

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

*  据说是因为Codis开源的比较晚，考虑到更换组件的成本问题。毕竟本来运行好好的东西，你再去换组件，风险是很大的。
 *  Redis Cluster在2015年还是试用版，不保证会遇到什么问题，因此不敢尝试。

所以我没接触过Codis，之前一直用的是Twemproxy作为Proxy。  
这里以Twemproxy为例说明，如下图所示

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]  
工作原理如下：

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

缺陷:

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

# Redis Cluster #

我经历这套架构的时间为2017年，在这个时间Redis Cluster已经很成熟了！你们在网上能查到的大部分缺点，在我接触到的时候基本已经解决!

而且毕竟是官网出的，肯定会一直维护、更新下去，未来必定会更加成熟、稳定。换句话说，Redis不倒，Redis Cluster就不会放弃维护。所以，我推荐还是这套架构!

如下图所示

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16]  
工作原理如下：

*  客户端与redis节点直连，不需要中间proxy层，直接连接任意一个master节点
 *  根据公式`HASH_SLOT=CRC16(key) mod 16384`计算出映射到哪个分片上，然后redis会去相应的节点进行操作

具有如下优点:

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

缺点：

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

# 其他 #

在面试中如果碰到下列问题，如何应用上本篇的知识呢？先明确一点，我推荐的是Redis Cluster。

> 问题：懂Redis事务么？

回答：生产环境中采用redis cluster集群架构，不同的key是有可能分配到不同的redis节点上的，在这种情况下redis的事务机制是不生效的。其次，redis事务不支持回滚操作，简直是鸡肋！所以基本不用

> 问题2:Redis的多数据库机制，了解多少？

正常版：redis支持多个数据库，并且每个数据库的数据是隔离的不能共享，单机下的redis可以支持问题2:Redis的多数据库机制，了解多少？

高调版: redis cluster集群架构下只有一个数据库空间，即db。因此，我们没有使用redis的多数据库功能

> 问题3:Redis集群机制中，你觉得有什么不足的地方吗？

回答：

*  因为codis中所有的key分散在不同的redis实例中，所以就**不能再支持事务**
 *  rename操作也很危险，它的参数是两个key，如果这两个key在不同的redis实例中，rename操作是无法正确完成的了
 *  为了支持扩容，单个key对应的value不宜过大，因为集群迁移的最小单位是key，对于一个hash结构，它会一次性使用hgetall拉取所有的内容，然后使用hmset将之放置到另一个节点中。如果hash内部的key/value太多，可能会导致卡顿。
 *  做批量操作比较麻烦！

> 问题:你们有对Redis做读写分离么？

不做读写分离。

*  redis cluster架构，属于分片集群的架构。
 *  redis本身在内存上的操作，不会涉及IO吞吐，即使读写分离也不会提升太多容量
 *  Redis在生产上的主要问题是考虑容量，单机最多10-20G，key太多降低redis性能.因此采用分片集群结构，已经能保证了我们的性能
 *  用上了读写分离后，还要考虑主从一致性，主从延迟等问题，徒增业务复杂度。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/c33e197b436b4fe5adafce50742af77d.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/70c0c85647d548e9aaf23023b8a34986.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/7406d2f2b7b3444cbf0ab22130e31a67.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/c2a94388cf504ad2a199dfb07c5c1690.png