优点:
-
秒级切换,在 5s 内完成整个切换操作
脚本自定义,架构可控
对应用透明,前端不用担心后端发生什么变化
缺点:
维护成本略高,Redis Sentinel 集群建议投入 3 台机器以上
使用 VIP 增加维护成本,存在 IP 混乱风险
Sentinel 模式存在短时间的服务不可用
3.3 封装客户端直连 Redis Sentinel 端口
部分业务只能通过外网访问 Redis,上述两种方案均不可用,于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口,然后通过这个端口获取到当前的主节点,然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是,Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。如果前端业务使用 Java,有 JedisSentinelPool 可以复用;如果前端业务使用 PHP,可以在 phpredis 的基础上做二次封装。
优点:
服务探测故障及时
DBA 维护成本低
缺点:
依赖客户端支持 Sentinel
Sentinel 服务器和 Redis 节点需要开放访问权限
对应用有侵入性
3.4 Redis Sentinel 集群 + Keepalived/Haproxy
底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端通过 VIP 提供服务。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Redis 之间的切换通过 Redis Sentinel 内部机制保障,VIP 切换通过 Keepalived 保障。
优点:
秒级切换
对应用透明
缺点:
维护成本高
存在脑裂
Sentinel 模式存在短时间的服务不可用
3.5 Redis M/S + Keepalived
此方案没有使用到 Redis Sentinel。此方案使用了原生的主从和 Keepalived,VIP 切换通过 Keepalived 保障,Redis 主从之间的切换需要自定义脚本实现。
优点:
秒级切换
对应用透明
部署简单,维护成本低
缺点:
需要脚本实现切换功能
存在脑裂
3.6 Redis Cluster
From: http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster
Redis 3.0.0 在 2015 年 4 月 2 日正式发布,距今已有两年多的时间。Redis 集群采用 P2P 模式,无中心化。把 key 分成 16384 个 slot,每个实例负责一部分 slot。客户端请求对应的数据,若该实例 slot 没有对应的数据,该实例会转发给对应的实例。另外,Redis 集群通过 Gossip 协议同步节点信息。
优点:
组件 all-in-box,部署简单,节约机器资源
性能比 proxy 模式好
自动故障转移、Slot 迁移中数据可用
官方原生集群方案,更新与支持有保障
缺点:
架构比较新,最佳实践较少
多键操作支持有限(驱动可以曲线救国)
为了性能提升,客户端需要缓存路由表信息
节点发现、reshard 操作不够自动化
3.7 Twemproxy
From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster
多个同构 Twemproxy(配置相同)同时工作,接受客户端的请求,根据 hash 算法,转发给对应的 Redis。
Twemproxy 方案比较成熟了,之前我们团队长期使用此方案,但是效果并不是很理想。一方面是定位问题比较困难,另一方面是它对自动剔除节点的支持不是很友好。
优点:
开发简单,对应用几乎透明
历史悠久,方案成熟
缺点:
代理影响性能
LVS 和 Twemproxy 会有节点性能瓶颈
Redis 扩容非常麻烦
Twitter 内部已放弃使用该方案,新使用的架构未开源
3.8 Codis
From: https://github.com/CodisLabs/codis
Codis 是由豌豆荚开源的产品,涉及组件众多,其中 ZooKeeper 存放路由表和代理节点元数据、分发 Codis-Config 的命令;Codis-Config 是集成管理工具,有 Web 界面供使用;Codis-Proxy 是一个兼容 Redis 协议的无状态代理;Codis-Redis 基于 Redis 2.8 版本二次开发,加入 slot 支持,方便迁移数据。
优点:
开发简单,对应用几乎透明
性能比 Twemproxy 好
有图形化界面,扩容容易,运维方便
缺点:
代理依旧影响性能
组件过多,需要很多机器资源
修改了 Redis 代码,导致和官方无法同步,新特性跟进缓慢
开发团队准备主推基于 Redis 改造的 reborndb
0×04 最佳实践
所谓的最佳实践,都是最适合具体场景的实践。
主推以下方案:
Redis Sentinel 集群 + 内网 DNS + 自定义脚本
Redis Sentinel 集群 + VIP + 自定义脚本
以下是实战过程中总结出的最佳实践:
Redis Sentinel 集群建议使用 >= 5 台机器
不同的大业务可以使用一套 Redis Sentinel 集群,代理该业务下的所有端口
根据不同的业务划分好 Redis 端口范围
自定义脚本建议采用 Python 实现,扩展便利
自定义脚本需要注意判断当前的 Sentinel 角色
自定义脚本传入参数:
自定义脚本需要远程 ssh 操作机器,建议使用 paramiko 库,避免重复建立 SSH 连接,消耗时间
加速 SSH 连接,建议关闭以下两个参数
UseDNS no
GSSAPIAuthentication no
自动切换和故障切换,所有操作建议在 15s 以内完成
閱讀更多 IT生涯 的文章