唯品会大规模 Redis Cluster 的生产实践

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介:

文章来源:http://h2ex.com/1117?utm_source=tuicool&utm_medium=referral


关于嘉宾

陈群,目前在唯品会主要负责redis/hbase的运维和开发支持工作,也参与工具开发工作。

本文是陈辉同学在Redis中国用户组给大家分享redis cluster的生产实践。

分享大纲

本次分享内容如下:

1、生产应用场景
2、存储架构演变
3、应用最佳实践
4、运维经验总结

关于这4部分的内容介绍:

  • 第1、2部分:介绍redis cluster在唯品会的生产应用场景,以及存储架构的演变。

  • 第3部分:redis cluster的稳定性,应用成熟度,踩到过那些坑,如何解决这些问题?这部分是大家比较关系的内容。

  • 第4部分:简单介绍大规模运营的一些经验,包括部署、监控、管理以及redis工具开发。

1、生产应用场景

1.1 业务范围

redis cluster在唯品会主要应用于后端业务,用作内存存储服务。主要大数据实时推荐/ETL、风控、营销三大业使用。

cluster用于取代当前twemproxy三层架构,作为通用的存储架构。redis cluster可以大幅度简化我们的存储架构,也解决twemproxy架构无法在线扩容节点的问题。

目前我们在线有生产几十个cluster集群,约2千个instances,单个集群最大达到250+instances。

这是我们的生产应用场景,主要是后端业务的存储,目前没有作为cache使用的场景。

1.2大数据、风控、营销系统的特征

  • cluster 一般数据量大, 单个cluster集群在几十个GB到上TB级别内存存储量。

  • 作为后端应用的存储,数据来源主要以下三种方式:

    • Kafka → Redis Cluster,Storm/Spark实时

    • Hive →  Redis Cluster,  MapReduce程序

    • MySQL →  Redis Cluster,Java/C++程序。

  • 数据由离线/实时job生成, 读写请求量大, 对读写性能也要求高。

  • 业务高峰期请求量急剧上升,几倍的读写量增加,需要多个redis实例承担业务的读写压力。

  • 业务需求变化快, schema变化频繁。如果使用MySQL作为存储,那么将会是频繁的DLL变更,而且需要做online schema change。

  • 大促销活动时扩容频繁。

1.3、为什么选择redis cluster

1) cluster适合我们后端生产应用场景

  • 在线水平扩展能力,能够解决我们大量的扩容需求。

  • Failover能力和高可用性。

  • 虽然cluster不保证主从数据强一致性,但是后端业务能够容忍failover后少量的数据丢失。

2) 架构简单

  • 无中心架构,各个节点度等。slave节点提供数据冗余,master节点异常时提升为master。

  • 取代twemproxy三层架构,系统复杂性降低。

  • 可以节约大量的硬件资源,我们的Lvs + Twemproxy层 使用了近上千台物理机器。

  • 少了lvs和twemproxy层,读写性能提升明显。响应时间从100-200us减少到50-100us。

  • 系统瓶颈更少。lvs层网卡和pps吞吐量瓶颈;对于请求长度较大的业务,twemproxy单节点性能低。
    总结下,我们选择redis cluster主要这两点原因:简单、扩展性。另外,我们用cluster取代twemproxy集群,三层架构实在是很令人头疼,复杂、瓶颈多、管理不方面。

2、存储架构演变

2.1 架构演变

在2014年7月,为了准备当时的814撒娇节大促销活动,我们把单个redis的服务迁移到twemproxy上。twemproxy在后端快速完成数据分片和扩容。为了避免再次扩容,我们静态分配足够多的资源。

之后,twemproxy暴露出来的系统瓶颈很多,资源使用很多,也存在一定的浪费。我们决定用redis cluster取代这种复杂的三层架构。

redis cluster GA之后,我们就开始上线使用。最初是3.0.2 版本,后面大量使用3.0.3 ,上个月开始使用3.0.7版本。

下面简单对比下两种架构,解析下他们的优缺点。

2.2 Twemproxy架构

1)优点

  • sharding逻辑对开发透明,读写方式和单个redis一致。

  • 可以作为cache和storage的proxy(by auto-eject)。

