【redis从入门到上线(4)】- redis高可用架构横向对比分析

redis架构分析

上篇我们讲解完 Redis Sentinel 原理之后，接下来讲解常用的 Redis 高可用架构。

• Redis Sentinel 集群 + 内网 DNS + 自定义脚本
• Redis Sentinel 集群 + VIP + 自定义脚本
• 封装客户端直连 Redis Sentinel 端口
  • JedisSentinelPool，适合 Java
  • PHP 基于 phpredis 自行封装
• Redis Sentinel 集群 + Keepalived/Haproxy
• Redis M/S + Keepalived
• Redis Cluster
• Twemproxy+sentinel+Keepalived
• Codis
• Pika

1.Redis Sentinel 集群 + 内网 DNS + 自定义脚本

上图是已经在线上环境应用的方案。底层是 Redis Sentinel 集群，代理着 Redis 主从，Web 端连接内网 DNS 提供服务。内网 DNS 按照一定的规则分配，比如 xxxx.redis.cache/queue.port.xxx.xxx，第一个段表示业务简写，第二个段表示这是 Redis 内网域名，第三个段表示 Redis 类型，cache 表示缓存，queue 表示队列，第四个段表示 Redis 端口，第五、第六个段表示内网主域名。

当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Sentinel 集群会调用 client-reconfig-script 配置的脚本，修改对应端口的内网域名。对应端口的内网域名指向新的 Redis 主节点。

优点：

秒级切换，在 10s 内完成整个切换操作

脚本自定义，架构可控

对应用透明，前端不用担心后端发生什么变化

缺点：

维护成本略高，Redis Sentinel 集群建议投入 3 台机器以上

依赖 DNS，存在解析延时

Sentinel 模式存在短时间的服务不可用

服务通过外网访问不可采用此方案

2.Redis Sentinel 集群 + VIP + 自定义脚本

此方案和上一个方案相比，略有不同。第一个方案使用了内网 DNS，第二个方案把内网 DNS 换成了虚拟 IP。底层是 Redis Sentinel 集群，代理着 Redis 主从，Web 端通过 VIP 提供服务。在部署 Redis 主从的时候，需要将虚拟 IP 绑定到当前的 Redis 主节点。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Sentinel 集群会调用 client-reconfig-script 配置的脚本，将 VIP 漂移到新的主节点上。

优点：

• 秒级切换，在 5s 内完成整个切换操作
• 脚本自定义，架构可控
• 对应用透明，前端不用担心后端发生什么变化

缺点：

• 维护成本略高，Redis Sentinel 集群建议投入 3 台机器以上
• 使用 VIP 增加维护成本，存在 IP 混乱风险
• Sentinel 模式存在短时间的服务不可用
• 3.3 封装客户端直连 Redis Sentinel 端口

3.封装客户端直连 Redis Sentinel 端口

部分业务只能通过外网访问 Redis，上述两种方案均不可用，于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口，然后通过这个端口获取到当前的主节点，然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是，Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。如果前端业务使用 Java，有 JedisSentinelPool 可以复用；如果前端业务使用 PHP，可以在 phpredis 的基础上做二次封装。

优点：

• 服务探测故障及时
• DBA 维护成本低

缺点：

• 依赖客户端支持 Sentinel
• Sentinel 服务器和 Redis 节点需要开放访问权限
• 对应用有侵入性

4.Redis Sentinel 集群 + Keepalived/Haproxy

底层是 Redis Sentinel 集群，代理着 Redis 主从，Web 端通过 VIP 提供服务。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Redis 之间的切换通过 Redis Sentinel 内部机制保障，VIP 切换通过 Keepalived 保障。

优点：

• 秒级切换
• 对应用透明

缺点：

• 维护成本高
• 存在脑裂
• Sentinel 模式存在短时间的服务不可用

5.Redis M/S + Keepalived

此方案没有使用到 Redis Sentinel。此方案使用了原生的主从和 Keepalived，VIP 切换通过 Keepalived 保障，Redis 主从之间的切换需要自定义脚本实现。

优点：

• 秒级切换
• 对应用透明
• 部署简单，维护成本低

缺点：

• 需要脚本实现切换功能
• 存在脑裂

6.Redis Cluster

Redis 3.0.0 在 2015 年 4 月 2 日正式发布，距今已有两年多的时间。Redis 集群采用 P2P 模式，无中心化。把 key 分成 16384 个 slot，每个实例负责一部分 slot。客户端请求对应的数据，若该实例 slot 没有对应的数据，该实例会转发给对应的实例。另外，Redis 集群通过 Gossip 协议同步节点信息。

