浅析Redis集群数据倾斜问题及解决方法

这篇具有很好参考价值的文章主要介绍了浅析Redis集群数据倾斜问题及解决方法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

概  述 

在服务端系统服务开发中,缓存是一种常用的技术,它可以提高系统对请求的处理效率,而redis又是缓存技术栈中的一个佼佼者,广泛的应用于各种服务系统中。在大型互联网服务中,每天需要处理的请求和存储的缓存数据都是海量的,在这些大型系统中,使用单实例的redis,很难满足系统超高的并发请求以及海量数据缓存需求。大型的互联网服务中对于redis的使用,往往采用集群架构,通过横向扩展redis实例规模的方式,以较低的成本,来提升缓存系统对数据请求的处理效率和数据存储容量。

redis集群架构虽然有众多优点,但是事物往往都是有双面性的,在解决某些场景下的问题后,又会在另外的场景下有带来问题。当然redis集群模式,也是符合这个规律的。redis集群模式下,会增加运维的复杂度,限制了redis中某些命令的使用(范围查询,事务操作的使用等),除了这些常见的问题外,数据倾斜问题,是redis集群模式下一个比较隐蔽的问题,只有在一些特殊的场景下才会出现,但是该问题带来的影响确实巨大的。

示  例

2019年春节抽奖服务,业务评估峰值qps是2w,转化到redis集群为10w qps和5GB内存存储,部署5个分片每个分片1GB+2W qps的redis集群(包含预留容量)。结果活动开始时,才发现服务存在”热点key",请求严重倾斜, 峰值时的6w qps都集中到其中一个分片,导致这分片过载,整个抽奖服务雪崩。

什么是数据倾斜

   在redis集群模式下,数据会按照一定的分布规则分散到不同的实例上。如果由于业务数据特殊性,按照指定的分布规则,可能导致不同的实例上数据分布不均匀,如以下场景:有些切片实例上数据分布量较大,有些实例上数据分布量较少;有些实例上保存了热点数据,数据访问量较大,有些实例上保存数据相对较"冷",几乎没有访问量。那么存储数据量大的实例,或者保存热点数据的实例,资源利用率会比较高,负载压力较大,导致其对数据请求响应变慢。此时就产生了数据倾斜。

浅析Redis集群数据倾斜问题及解决方法

 有哪几种数据倾斜

redis分布式集群倾斜问题,主要分为两类:

1、数据存储容量倾斜,数据存储总是落到集群中少数节点;

2、qps请求倾斜,qps总是落到少数节点。

redis集群出现倾斜的影响

倾斜问题对于redis这类纯内存和单线程服务影响较大,存在以下痛点:

  • qps集中到少数redis节点,引起少数节点过载,会拖垮整个服务,同时集群处理qps能力不具备可扩展性;

  • 数据容量倾斜,导致少数节点内存爆增,出现OOM Killer和集群存储容量不具备可扩展性;

  • 运维管理变复杂,类似监控告警内存使用量、QPS、连接数、redis cpu busy等值不便统一;

  • 因集群内其他节点资源不能被充分利用,导致redis服务器/容器资源利率低;

  • 增大自动化配置管理难度;单集群节点尽量统一参数配置;

分析完影响,那我们再看生产环境中,导致Redis集群严重“倾斜”的常见原因。

导致Redis集群倾斜的常见原因

一般是系统设计时,键空间(keyspace)设计不合理:

  • 系统设计时,redis键空间(keyspace)设计不合理,出现”热点key",导致这类key所在节点qps过载,集群出现qps倾斜;

  • 系统存在大的集合key(hash,set,list等),导致大key所在节点的容量和QPS过载,集群出现qps和容量倾斜;

  • DBA在规划集群或扩容不当,导致数据槽(slot)数分配不均匀,导致容量和请求qps倾斜;

  • 系统大量使用Keys hash tags, 可能导致某些数据槽位的key数量多,集群集群出现qps和容量倾斜;

  • 工程师执行monitor这类命令,导致当前节点client输出缓冲区增大;used_memory_rss被撑大;导致节点内存容量增大,出现容量倾斜;

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