2)缺点

  • 架构复杂,层次多。包括lvs、twemproxy、redis、sentinel和其控制层程序。

  • 管理成本和硬件成本很高。

  • 2 * 1Gbps 网卡的lvs机器,最大能支撑140万pps。

  • 流量高的系统,proxy节点数和redis个数接近。

  • Redis层仍然扩容能力差,预分配足够的redis存储节点。

这是twemproxy的架构,客户端直接连接最上面的lvs(LB),第二层是同构的twemproxy节点,下面的redis master节点以及热备的slave节点,另外还有独立的sentinel集群和切换控制程序,twemproxy先介绍到这里。

2.3 Redis Cluster架构

1)优点

  • 无中心架构。

  • 数据按照slot存储分布在多个redis实例上。

  • 增加slave做standby数据副本,用于failover,使集群快速恢复。

  • 实现故障auto failover。节点之间通过gossip协议交换状态信息;投票机制完成slave到master角色的提升。

  • 亦可manual failover,为升级和迁移提供可操作方案。

  • 降低硬件成本和运维成本,提高系统的扩展性和可用性。

2)缺点

  • client实现复杂,驱动要求实现smart client,缓存slots mapping信息并及时更新。

  • 目前仅JedisCluster相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。

  • 客户端的不成熟,影响应用的稳定性,提高开发难度。

  • 节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout),被判断下线。这种failover是没有必要,sentinel也存在这种切换场景。

cluster的架构如下:

图上只有master节点(slave略去),所有节点构成一个完全图,slave节点在集群中与master只有角色和功能的区别。

架构演变讲完了,开始讲第三部分,也是大家最感兴趣的一部分.

3、应用最佳实践

本部分包括内容如下:

  • redis cluster的稳定性如何?

  • 存在哪些坑?

  • develop guideline & best practice

3.1 稳定性

  • 不扩容时集群非常稳定。

  • 扩容resharding时候,早期版本的Jedis端有时会出现“max-redirect”异常。
    分析Jedis源码,请求重试次数达到了上限,仍然没有请求成功。两方面分析:redis连接不上?还是集群节点信息不一致?

  • 存活检测机制缺陷
    redis 存活检测机制可能因为master 节点上慢查询、阻塞式命令、或者其它的性能问题导致长时间没有响应,这个节点会认为处于failed状态,并进行切换。这种切换是没必要的。

优化策略:

a) 默认的cluster-node-timeout为15s,可以适当增大;

b) 避免使用会引起长时间阻塞的命令,比如save/flushdb等阻塞操作,或者keys pattern这种慢查询。

总体来说,redis cluster已经非常稳定了,但是要注意一些应用中的小问题,下面是5个坑,大家注意了.

3.2 有哪些坑?

1)迁移过程中Jedis“Max Redirect”异常。

  • github上讨论的结果是程序retry。

  • max redirt issues:https://github.com/xetorthio/jedis/issues/1238

  • retry时间应该大于failover 时间。

  • Jedis参数优化调整:增大jedis中的‘DEFAULT_MAX_REDIRECTIONS’参数,默认值是5.

  • 避免使用multi-keys操作,比如mset/mget. multi-key操作有些客户端没有支持实现。

2)长时间阻塞引起的不必要的failover

  • 阻塞的命令。比如save/flushall/flushdb

  • 慢查询。keys *、大key的操作、O(N)操作

  • rename危险操作:

    • rename-command FLUSHDB REDIS_FLUSHDB

    • rename-command FLUSHALL REDIS_FLUSHALL

    • rename-command KEYS REDIS_KEYS

3)同时支持ipv4和ipv6侦听服务埋下的坑

具体现象:redis启动正常,节点的协议端口只有ipv6 socket创建正常。异常节点也无法加入到集群中,也无法获取epoch。

解决方法:启动时指定网卡ipv4地址,也可以是0.0.0.0,配置文件中添加:bind 0.0.0.0

这个是在setup集群的时候发生过的一个问题,bind 0.0.0.0虽然存在一些安全性问题,但是是比较简单通用的解决方法。

4)数据迁移速度较慢

  • 主要使用的redis-trib.rb reshard来完成数据迁移。

  • redis-3.0.6版本以前migrate操作是单个key逐一操作。从redis-3.0.6开始,支持单次迁移多个key。

  • redis集群内部最多只允许一个slot处于迁移状态,不能并发的迁移slots。

  • redis-trib.rb reshard如果执行中断,用redis-trib.rb fix修复集群状态。

