Redis集群“倾斜”问题

标签: Redis Redis | 发表时间:2016-08-03 23:50 | 作者:
出处:http://yoursite.com/

对分布式存储系统的架构和运维管理,如何保证每个Node的数据存储容量和请求量尽量均衡,是非常重要的。
本文介绍Redis大集群运维过程中,常见导致数据和请求量“倾斜”的场景,及规避措施。


Redis数据容量或请求量严重”倾斜”的影响

以下从运维的角度解释,Redis数十节点的集群,出现数据容量和请求量倾斜情况下,存在的一些痛点:

  • 少数或单个节点请求量”过热”,导致Redis分布式系统失去可扩展性能力和集群的意义。类似MongoDB_id字段作为片键。
  • 导致运维容量规划,扩容处理难度大。
  • 增大自动化配置管理难度;单集群节点尽量统一参数配置。
  • 监控告警复杂(容量,QPS,连接数的阈值等)

那我们再看生产环境中,常见导致Redis集群严重“倾斜”的场景

Redis集群常见“倾斜”的场景

这类问题一般DBA规划不当,业务键空间(keyspace)设计不合理等问题导致

  • DBA在规划集群时或扩容后,导致数据槽(哈希桶)位分配不均匀;引起内存容量、键个数和请求QPS倾斜
  • 业务的键空间设计不合理,所谓”热点key”,导致某少量KEY的QPS操作很大;这类节点QPS过载
  • 程序大量使用 Keys hash tags, 可能导致某些数据槽位的键个数较多
  • 程序存在大的集群key(hash,set,list等),导致大key所在节点的容量和QPS过高
  • 工和师执行Monitor这类命令,导致当前节点client输出缓冲区增大;used_memory_rss被撑大;导致节点内存容量增大

接下来,当集群出现内存容量、键数量或QPS请求量严重倾斜时,我们应该排查定位问题呢?

Redis集群“倾斜”问题排查

检查集群每个分片的数据槽分配是否均匀

下面以Redis Cluster集群为例
确认集群中,每个节点负责的数据槽位(slots)和key个数。下面demo的部分实例存在不轻度“倾斜”
但不严重,可考虑进行reblance.

      
1
2
3
4
5
6
7
8
9
10
11
      
redis-trib.rb info redis_ip:port
nodeip:port (5e59101a...) -> 44357924 keys | 617 slots | 1 slaves.
nodeip:port (72f686aa...) -> 52257829 keys | 726 slots | 1 slaves.
nodeip:port (d1e4ac02...) -> 45137046 keys | 627 slots | 1 slaves.
---------------------省略------------------------
nodeip:port (f87076c1...) -> 44433892 keys | 617 slots | 1 slaves.
nodeip:port (a7801b06...) -> 44418216 keys | 619 slots | 1 slaves.
nodeip:port (400bbd47...) -> 45318509 keys | 614 slots | 1 slaves.
nodeip:port (c90a36c9...) -> 44417794 keys | 617 slots | 1 slaves.
[OK] 1186817927 keys in 25 masters.
72437.62 keys per slot on average.

排查节点热点Key,确定top commands.

使用 redis-faina,当然有实时分析平台就更好。
从以下示例中,可见两个前缀key的QPS占比基本各为50%, 明显热点key;也能看到auth命令的异常(top commands)

      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
      
Overall Stats
========================================
Lines Processed 100000
Commands/Sec 7276.82
Top Prefixes
========================================
ar_xxx 49849 (49.85%)
Top Keys
========================================
c8a87fxxxxx 49943 (49.94%)
a_r:xxxx 49849 (49.85%)
Top Commands
========================================
GET 49964 (49.96%)
AUTH 49943 (49.94%)
SELECT 88 (0.09%)

程序是否大量使用Keys hash tags

可能导致数据存储内存量,QPS都不均匀的问题;
可使用scan扫描keyspace是否有使用hash tags的,或使用monitor, vc-redis-sniffer

程序是否使用较大的集合键

比如1kw个字段的hash key, 内存占用在几个GB. 这类集合key每次操作几个字段,很难从proxy或sdk发现key的大小。 可通过redis-cli –bigkeys

      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
      
redis-cli --bigkeys -p 7000
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest string found so far 'key:000000019996' with 1024 bytes
[48.57%] Biggest list found so far 'mylist' with 534196 items
-------- summary -------
Sampled 8265 keys in the keyspace!
Total key length in bytes is 132234 (avg len 16.00)
Biggest string found 'key:000000019996' has 1024 bytes
Biggest list found 'mylist' has 534196 items
8264 strings with 8460296 bytes (99.99% of keys, avg size 1023.75)
1 lists with 534196 items (00.01% of keys, avg size 534196.00)

确认是否因monitor命令引起的输出缓冲区占用内存过大的问题

这类情况基本Redis实例内存会快速增长,很快会出现回落。通过监测client输出缓冲区使用情况

     
1
2
3
4
5
6
7
8
9
10
11
     
