2022-01-27 redis集群技术调研

目录

​​摘要:​​

​​redis集群方案选型:​​

​​redis集群前端代理proxy技术选型:​​

​​redis集群的扩容/缩容:​​

​​redis cluster集群的节点高可用​​

​​redis节点主从复制:​​

​​鉴权​​

​​监控和:​​

摘要:

记录对于redis相关的技术选型, 并记录其特性

redis集群方案选型:

方案一: 主从部署 + sentinel监控

原理:

优点:

1. 完成了主从节点的高可用，自动完成主节点的failover

不足：

1. redis的主节点互相独立，不构成集群，仅主从节点构成读写分离集群。 容量受限于主节点
2. sentinel监控需要独立部署，浪费资源
3. 监控redis节点时需要明确配置sentinel-monitor，自动扩容redis集群时维护困难
4. 脑裂问题

1. sentinel集群由于网络问题监控到master节点失效, 进行主从切换，但是该主节点与客户端依然保持连接，导致出现双主节点
2. 此时客户端数据写入旧主节点，sentinele将旧主节点切换为从节点后，客户端写入的数据丢失
3. 问题出在sentinel集群与redis集群的心跳线路不稳定

5. 业界主流云数据库很少采用过该方案

方案二: redis cluster集群

优点:

1. 不需要单独部署监控节点, redis节点本身承担监控功能，自动完成主节点failover的主从切换，实现高可用
2. 节点间使用gossip协议，单个主从节点状态变化，可通过仅与相邻节点通信扩散到整个集群，通信方便
3. 数据分散到整个集群，存储容量达到整个集群的容量限制
4. 业界有成熟的使用案例

不足:

1. 数据分散到节点是通过crc16(key)%16384计算出slot，然后找到映射的节点，对客户端不透明。

1. 客户端需要连接每个redis节点，并且客户端需要响应ask和move指令，key如果不在查询的节点，则客户端需要根据move的返回信息重新查询，对客户端要求高
2. 为简化客户端操作， 需要集群代理proxy，对客户端屏蔽细节

2. 仅支持数据库0，不支持select选择数据库
3. 添加和删除节点，需要人为手动管理

1. 新增节点

1. 手动添加进集群，设置主从关系
2. 手动将为新增加的节点迁入slot

2. 删除节点

1. 手动将该节点的slot迁出
2. 手动将该节点下线

redis集群技术方案选择结果:

redis cluster集群 + 前端集群代理proxy

说明:

1. 为了屏蔽redis cluster内部的key分布细节，需要添加集群的前端代理proxy。proxy的选型见下文
2. 为支持对集群的动态扩容, 需要新增集群节点管理组件，用于完成自动扩容和缩容

1. 新节点的加入，为新节点迁入slot
2. 节点删除，迁出该节点的slot

redis集群前端代理proxy技术选型:

选型因素:

1. 稳定成熟的中间件，有业界采用的案例
2. 支持的命令充分，以减少对业务的限制

1. 批量key的命令
2. 支持阻塞式命令
3. 支持事务 TODO ?
4. 可以查看监控信息

3. 考虑不但支持redis cluster集群，也支持sentinel模式
4. 轻量级，便于做二次开发做定制

方案一: codis

优点:

1. 完整的redis分布式集群方案，监控和节点管理完善, 可直接用
2. 支持数据在线迁移
3. 自动对数据进行负载均衡
4. 最大支持1024个实例

缺点：

1. redis-server是自己开发的，非官方redis，存在差异
2. 支持的命令存在限制, 不支持的命令: ​​【redis】codis不支持命令_爱情三脚猫的专栏
3. codis过重,不便于做二次开发定制，也不便于直接集成到公司的云平台

方案二: redis-cluster-proxy

特性:

1. 随redis6.0版本发布的实验特性，redis官方实验室提供, 地址: ​​https://github.com/RedisLabs/redis-cluster-proxy/​​
2. 特性: ​​https://github.com/RedisLabs/redis-cluster-proxy/blob/1.0/README.md​​
3. 支持的命令: ​​https://github.com/RedisLabs/redis-cluster-proxy/blob/1.0/COMMANDS.md​​

缺点：

1. 目前仅发布​​1.0-beta2​​版, 没有发布release版, 未有已经采用的案例。 且已有14个月未有新代码提交
2. 目前没有性能测试数据对比
3. 仅支持redis cluster集群
4. 不支持订阅/发布命令
5. 没有附带监控命令和信息
6. 仅是前端proxy，没有动态扩容/缩容功能，需要定制开发

方案三：predixy

特性:

1. redis官方推荐的集群前端代理, 可认为经过redis官方认可, 且小米云redis也在使用:

1. redis客户端推荐列表: ​​Redis​​
2. 小米云redis使用predixy说明: ​​小米Redis的K8s容器化部署实践_小米云技术

2. predixy代码仓库: ​​https://github.com/joyieldInc/predixy​​
3. 支持的命令列表: ​​https://github.com/joyieldInc/predixy/blob/1.0.5/src/Command.h​​
4. 性能测试数据: ​​https://github.com/joyieldInc/predixy/wiki/Benchmark​​
5. 配置说明: ​​https://github.com/joyieldInc/predixy/blob/master/doc/config_CN.md​​
6. 支持sentinel和cluster集群
7. 支持更细粒度的权限访问控制
8. 配置简单, 仅配置一个存活的cluster节点地址,即可知道整个集群的信息
9. predix每100ms, 从配置的redis节点中, 请求此redis集群信息

