文/温国兵
2017 年 5 月 13 日,应用性能管理大讲堂广州站圆满落幕,其中来自三七互娱的 DBA 温国兵在会场与各位进行了精彩的 Redis 技术分享。
Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。
如今,互联网业务的数据正以更快的速度在增长,数据类型越来越丰富,这对数据处理的速度和能力提出了更高要求。Redis 是一种开源的内存非关系型数据库,给开发人员带来的体验是颠覆性的。在自始至终的设计过程中,都充分考虑高性能,这使得 Redis 成为当今速度最快的 NoSQL 数据库。
考虑高性能的同时,高可用也是很重要的考虑因素。互联网 7x24 无间断服务,在故障期间以最快的速度 Failover,能给企业带来最小的损失。
那么,在实际应用中,都有哪些高可用架构呢?架构之间有何优劣?我们应该怎么取舍?有哪些最佳实践?
在讲解 Redis 高可用方案之前,我们先来看看 Redis Sentinel原理是怎么样的。
1 到 3 是自动发现机制:
4 是检测机制,5 和 6 是 failover 机制,7 是更新配置机制。[1]
讲解完 Redis Sentinel 原理之后,接下来讲解常用的 Redis 高可用架构。
接下来配合图文逐个讲解。
上图是已经在线上环境应用的方案。底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端连接内网 DNS 提供服务。内网 DNS 按照一定的规则分配,比如 xxxx.redis.cache/queue.port.xxx.xxx
,第一个段表示业务简写,第二个段表示这是 Redis 内网域名,第三个段表示 Redis 类型,cache 表示缓存,queue 表示队列,第四个段表示 Redis 端口,第五、第六个段表示内网主域名。
当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Sentinel 集群会调用 client-reconfig-script
配置的脚本,修改对应端口的内网域名。对应端口的内网域名指向新的 Redis 主节点。
优点:
缺点:
此方案和上一个方案相比,略有不同。第一个方案使用了内网 DNS,第二个方案把内网 DNS 换成了虚拟 IP。底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端通过 VIP 提供服务。在部署 Redis 主从的时候,需要将虚拟 IP 绑定到当前的 Redis 主节点。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Sentinel 集群会调用 client-reconfig-script
配置的脚本,将 VIP 漂移到新的主节点上。
优点:
缺点:
部分业务只能通过外网访问 Redis,上述两种方案均不可用,于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口,然后通过这个端口获取到当前的主节点,然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是,Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。如果前端业务使用 Java,有 JedisSentinelPool 可以复用;如果前端业务使用 PHP,可以在 phpredis 的基础上做二次封装。
优点:
缺点:
底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端通过 VIP 提供服务。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Redis 之间的切换通过 Redis Sentinel 内部机制保障,VIP 切换通过 Keepalived 保障。
优点:
缺点:
此方案没有使用到 Redis Sentinel。此方案使用了原生的主从和 Keepalived,VIP 切换通过 Keepalived 保障,Redis 主从之间的切换需要自定义脚本实现。
优点:
缺点:
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 协议同步节点信息。
优点:
缺点:
From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster
多个同构 Twemproxy(配置相同)同时工作,接受客户端的请求,根据 hash 算法,转发给对应的 Redis。
Twemproxy 方案比较成熟了,之前我们团队长期使用此方案,但是效果并不是很理想。一方面是定位问题比较困难,另一方面是它对自动剔除节点的支持不是很友好。
优点:
缺点:
From: https://github.com/CodisLabs/codis
Codis是由豌豆荚开源的产品,涉及组件众多,其中 ZooKeeper 存放路由表和代理节点元数据、分发 Codis-Config 的命令;Codis-Config 是集成管理工具,有 Web 界面供使用;Codis-Proxy 是一个兼容 Redis 协议的无状态代理;Codis-Redis 基于 Redis 2.8 版本二次开发,加入 slot 支持,方便迁移数据。
优点:
缺点:
所谓的最佳实践,都是最适合具体场景的实践。
主推以下方案:
以下是实战过程中总结出的最佳实践:
paramiko
库,避免重复建立 SSH 连接,消耗时间此次活动分享了 Redis 高可用的必要性、Sentinel 原理、Redis 高可用常用架构和实战过程中总结出的最佳实践,希望对读者有所帮助,如果有需要后续交流的,可以添加我的微信( Wentasy),或者发邮件到: [email protected]
附 PPT 下载: https://github.com/dbarobin/slides
视频回放: Redis 高可用架构最佳实践
感谢听云和运维帮的精心组织,感谢大家冒着大雨前来参加此次活动。此次分享由 IT 大咖说全程录像,感谢 IT 大咖说的技术支持。
听云
听云是国内领先的应用性能管理(APM)解决方案提供商,拥有听云 App、听云 Server、听云 Browser、听云 Network、听云 Sys 五条重要产品线。从移动客户端到服务器端再到网络层面,全方位帮助客户实时监控定位从崩溃、报错、代码效率质量低下、交互过慢、第三方API调用监测、到网络环境出错等多维度复杂的性能问题。
运维帮
互联网技术分享平台,分享的力量。帮主一直坚信技术可以改变世界,从毕业到现在干了 15 年运维,有许多话要和你说。
IT 大咖说
IT 大咖说,践行 “开源是一种态度”,通过线上线下开放模式分享大咖干货。 技术大会在线直播点播,在线直播知识分享平台,让不在现场的程序猿、攻城狮不再遗憾,随时随地都能获得大咖的精彩分享。IT 大咖说,让智慧流动起来!
温国兵,曾任职于酷狗音乐,现为三七互娱 DBA。目前主要关注领域:数据库自动化运维、高可用架构设计、数据库安全、海量数据解决方案、以及开源技术在互联网中的应用。
本文首发于 听云。
–EOF–
版权声明:自由转载-非商用-非衍生-保持署名 (创意共享4.0许可证)