优点：

• 组件 all-in-box，部署简单，节约机器资源
• 性能比 proxy 模式好
• 自动故障转移、Slot 迁移中数据可用
• 官方原生集群方案，更新与支持有保障

缺点：

• 架构比较新，最佳实践较少
• 多键操作支持有限（驱动可以曲线救国）
• 为了性能提升，客户端需要缓存路由表信息
• 节点发现、reshard 操作不够自动化

7.Twemproxy+sentinel+Keepalived

多个同构 Twemproxy（配置相同）同时工作，接受客户端的请求，根据 hash 算法，转发给对应的 Redis。

Twemproxy 方案比较成熟了，之前我们团队长期使用此方案，但是效果并不是很理想。一方面是定位问题比较困难，另一方面是它对自动剔除节点的支持不是很友好。

优点：

• 开发简单，对应用几乎透明
• 历史悠久，方案成熟

缺点：

• 代理影响性能
• LVS 和 Twemproxy 会有节点性能瓶颈
• Redis 扩容非常麻烦
• Twitter 内部已放弃使用该方案且不再在GitHub上更新，新使用的架构未开源

8.Codis

Codis 是由豌豆荚开源的产品，涉及组件众多，其中 ZooKeeper 存放路由表和代理节点元数据、分发 Codis-Config 的命令；Codis-Config 是集成管理工具，有 Web 界面供使用；Codis-Proxy 是一个兼容 Redis 协议的无状态代理；Codis-Redis 基于 Redis 2.8 版本二次开发，加入 slot 支持，方便迁移数据。

优点：

• 开发简单，对应用几乎透明
• 性能在特定情况下比Twemproxy好
• 有图形化界面，扩容容易，运维方便

缺点：

• 代理依旧影响性能
• 组件过多，需要很多机器资源
• 修改了 Redis 代码，导致和官方无法同步，新特性跟进缓慢
• 开发团队准备主推基于 Redis 改造的 reborndb

9.Pika

pika 是DBA和基础架构组联合开发的类Redis 存储系统，所以完全支持Redis协议，用户不需要修改任何代码，就可以将服务迁移至pika。Pika是一个可持久化的大容量redis存储服务，兼容string、hash、list、zset、set的绝大接口(兼容详情)，解决redis由于存储数据量巨大而导致内存不够用的容量瓶颈，并且可以像redis一样，通过slaveof命令进行主从备份，支持全同步和部分同步。同时DBA团队还提供了迁移工具， 所以户不会感知这个迁移的过程，迁移是平滑的。

pika主要是使用持久化存储来解决redis在内存占用超过50G，80G时遇到的如启动恢复时间长，主从同步代价大，硬件成本贵等问题，并且在对外用法上尽可能做到与redis一致，用户基本上对后端是redis或pika无感知。

优势：

• 多线程：较redis单线程更快
• 容量大：Pika没有Redis的内存限制, 最大使用空间等于磁盘空间的大小
• 加载db速度快：Pika 在写入的时候, 数据是落盘的, 所以即使节点挂了, 不需要rdb或者oplog，pika 重启不用加载所有数据到内存就能恢复之前的数据, 不需要进行回放数据操作
• 备份速度快：Pika备份的速度大致等同于cp的速度（拷贝数据文件后还有一个快照的恢复过程，会花费一些时间），这样在对于百G大库的备份是快捷的，更快的备份速度更好的解决了主从的全同步问题

劣势：

• 由于Pika是基于内存和文件来存放数据, 所以性能肯定比Redis低一些, 但是如果使用SSD盘来存放数据, 尽可能跟上Redis的性能

实践

其实架构的选型还是得结合实际应用场景来进行评估，个人建议：

• 量级一般够用的情况下，采用“Redis Sentinel 集群 + VIP + 自定义脚本”方案，最好配合个好的客户端，调整比较灵活，实施也高效。
• 量级较大时，可以考虑“Twemproxy+sentinel+Keepalived”或“Codis”，根据存储数据单key大小进行判断，我自己测试发现value小于KB级时，Codis的set性能是要远高于Twemproxy，大于KB级时，twemproxy性能反而好些。（虽然我看很多文章都说codis性能优于twemproxy，实际应用还是针对实际应用场景进行测试比较靠谱）
• 无论codis还是twemproxy相对来说都较复杂，嫌麻烦的朋友直接上360的pika好了

今天就写到这，之后可能会针对codis和pika单独写些文章。