Redis 高可用架构最佳实践( 二 ) 作者：温国兵来源：1、题记

当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达， Sentinel 集群会调用 client-reconfig-script 配置的脚本，修改对应端口的内网域名。对应端口的内网域名指向新的 Redis 主节点。
优点：
秒级切换，在 10s 内完成整个切换操作
脚本自定义，架构可控
对应用透明，前端不用担心后端发生什么变化
缺点：
维护成本略高， Redis Sentinel 集群建议投入 3 台机器以上
依赖 DNS ，存在解析延时
Sentinel 模式存在短时间的服务不可用
服务通过外网访问不可采用此方案
2、Redis Sentinel 集群 + VIP + 自定义脚本
文章插图
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 集群 + Keepalived/Haproxy
底层是 Redis Sentinel 集群，代理着 Redis 主从， Web 端通过 VIP 提供服务。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达， Redis 之间的切换通过 Redis Sentinel 内部机制保障， VIP 切换通过 Keepalived 保障。
优点：

秒级切换
对应用透明

缺点：

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

5、Redis M/S + Keepalived

文章插图
Redis M/S + Keepalived
此方案没有使用到 Redis Sentinel 。此方案使用了原生的主从和 Keepalived ， VIP 切换通过 Keepalived 保障， Redis 主从之间的切换需要自定义脚本实现。
优点：

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

缺点：

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

6、Redis Cluster

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

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