AI 助理
备案控制台
开发者社区 数据库 文章 正文

唯品会Redis cluster大规模生产实践经验

2017-07-03 4913
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
Redis 开源版，标准版 2GB
推荐场景：
搭建游戏排行榜
云数据库 Tair（兼容Redis），内存型 2GB
推荐场景：
通过缓存加速数据库访问
简介：

嘉宾：陈群
很高兴有机会给大家分享redis cluster的生产实践经验。目前在唯品会主要负责redis/hbase的运维和开发支持工作，也参与工具开发工作。

Outline
一、生产应用场景
二、存储架构演变
三、应用最佳实践
四、运维经验总结
第1、2节：介绍redis cluster在唯品会的生产应用场景，以及存储架构的演变。
第3节：redis cluster的稳定性，应用成熟度，踩到过那些坑，如何解决这些问题？这部分是大家比较关心的内容。
第4节：简单介绍大规模运营的一些经验，包括部署、监控、管理以及redis工具开发。

一、生产应用场景
1、业务范围
redis cluster在唯品会主要应用于后端业务，用作内存存储服务。主要大数据实时推荐/ETL、风控、营销三大业使用。cluster用于取代当前twemproxy三层架构，作为通用的存储架构。redis cluster可以大幅度简化我们的存储架构，也解决twemproxy架构无法在线扩容节点的问题。目前我们在线有生产几十个cluster集群，约2千个instances，单个集群最大达到250+instances。
这是我们的生产应用场景，主要是后端业务的存储，目前没有作为cache使用的场景。

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。
  • 大促销活动时扩容频繁。


3、为什么选择redis cluster3.1 cluster适合我们后端生产应用场景

  • 在线水平扩展能力，能够解决我们大量的扩容需求。
  • Failover能力和高可用性。
  • 虽然cluster不保证主从数据强一致性，但是后端业务能够容忍failover后少量的数据丢失。

3.2 架构简单

  • 无中心架构，各个节点度等。slave节点提供数据冗余，master节点异常时提升为master。
  • 取代twemproxy三层架构，系统复杂性降低。
  • 可以节约大量的硬件资源，我们的Lvs + Twemproxy层 使用了近上千台物理机器。
  • 少了lvs和twemproxy层，读写性能提升明显。响应时间从100-200us减少到50-100us。
  • 系统瓶颈更少。lvs层网卡和pps吞吐量瓶颈;对于请求长度较大的业务，twemproxy单节点性能低。
    总结下，我们选择redis cluster主要这两点原因：简单、扩展性。另外，我们用cluster取代twemproxy集群，三层架构实在是很令人头疼，复杂、瓶颈多、管理不方面。


二、存储架构演变

1、架构演变
<ignore_js_op style="word-wrap: break-word; color: rgb(68, 68, 68); font-family: Tahoma, Helvetica, SimSun, sans-serif;"> 

在2014年7月，为了准备当时的814撒娇节大促销活动，我们把单个redis的服务迁移到twemproxy上。twemproxy在后端快速完成数据分片和扩容。为了避免再次扩容，我们静态分配足够多的资源。
之后，twemproxy暴露出来的系统瓶颈很多，资源使用很多，也存在一定的浪费。我们决定用redis cluster取代这种复杂的三层架构。
redis cluster GA之后，我们就开始上线使用。最初是3.0.2 版本，后面大量使用3.0.3 ，上个月开始使用3.0.7版本。
下面简单对比下两种架构，解析下他们的优缺点。

2、Twemproxy架构优点

  • sharding逻辑对开发透明，读写方式和单个redis一致。
  • 可以作为cache和storage的proxy（by auto-eject）。


缺点

  • 架构复杂，层次多。包括lvs、twemproxy、redis、sentinel和其控制层程序。
  • 管理成本和硬件成本很高。
  • 2 * 1Gbps 网卡的lvs机器，最大能支撑140万pps。
  • 流量高的系统，proxy节点数和redis个数接近。
  • Redis层仍然扩容能力差，预分配足够的redis存储节点。

<ignore_js_op style="word-wrap: break-word; color: rgb(68, 68, 68); font-family: Tahoma, Helvetica, SimSun, sans-serif;"> 


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

3、Redis Cluster架构优点

  • 无中心 架构。
  • 数据按照slot存储分布在多个redis实例上。
  • 增加slave做standby数据副本，用于failover，使集群快速恢复。
  • 实现故障auto failover。节点之间通过gossip协议交换状态信息；投票机制完成slave到master角色的提升。
  • 亦可manual failover，为升级和迁移提供可操作方案。
  • 降低硬件成本和运维成本，提高系统的扩展性和可用性。


缺点和不足的地方

  • client实现复杂，驱动要求实现smart client，缓存slots mapping信息并及时更新。
  • 目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
  • 客户端的不成熟，影响应用的稳定性，提高开发难度。
  • 节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout），被判断下线。这种failover是没有必要，sentinel也存在这种切换场景。
    cluster的架构如下：