5)版本选择/升级建议
  • 我们已经开始使用3.0.7版本,很多3.2.0修复的bug已经backport到这个版本。

  • 另外我们也开始测试3.2.0版本,内存空间优化很大。

  • Tips

    • redis-trib.rb支持resharding/rebalance,分配权重。

    • redis-trib.rb支持从单个redis迁移数据到cluster集群中。

后面2点不算坑把,算是不足,tips也很实用。开始分享下最佳实践。

3、最佳实践

3.1 应用做好容错机制

  • 连接或者请求异常,进行连接retry和reconnect。

  • 重试时间应该大于cluster-node-time时间
    还是强调容错,这个不是针对cluster,所有的应用设计都适用。

3.2 制定开发规范

  • 慢查询,进程cpu 100%、客户端请求变慢,甚至超时。

  • 避免产生hot-key,导致节点成为系统的短板。

  • 避免产生big-key,导致网卡打爆、慢查询。

  • TTL, 设置合理的ttl,释放内存。避免大量key在同一时间段过期,虽然redis已经做了很多优化,仍然会导致请求变慢。

  • key命名规则。

  • 避免使用阻塞操作,不建议使用事务。
    开发规范,使你们的开发按照最优的方式使用nosql。

3.3 优化连接池使用

  • 主要避免server端维持大量的连接。

  • 合理的连接池大小。

  • 合理的心跳检测时间。

  • 快速释放使用完的连接。

  • Jedis一个连接创建异常问题(fixed):
    https://github.com/xetorthio/jedis/issues/1252

连接问题是redis开发使用中最常见的问题,connection timeout/read timeout,还有borrow connection的问题。

3.4 区分redis/twemproxy和cluster的使用

  • redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率。

  • twemproxy也支持pipeline, 支持部分的multi-key可以操作。

  • redis cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。

区分redis 和 cluster的使用,一方面是数据分片引起的;另一方面,与client的实现支持相关。

3.5 几个需要调整的参数

1)设置系统参数vm.overcommit_memory=1,可以避免bgsave/aofrewrite失败。

2)设置timeout值大于0,可以使redis主动释放空闲连接。

3)设置repl-backlog-size 64mb。默认值是1M,当写入量很大时,backlog溢出会导致增量复制不成功。

4)client buffer参数调整
client-output-buffer-limit normal 256mb 128mb 60
client-output-buffer-limit slave  512mb  256mb 180

4、运维经验总结

4.1 自动化管理

  • CMDB管理所有的资源信息。

  • Agent方式上报硬软件信息。

  • 标准化基础设置。机型、OS内核参数、软件版本。

  • Puppet管理和下发标准化的配置文件、公用的任务计划、软件包、运维工具。

  • 资源申请自助服务。

4.2 自动化监控

  • zabbix作为主要的监控数据收集工具。

  • 开发实时性能dashboard,对开发提供查询。

  • 单机部署多个redis,借助于zabbix discovery。

  • 开发DB响应时间监控工具Titan。

  • 基本思想来源于pt-query-degest,通过分析tcp应答报文产生日志。flume agent + kafka收集,spark实时计算,hbase作为存储。最终得到hotquery/slowquery,request source等性能数据。

4.3 自动化运维

  • 资源申请自助服务化。

  • 如果申请合理,一键即可完成cluster集群部署。
    能不动手的,就坚决不动手,另外,监控数据对开发开发很重要,让他们了解自己服务性能,有时候开发会更早发现集群的一些异常行为,比如数据不过期这种问题,运维就讲这么多了,后面是干货中的干货,由deep同学开发的几个实用工具。

4.4 redis开源工具介绍

1) redis实时数据迁移工具

1)在线实时迁移
2)redis/twemproxy/cluster 异构集群之间相互迁移。
3)github:https://github.com/vipshop/redis-migrate-tool

2) redis cluster管理工具

1)批量更改集群参数
2)clusterrebalance
3)很多功能,具体看github :
https://github.com/deep011/redis-cluster-tool

3) 多线程版本Twemproxy

