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集群遇到的问题 - 简书

- -
具体环境：两台云端服务器 专有网络. 软件环境： jedis 2.9.0 redis3.2.10. 1、先是设置了redis密码再集群，见. /usr/lib/ruby/gems/1.8/gems/redis-3.3.0/lib/redis/client.rb这里的. client.rb文件路径是按照你安装ruby、在通过gems安装redis3.3的时候的路径（不熟悉ruby的软件安装）.

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.