2.5.1 通过监控client_longest_output_list输出列表的长度,是否有client使用大量的输出缓冲区.
redis-cli -p 7000 info clients
# Clients
connected_clients:52
client_longest_output_list:9179
client_biggest_input_buf:0
blocked_clients:0
2.5.2 查看输出缓冲区列表长度不为0的client。 可见monitor占用输出缓冲区370MB
redis-cli -p 7000 client list | grep -v "oll=0"
id=1840 addr=xx64598 age=75 idle=0 flags=O obl=0 oll=15234 omem=374930608 cmd=monitor

如何有效避免Redis集群“倾斜”问题

  • 集群部署和扩容处理,保证数据槽位分配平均
  • keyspace设计时,如何避免热点key, 打散热key
  • 业务在键空间设计时,中尽量避免使用大的集合类型的Key,把key设计拆分
  • 程序角度尽量避免使用keys hash tag
  • 避免工程师直接使用keys,monitor等命令,导致输出缓冲区堆积.
  • 合量配置normal的client output buffer, 建议设置10mb(警示:和业务确认调整再修改,避免业务出错)

在实际生产业务场景中,大规模集群很难做到集群的完全均衡,只是尽量保证不出现严重倾斜问题。

相关 [redis 集群 问题] 推荐:

Redis集群“倾斜”问题

- - 今天
对分布式存储系统的架构和运维管理,如何保证每个Node的数据存储容量和请求量尽量均衡,是非常重要的. 本文介绍Redis大集群运维过程中,常见导致数据和请求量“倾斜”的场景,及规避措施. Redis数据容量或请求量严重”倾斜”的影响. 以下从运维的角度解释,Redis数十节点的集群,出现数据容量和请求量倾斜情况下,存在的一些痛点:.

Redis集群功能说明

- gOODiDEA - NoSQLFan
虽然目前可以通过在客户端做hash的方法来构建Redis集群,但Redis原生的集群支持还是颇受期待. 本文是对Redis集群功能官方描述文档的一个翻译,译者是@PPS萝卜同学,也感谢他的投稿分享. 这篇文档主要是为了说明正在进展中的Redis集群功能. 文档主要分为两个部分,前一部分主要介绍我在非稳定分支已完成的代码,后一部分主要介绍还有哪些功能待实现.

redis集群(主从配置)

- - 操作系统 - ITeye博客
市面上太多kv的缓存,最常用的就属memcache了,但是memcache存在单点问题,不过小日本有复制版本,但是使用的人比较少,redis的出现让kv内存存储的想法成为现实. 今天主要内容便是redis主从实现简单的集群,实际上redis的安装配置砸门ttlsa之前就有个文章,废话少说,进入正题吧.

Redis集群明细文档

- - CSDN博客架构设计推荐文章
  Redis目前版本是没有提供集群功能的,如果要实现多台Redis同时提供服务只能通过客户端自身去实现(Memchached也是客户端实现分布式). 目前根据文档已经看到Redis正在开发集群功能,其中一部分已经开发完成,但是具体什么时候可以用上,还不得而知. 文档来源: http://redis.io/topics/cluster-spec.

BDRP分布式redis集群

- - 百度运维团队技术博客
BDRP(baidu distributed redis platform)是包含 twemproxy, redis,redis-sentinel等多个模块开发的分布式redis平台. bdrp已经在github上进行了开源, bdrp的github项目点这里. 目前redis集群架构主要有以下几个组件: twemproxy:redis的代理系统,可以选择多种数据分片算法 redis:集群的redis存储节点 sentinel:redis官方的集群高可用组件,可以监控redis主节点故障,并进行主备切换.

redis 性能问题查找

- - 开源软件 - ITeye博客
          使用redis作为数据库时,系统出现少量超时,通过日志信息发现,超时发生在bgsave时. bgsave命令会fork一个子进程,子进程会将redis数据库信息dump到rdb文件中. 因此不能确定使用bgsave命令时,是fork一个子进程引起超时,还是dump文件时与主进程的sync同步同时写磁盘引起的超时.

redis超时问题分析

- - 搜索技术博客-淘宝
Redis在分布式应用中占据着越来越重要的地位,短短的几万行代码,实现了一个高性能的数据存储服务. 最近dump中心的cm8集群出现过几次redis超时的情况,但是查看redis机器的相关内存都没有发现内存不够,或者内存发生交换的情况,查看redis源码之后,发现在某些情况下redis会出现超时的状况,相关细节如下.

Redis数据“丢失”问题

- - 今天
Redis大部分应用场景是纯缓存服务,请求后端有Primary Storage的组件,如MySQL,HBase;请求Redis的键未命中,会从primary Storage中获取数据返回,同时更新Redis缓存. 如果少量数据丢失,相当于请求”缓冲未命中“; 一般对业务的影响是无感知的. 但现在Redis用作存储的业务场景变多,数据丢失对业务是致命的影响.

Redis核心解读–集群管理工具(Redis-sentinel)

- - NoSQLFan
Redis作为高性能的key-value存储,一直在单实例上表现良好,但是长期以来一直缺乏一种官方的 高可用方案支持. 于是 Redis-sentinel应运而生,提供了对客户端透明的高可用支持. 下面文章对Redis- sentinel的原理进行了系统的讲解. 文章来源: www.wzxue.com.

基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

- - 开源软件 - ITeye博客
本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在Redis2.4中,Redis2.8中Sentinel更加稳定),Redis集群是以分片(Sharding)加主从的方式搭建,满足可扩展性的要求;.