1)大幅度提升单个proxy的吞吐量,线程数可配置。
2)压测情况下,20线程达到50w+qps,最优6线程达到29w。
3)完全兼容twemproxy。
4)github:
https://github.com/vipshop/twemproxies

4) 在开发的中的多线redis

1)Github:
https://github.com/vipshop/vire

2)欢迎一起参与协作开发,这是我们在开发中的项目,希望大家能够提出好的意见。

互动环节(陈群和申政解答)

问题1:版本更新,对数据有没有影响?

答:我们重启升级从2.8.17到3.0.3/3.0.7没有任何的异常。3.0到3.2我们目前还没有实际升级操作过。

问题2:请问下sentinel模式下有什么好的读写分离的方法吗

答:我们没有读写分离的使用,读写都在maste;集群太多,管理复杂;此外,我们也做了分片,没有做读写分离的必要;且我们几乎是一主一从节点配置

问题3:redis的fork主要是为了rdb吧,去掉是为了什么呢

答:fork不友好

问题4:如果不用fork,是怎么保证rdb快照是精确的,有其他cow机制么

答:可以通过其他方法,这个还在探究阶段,但目标是不用fork

问题5:就是redis cluster模式下批量操作会有很多问题,可是不批量操作又会降低业务系统的性能

答:确实存在这方面的问题,这方面支持需要客户端的支持,但是jedis的作者也不大愿意支持pipeline或者一些multi key操作。如果是大批量的操作,可以用多线程提高客户端的吞吐量。


本文转自    鹏爱   51CTO博客,原文链接:
http://blog.51cto.com/pengai/1837266
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
4月前
|
存储 运维 NoSQL
Redis Cluster集群模式部署
Redis Cluster集群模式部署
104 4
|
5月前
|
存储 监控 负载均衡
redis 集群 (主从复制 哨兵模式 cluster)
redis 集群 (主从复制 哨兵模式 cluster)
|
2月前
|
存储 NoSQL 算法
深入理解Redis分片Cluster原理
本文深入探讨了Redis Cluster的分片原理,作为Redis官方提供的高可用性和高性能解决方案,Redis Cluster通过数据分片和横向扩展能力,有效降低单个主节点的压力。
深入理解Redis分片Cluster原理
|
26天前
|
消息中间件 NoSQL Go
PHP转Go系列 | ThinkPHP与Gin框架之Redis延时消息队列技术实践
【9月更文挑战第7天】在从 PHP 的 ThinkPHP 框架迁移到 Go 的 Gin 框架时,涉及 Redis 延时消息队列的技术实践主要包括:理解延时消息队列概念,其能在特定时间处理消息,适用于定时任务等场景;在 ThinkPHP 中使用 Redis 实现延时队列;在 Gin 中结合 Go 的 Redis 客户端库实现类似功能;Go 具有更高性能和简洁性,适合处理大量消息。迁移过程中需考虑业务需求及系统稳定性。
|
2月前
|
缓存 NoSQL 网络协议
【Azure Redis 缓存】Azure Redis Cluster 在增加分片数时失败分析
【Azure Redis 缓存】Azure Redis Cluster 在增加分片数时失败分析
|
2月前
|
缓存 NoSQL Redis
【Azure Redis 缓存】Windows版创建 Redis Cluster 实验 (精简版)
【Azure Redis 缓存】Windows版创建 Redis Cluster 实验 (精简版)
|
2月前
|
NoSQL Redis
Redis——单机迁移cluster集群如何快速迁移
Redis——单机迁移cluster集群如何快速迁移
47 0
|
4月前
|
网络协议 NoSQL Redis
SMC-R 透明加速 TCP 技术,在 Redis 场景下的应用实践 | 干货推荐
SMC-R 作为一套与 TCP/IP 协议平行、向上兼容 socket 接口、底层使用 RDMA 完成共享内存通信的内核协议栈,其设计意图是为 TCP 应用提供透明的 RDMA 服务,同时保留了 TCP/IP 生态系统中的关键功能。
|
5月前
|
存储 负载均衡 监控
redis 集群模式(redis cluster)介绍
redis 集群模式(redis cluster)介绍
|
5月前
|
存储 缓存 运维
软件体系结构 - 缓存技术(5)Redis Cluster
【4月更文挑战第20天】软件体系结构 - 缓存技术(5)Redis Cluster
177 10
下一篇
无影云桌面