<ignore_js_op style="word-wrap: break-word; color: rgb(68, 68, 68); font-family: Tahoma, Helvetica, SimSun, sans-serif;"> 


图上只有master节点（slave略去），所有节点构成一个完全图,slave节点在集群中与master只有角色和功能的区别。
架构演变讲完了,开始讲第三部分，也是大家最感兴趣的一部分。

三、应用最佳实践

  • redis cluster的稳定性如何？
  • 存在哪些坑?
  • develop guideline & best practice


1、稳定性

  • 不扩容时集群非常稳定。
  • 扩容resharding时候，早期版本的Jedis端有时会出现“max-redirect”异常。
    分析Jedis源码，请求重试次数达到了上限，仍然没有请求成功。两方面分析：redis连接不上？还是集群节点信息不一致？
  • 存活检测机制缺陷
      redis 存活检测机制可能因为master 节点上慢查询、阻塞式命令、或者其它的性能问题导致长时间没有响应，这个节点会认为处于failed状态，并进行切换。这种切换是没必要的。    优化策略：a) 默认的cluster-node-timeout为15s，可以适当增大;
    b) 避免使用会引起长时间阻塞的命令，比如save/flushdb等阻塞操作，或者keys pattern这种慢查询。

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

2、有哪些坑？

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


2.3 同时支持ipv4和ipv6侦听服务埋下的坑
具体现象：redis启动正常，节点的协议端口只有ipv6 socket创建正常。异常节点也无法加入到集群中，也无法获取epoch。
解决方法：启动时指定网卡ipv4地址，也可以是0.0.0.0，配置文件中添加：bind 0.0.0.0
这个是在setup集群的时候发生过的一个问题，bind 0.0.0.0虽然存在一些安全性问题，但是是比较简单通用的解决方法。

2.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修复集群状态。


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

四、运维经验总结1、自动化管理

  • CMDB管理所有的资源信息。
  • Agent方式上报硬软件信息。
  • 标准化基础设置。机型、OS内核参数、软件版本。
  • Puppet管理和下发标准化的配置文件、公用的任务计划、软件包、运维工具。
  • 资源申请自助服务。


2、自动化监控

  • zabbix作为主要的监控数据收集工具。
  • 开发实时性能dashboard，对开发提供查询。
  • 单机部署多个redis，借助于zabbix discovery。
  • 开发DB响应时间监控工具Titan。
  • 基本思想来源于pt-query-degest，通过分析tcp应答报文产生日志。flume agent + kafka收集，spark实时计算，hbase作为存储。最终得到hotquery/slowquery，request source等性能数据。


3、自动化运维

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


4、redis开源工具介绍4.1 redis实时数据迁移工具
1） 在线实时迁移
2） redis/twemproxy/cluster 异构集群之间相互迁移。
3）github：https://github.com/vipshop/redis-migrate-tool 

4.2 redis cluster管理工具
1）批量更改集群参数
2）clusterrebalance
3）很多功能，具体看github ：
https://github.com/deep011/redis-cluster-tool

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

4.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操作。如果是大批量的操作，可以用多线程提高客户端的吞吐量。

