三七互娱DBA温国兵：Redis高可用架构最佳实践(2)

优点：

• 秒级切换,在 5s 内完成整个切换操作
• 脚本自定义,Redis Sentinel 集群建议投入 3 台机器以上
• 使用 VIP 增加维护成本,存在 IP 混乱风险
• Sentinel 模式存在短时间的服务不可用

2.3 封装客户端直连 Redis Sentinel 端口

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

优点：

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

缺点：

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

2.4 Redis Sentinel 集群 + Keepalived/Haproxy

底层是 Redis Sentinel 集群,Web 端通过 VIP 提供服务.当主节点发生故障,Redis 之间的切换通过 Redis Sentinel 内部机制保障,VIP 切换通过 Keepalived 保障.

优点：

• 秒级切换
• 对应用透明

缺点：

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

2.5 Redis M/S + Keepalived

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

优点：

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

缺点：

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

2.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 操作不够自动化

2.7 Twemproxy

From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster

多个同构 Twemproxy(配置相同)同时工作,接受客户端的请求,根据 hash 算法,转发给对应的 Redis.

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

优点：

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

缺点：

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

2.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

三、最佳实践

（编辑：ASP站长网）