Redis集群倾斜问题的排查方式

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

当集群因热点key导致集群qps倾斜,需快速定位热点key和top commands。可使用开源工具redis-faina,或有实时redis分析平台更好。

以下是使用redis-faina工具分析,可见两个前缀key的QPS占比基本各为50%, 明显热点key;也能看到auth命令的异常(top commands)。

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%)

系统是否使用较大的集合键

系统使用大key导致集群节点容量或qps倾斜,比如一个5kw字段的hash key, 内存占用在近10GB,这个key所在slot的节点的内存容量或qps都很有可能倾斜。

这类集合key每次操作几个字段,很难从proxy或sdk发现key的大小。

可使用redis-cli --bigkeys 分析节点存在的大键。如果需全量分析,可使用redis-rdb-tools(https://github.com/sripathikrishnan/redis-rdb-tools) 对节点的RDB文件全量分析,通过结果size_in_bytes列得到大key的占用内存字节数。

示例使用redis-cli 进行抽样分析:

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)

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

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

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.

系统是否大量使用keys hash tags

在redis集群中,有些业务为达到多键的操作,会使用hash tags把某类key分配同一个分片,可能导致数据、qps都不均匀的问题。可使用scan扫描keyspace是否有使用hash tags的,或使用monitor,vc-redis-sniffer工具分析倾斜节点,是否大理包含有hash tag的key。

是否因为client output buffer异常,导致内存容量倾斜

确认是否有client出现output buffer使用量异常,引起内存过大的问题;比如执行monitor、keys命令或slave同步full sync时出现客户端输入缓冲区占用过大。

这类情况基本redis实例内存会快速增长,很快会出现回落。通过监测client输出缓冲区使用情况;分析见下面示例:

# 通过监控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

# 查看输出缓冲区列表长度不为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集群倾斜问题

  • 系统设计redis集群键空间和query pattern时,应避免出现热点key, 如果有热点key逻辑,尽量打散分布不同的节点或添加程序本地缓存;

  • 系统设计redis集群键空间时,应避免使用大key,把key设计拆分打散;大key除了倾斜问题,对集群稳定性有严重影响;

  • redis集群部署和扩缩容处理,保证数据槽位分配平均;

  • 系统设计角度应避免使用keys hash tag;

  • 日常运维和系统中应避免直接使用keys,monitor等命令,导致输出缓冲区堆积;这类命令建议作rename处理;

  • 合量配置normal的client output buffer, 建议设置10mb,slave限制为1GB按需要临时调整(警示:和业务确认调整再修改,避免业务出错)

在实际生产业务场景中,大规模集群很难做到集群的完全均衡,只是尽量保证不出现严重倾斜问题。文章来源地址https://www.toymoban.com/news/detail-466761.html