缺点:

1. 社区活跃度低
2. 没有对redis集群节点的扩容/缩容功能, 自动化扩容缩容需要额外开发
3. predix配置中的所有静态redis节点下线，将导致整个集群不可用

方案四: ​​twemproxy​​

特点:

1. 由twemproxy自身负责对key进行分片
2. 地址: ​​https://github.com/twitter/twemproxy​​
3. 支持的命令列表: ​​https://raw.githubusercontent.com/twitter/twemproxy/master/notes/redis.md​​

不足:

1. 社区也不活跃, 上次提交src目录是在三年前
2. 支持命令不足, 订阅/发布，事件都不支持， 且不支持权限管理
3. 性能相比直接使用redis带来10%性能下降, 单redis节点超过20G, 效率急剧下降
4. 配置不便, nutcracker.yml中的servers必须配置所有的后端redis节点, 扩容redis集群困难

redis集群代理proxy的技术选型结果:

predixy, 但需要定制开发集群节点的扩容/缩容功能

predixy部署方式：

1. 由于proxy无状态，可多节点部署
2. proxy集群的自动扩容和缩容, 可通过k8s原生的HPA进行: ​​Horizontal Pod Autoscaler 演练 | Kubernetes​​
3. predixy中配置的redis节点,必须保证一直可用, 否则将造成整个集群不可用
4. proxy集群的高可用方案

1. keepalive + haproxy/lvs
2. miniSLB

redis集群的扩容/缩容:

方案一: redis cluster原生的slots迁移方案

特点:

1. 简单

1. redis-cli --cluster 命令簇

1. add-node/del-node 增加删除节点, 默认master, 建立主从需要用--cluster-slave --cluster-master-idr-slave --cluster-slave --cluster-slave 
2. reshard 分配slots
3. reblance 自动平衡各节点slots

2. 手动控制, 操作者可以控制每一个操作过程, 对操作者的经验和事故处理能力要求很高

缺点：

1. 需要手动进行, 无法自动扩容，数据量大时手动操作非常繁琐且易出错
2. 迁移slots的时间无法评估
3. 迁移过程中，遇到问题，无法回退

方案二: 使用当前现有的成熟的扩容缩容方案， 如codis

特点：

1. 不增加工作量, 有加快上线速度

缺点:

1. codis是一个完整的解决方案, 不适合直接用
2. 未找到合适的成熟的自动扩容集群的组件, 其他的云平台基本是自己实现, 所以可行性存在问题

方案三: 在集群代理proxy中, 添加控制集群扩容/缩容模块

特点:

1. 屏蔽掉集群扩容的细节, 在proxy中根据策略自动进行集群节点加入/删除, 和slots的迁入/迁出
2. 集群的扩容/缩容作为集群管理的核心模块自己编写, 有利于后续继续的迭代优化

缺点:

1. 需要对集群扩容过程中可能出现的问题都做好防范 开发时必须对每一个执行流程都理解的非常深刻

1. 延缓上线时间
2. 出错后影响数据的正确性和安全性, 后果无法接受

redis集群自动扩容方案选择:

1. 如果时间紧张, 使用redis cluster自带的命令手动扩容?
2. 如果有开发的时间, 解读codis自动扩容集群机制, 然后在集群代理proxy中实现一份

1. 是否能将存在的坑全部解决?
2. 要开发多久?

redis cluster集群的节点高可用

方案一: redis cluster集群自身的节点高可用

参考文章:
​​​018.Redis Cluster故障转移原理 - 云+社区 - 腾讯云​​

节点故障检测:

1. redis cluster集群心跳检测, failover, 选举新主节点

问题:

1. 脑裂问题

1. 原因:

1. 监控节点与redis节点的心跳线路存在网络分区, 导致监控节点选出新的主节点, 但是旧主节点与客户端网络连接依然存在。导致存在两个主节点
2. 导致客户端写入旧的主节点, 监控节点将旧主节点切换到从节点后，客户端写入数据丢失

2. 解决

1. 修改redis配置

1. min-replicas-max-lag: 主从复制和同步的时间延迟限制, 超过该时间master拒绝写入。避免双主时, 旧master继续写入数据

方案二: 自己编写一套故障探测切换系统, 如阿里云的HA系统。 TODO: 此版本不考虑

redis节点主从复制:

机制:

1. slave节点第一次连接master节点, 全量同步, sync

1. master生成子进程, 生成rdb文件,发送给slave节点。并记录发送数据的位置
2. slave节点加载rdb文件

2. 随后slave向master请求增量同步, psync
3. 如果slave请求增量同步失败, 会请求一次全量同步 sync

问题:

1. 一旦slave节点请求增量同步失败, 将请求全量同步

1. master节点创建子进程, 如果此时有写请求, 将导致写时复制, master主节点将占用两倍的内存开销
2. 增量同步失败后, 请求全量同步, 将占用master节点的出口网络io，和slave节点的入口网络io

解决方法：

方案一: 阿里云redis的主从策略, 己实现了一套基于日志的增量复制方案, TODO: 需要确定是否要按照该思路进行

​​标准版-双副本 - 云数据库 Redis - 阿里云​​

鉴权

包含：

1. 登录鉴权+日志
2. 操作鉴权+日志
3. 操作记录放到日志存储服务器

监控和:

包含: