专栏首页极客运维【redis从入门到上线(4)】- redis高可用架构横向对比分析

【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单独写些文章。

本文分享自微信公众号 - 极客运维(hypernetworker),作者:背锅侠

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-07-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 【redis从入门到上线(2)】- redis配置要点

    这次我们讲讲redis的一些配置要点,包括日志,持久化,主备,数据压缩,内存分配等,以及一些坑,简单的配置就不说了,可以去看官方文档。

    一条老狗
  • 【redis从入门到上线(1)】- 初识redis及部署

    Redis是一个开源(BSD许可),内存存储的数据结构服务器,可用作数据库,高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合,位图,hyper...

    一条老狗
  • Rancher入门

    Rancher是目前市面上唯一一个能满足开箱即用的容器管理平台,同时能够支持多种编排引擎,如Mesos,Rancher自己的Cattle,Google的K8S,...

    一条老狗
  • 解决 Redis 的疑难杂症

    显而易见,如今的 Redis 已经进入了成熟期,但依旧存在很多疑难杂症。数以千计的开发者都在开发和使用这个数据库,它拥有非常完善的文档。

    用户1737318
  • Spring Boot 如何快速集成 Redis 哨兵?

    前面的分享栈长介绍了如何使用 Spring Boot 快速集成 Redis,上一篇是单机版,也有粉丝留言说有没有 Redis Sentinel 的集成教程,这篇...

    Java技术栈
  • 【redis学习】高级键管理

    为了更有效地在应用程序中使用 Redis ,我们需要理解 Redis 是如何存储键的,并了解用于操作 Redis 实例中键空间的命令。

    看、未来
  • Redis数据库安全手册

    Redis是一个高性能的key-value数据库,这两年可谓火的不行。而Redis的流行也带来一系列安全问题,不少攻击者都通过Redis发起攻击。本文将讲解这方...

    FB客服
  • Redis 创始人宣布退居二线:我写代码只是为了表达自己!

    前几日,Redis 创始人 Salvatore Sanfilippo 在他的个人博客(http://antirez.com/)上宣布将结束自己的 Redis 之...

    程序猿DD
  • 如何在云开发Cloudbase中使用Redis?

    云开发 Cloudbase 是腾讯云为移动开发者提供的云原生一体化应用开发平台,可用于开发多种客户端,它帮助开发者统一构建和管理资源,免去了应用开发过程中繁琐的...

    腾讯云开发TCB
  • Gavin老师:分布式缓存Redis高级应用实战(艾编程精品视频)

    【学完本节课你将掌握如下知识】 1、分布式缓存中间件选型 2、Redis作为单线程模式为什么效能还这么高? 3、Redis服务安装机常用命令解析 4、如...

    艾编程

扫码关注云+社区

领取腾讯云代金券