到了这里,关于浅析Redis集群数据倾斜问题及解决方法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Redis 数据分布优化:如何应对数据倾斜?

    Redis 核心技术与实战 笔记 作者: 蒋德钧 在切片集群中,数据会按照一定的分布规则分散到不同的实例上保存。比如,在使用 Redis Cluster 或 Codis 时,数据都会先按照 CRC 算法的计算值对 Slot(逻辑槽)取模,同时,所有的 Slot 又会由运维管理员分配到不同的实例上。这样,数

    2024年02月11日
    浏览(35)
  • docker搭建redis三主三从集群,及其常见问题解决

    每个配置文件都要修改对应的端口 容器内端口不能都是是6379,集群总线接口是端口号+10000 端口号与network_mode: \\\"host\\\"不能一起配置,出现下述问题 “主机”网络模式与端口绑定不兼容 问题,具体看github,有对应解释。 如果一直卡在 Waiting for the cluster to join ,那一般是端口问题

    2024年02月11日
    浏览(55)
  • 浅析CXL P2P DMA加速数据传输拥堵问题的解决方案

    接上文:CXL P2P DMA加速数据传输的拥堵问题 为了改善这个问题,CXL 3.0引入了Unordered-IO和Back Invalidate Snoop新机制 ,允许更直接和高效点对点数据传输,以减轻上游CXL通道的压力并减少延迟。 (1)Unordered-IO (UIO) 在 传统PCIe体系中,DMA传输通常是有序的,要求严格按照顺序完成,否

    2024年01月18日
    浏览(40)
  • Flink本地集群部署启动&常见问题的解决方法

    [zhangflink@9wmwtivvjuibcd2e software]$ vim flink/conf/flink-conf.yaml [zhangflink@9wmwtivvjuibcd2e software]$ vim flink/conf/workers [zhangflink@9wmwtivvjuibcd2e software]$ xsync flink/conf/ 启动集群在jobmanager那台机器启动 [zhangflink@9wmwtivvjuibcd2e-0001 flink]$ bin/start-cluster.sh 启动成功jobmanager会出现如下进程 启动成功taskm

    2024年02月02日
    浏览(51)
  • Redis缓存穿透、击穿、雪崩问题及其解决方法

    缓存穿透 :缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库。 常见的解决方案有两种: 缓存空对象 优点:实现简单,维护方便 缺点: 额外的内存消耗 可能造成短期的不一致 布隆过滤 优点:内存占用较少,

    2024年02月02日
    浏览(42)
  • [Redis]缓存穿透、缓存击穿、缓存雪崩问题及解决方法

    缓存穿透就是指在高并发的情况下大量的请求去查询一个不存在于缓存中的数据,导致这些请求都直接访问数据库,给数据库造成压力。例如:我存储在缓存中的key是数字类型(123),但是网络攻击者频繁地用字符串(abc)去获取缓存。导致永远都无法命中缓存,请求最终都

    2024年02月15日
    浏览(47)
  • 倾斜摄影三维模型的OSGB、3DTiles格式的层级划分和块大小划分规则浅析

    倾斜摄影三维模型的OSGB、3DTiles格式的层级划分和块大小划分规则浅析  倾斜摄影三维模型是一种基于倾斜摄影技术获取的高精度三维地图,可以用于城市规划、建筑设计、公共安全等领域。在数字化建设中,OSGB和3DTiles是两种常见的数据格式,它们都支持倾斜摄影三维模型的

    2024年02月16日
    浏览(41)
  • Spark数据倾斜解决方案一:源数据预处理和过滤倾斜key

    为什么把源数据预处理和过滤掉倾斜的key两种处理倾斜的方式写到一起? 因为这两种方式在实际的项目中场景较少而且单一,对于数据源预处理,比如原本要在spark中进行聚合或join的操作,提前到hive中去做,这种方式虽然解决了spark中数据倾斜的问题,但是hive中依然也会存

    2024年02月09日
    浏览(41)
  • 倾斜摄影三维模型数据几何坐标重建方法分析

    利用几何坐标变换等技术实现倾斜摄影三维模型数据的坐标重建,可以采用以下方法: 1、数据准备:首先,需要获取倾斜摄影影像数据。这些影像应包含多个视角下的拍摄图像,并覆盖同一场景。同时,还需要收集地面控制点的坐标信息,以提供参考和配准基准。 2、特征提

    2024年02月06日
    浏览(43)
  • 如何处理生产环境中的数据倾斜问题?

    1、flink数据倾斜的表现: 任务节点频繁出现反压,增加并行度也不能解决问题 部分节点出现OOM异常,是因为大量的数据集中在某个节点上,导致该节点内存被爆,任务失败重启 2、数据倾斜产生的原因: 业务上有严重的数据热点,比如滴滴打车的订单数据中北京、上海等几

    2024年02月10日
    浏览(74)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包