附录：
嘉宾微信：qunchenmy
技术博客：[http://mdba.cn]
微博：[http://weibo.com/sylarqun]
Redis中国用户组官网：[http://redis.cn]
Redis知识图谱：
           [http://lib.csdn.net/base/redis]
           [http://lib.csdn.net/mobile/base/34]


原文链接：http://www.jianshu.com/p/ee2aa7fe341b
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。


原文链接:[http://wely.iteye.com/blog/2360419]

文章标签：
云数据库 Tair（兼容 Redis）
Redis
NoSQL
存储
Java
监控
关键词：
云数据库 Tair（兼容 Redis）实践
云数据库 Tair（兼容 Redis）Cluster
云数据库 Tair（兼容 Redis）生产
云数据库 Tair（兼容 Redis）cluster实践
唯品会云数据库 Tair（兼容 Redis）
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务，基于高可靠双机热备架构及可无缝扩展的集群架构，满足高读写性能场景及容量需弹性变配的业务需求。 产品详情：https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验：数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引，您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接，领取免费ECS&amp;RDS资源，30分钟完成数据库上云实战！https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
行者武松
目录
相关文章
小陈运维
|
4月前
|
存储 运维 NoSQL
Redis Cluster集群模式部署
Redis Cluster集群模式部署
小陈运维
105 4
服务端技术栈
|
2月前
|
存储 NoSQL 算法
深入理解Redis分片Cluster原理
本文深入探讨了Redis Cluster的分片原理，作为Redis官方提供的高可用性和高性能解决方案，Redis Cluster通过数据分片和横向扩展能力，有效降低单个主节点的压力。
服务端技术栈
65 1
深入理解Redis分片Cluster原理
小王老师呀
|
1月前
|
消息中间件 NoSQL Go
PHP转Go系列 | ThinkPHP与Gin框架之Redis延时消息队列技术实践
【9月更文挑战第7天】在从 PHP 的 ThinkPHP 框架迁移到 Go 的 Gin 框架时，涉及 Redis 延时消息队列的技术实践主要包括：理解延时消息队列概念，其能在特定时间处理消息，适用于定时任务等场景；在 ThinkPHP 中使用 Redis 实现延时队列；在 Gin 中结合 Go 的 Redis 客户端库实现类似功能；Go 具有更高性能和简洁性，适合处理大量消息。迁移过程中需考虑业务需求及系统稳定性。
小王老师呀
36 0
路边两盏灯
|
2月前
|
缓存 NoSQL 网络协议
【Azure Redis 缓存】Azure Redis Cluster 在增加分片数时失败分析
【Azure Redis 缓存】Azure Redis Cluster 在增加分片数时失败分析
路边两盏灯
33 0
路边两盏灯
|
2月前
|
缓存 NoSQL Redis
【Azure Redis 缓存】Windows版创建 Redis Cluster 实验 （精简版）
【Azure Redis 缓存】Windows版创建 Redis Cluster 实验 （精简版）
路边两盏灯
37 0
。思索
|
2月前
|
NoSQL Redis
Redis——单机迁移cluster集群如何快速迁移
Redis——单机迁移cluster集群如何快速迁移
。思索
50 0
龙蜥社区（OpenAnolis）
|
4月前
|
网络协议 NoSQL Redis
SMC-R 透明加速 TCP 技术，在 Redis 场景下的应用实践 | 干货推荐
SMC-R 作为一套与 TCP/IP 协议平行、向上兼容 socket 接口、底层使用 RDMA 完成共享内存通信的内核协议栈，其设计意图是为 TCP 应用提供透明的 RDMA 服务，同时保留了 TCP/IP 生态系统中的关键功能。
龙蜥社区（OpenAnolis）
115 3
玉米侠爱吃玉米
|
5月前
|
存储 负载均衡 监控
redis 集群模式（redis cluster）介绍
redis 集群模式（redis cluster）介绍
玉米侠爱吃玉米
1172 1
dream_ready
|
3天前
|
缓存 NoSQL 关系型数据库
redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿
本文深入探讨了Redis缓存的相关知识，包括缓存的概念、使用场景、可能出现的问题（缓存预热、缓存穿透、缓存雪崩、缓存击穿）及其解决方案。
dream_ready
15 0
redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿
程序员小海绵
|
28天前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性？同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度，提出多种解决方案：同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
程序员小海绵
132 5
Redis缓存与数据库如何保证一致性？同步删除+延时双删+异步监听+多重保障方案

热门文章

最新文章

  • 1
    Redis学习之基础命令
  • 2
    Mac安装、配置redis
  • 3
    Redis 3.0 Cluster集群配置
  • 4
    手把手redis集群的搭建
  • 5
    全内存的redis用习惯了？那能突破内存限制类redis产品ssdb呢？
  • 6
    Redis自学笔记–Zset类型及管理简述
  • 7
    Redis远程连接工具，安装教程，附安装包(重要)！
  • 8
    3.Redis实现问题
  • 9
    在java中使用redis
  • 10
    使用elk+redis搭建nginx日志分析平台(转)
  • 1
    Redis缓存雪崩及应对策略
    103
  • 2
    Redis数据存储系统为什么快？
    53
  • 3
    Redis常用数据类型及常用命令
    53
  • 4
    Redis的特点和应用场景
    88
  • 5
    透视Redis集群：心跳检测如何维护高可用性
    373
  • 6
    探秘Redis分布式锁：实战与注意事项
    403
  • 7
    优化Redis缓存：解决性能瓶颈和容量限制
    218
  • 8
    【Redis系列笔记】Redis总结
    157
  • 9
    【Redis系列笔记】Redis入门
    171
  • 10
    redis的应用场景
    60

    • 相关课程

    更多
  • 大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第一阶段
  • 大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第四阶段
  • 大数据实战项目 - 反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第七阶段
  • Redis入门实战演练
  • 云数据库 Redis 版使用教程
  • Redis数据库入门

    • 相关电子书

    更多
  • Redis在唯品会的应用实践——架构演进与功能定制
  • 微博的Redis定制之路
  • 云数据库Redis版的开源之路

    • 相关实验场景

    更多
  • 倚天大数据电商数据分析快速实践
  • 利用大模型大规模分发技术，实现AIGC在线应用秒级弹性
  • 基于Flink+Tair搭建实时监控大屏
  • AnalyticDB MySQL游戏行业数据分析实践
  • 【企业数据中台交付】数据回刷实验
  • 灵活弹性的PolarDB Serverless确保数据业务持续在线
    • 下一篇
    阿里云对象存储OSS怎么收费？包年包月和按量付费价格表