特点#xff1a;

支持数据持久化#xff1a;可以将内存中的数据保…一、说说什么是Redis、及特点

Redis是一个基于内存存储数据运行并支持持久化、使用key/value形式存储的高性能的nosql数据库适合用于存储频繁访问数据量较小的场景下。

支持数据持久化可以将内存中的数据保持在磁盘中重启的时候可以再次加载进行使用。

支持多种数据结构不仅支持简单的key-value类型数据同时还提供string、list、set、zset、hash等数据结构的存储支持数据备份master-salve模式的数据备份

通常我们会将含有较大数据或含有大量成员、列表数的Key称之为大Key下面我们将用几个实际的例子对大Key的特征进行量化描述

一个STRING类型的Key它的值为5MB数据过大一个LIST类型的Key它的列表数量为20000个列表数量过多一个ZSET类型的Key它的成员数量为10000个成员数量过多一个HASH格式的Key它的成员数量虽然只有1000个但这些成员的value总大小为100MB成员体积过大

在某个Key接收到的访问次数、显著高于其它Key时我们可以将其称之为热Key常见的热Key如

某Redis实例的每秒总访问量为10000而其中一个Key的每秒访问量达到了7000访问次数显著高于其它Key对一个拥有上千个成员且总大小为1MB的HASH

Key每秒发送大量的HGETALL带宽占用显著高于其它Key对一个拥有数万个成员的ZSET

Key每秒发送大量的ZRANGECPU时间占用显著高于其它Key

在Redis的使用中大Key及热Key会给Redis带来各种各样的问题而最常见的问题为性能下降、访问超时、数据不均衡等。

4.1

Client发现Redis变慢Redis内存不断变大引发OOM或达到maxmemory设置值引发写阻塞或重要Key被逐出Redis

Cluster中的某个node内存远超其余node但因Redis

Cluster的数据迁移最小粒度为Key而无法将node上的内存均衡化大Key上的读请求使Redis占用服务器全部带宽自身变慢的同时影响到该服务器上的其它服务删除一个大Key造成主库较长时间的阻塞并引发同步中断或主从切换

4.2

Cluster的分布式优势无法被Client利用一个分片负载很高而其它分片十分空闲从而产生读/写热点问题在抢购、秒杀活动中由于商品对应库存Key的请求量过大超出Redis处理能力造成超卖热Key的请求压力数量超出Redis的承受能力造成缓存击穿此时大量强求将直接指向后端存储将其打挂并影响到其它业务

业务规划不足、Redis不正确的使用、无效数据的堆积、访问突增等都会产生大Key与热Key如

将Redis用在并不适合其能力的场景造成Key的value过大如使用String类型的Key存放大体积二进制文件型数据大Key业务上线前规划设计考虑不足没有对Key中的成员进行合理的拆分造成个别Key中的成员数量过多大Key没有对无效数据进行定期清理造成如HASH类型Key中的成员持续不断的增加大Key预期外的访问量陡增如突然出现的爆款商品、访问量暴涨的热点新闻、直播间某大主播搞活动带来的大量刷屏点赞、游戏中某区域发生多个工会间的战斗涉及大量玩家等热Key使用LIST类型Key的业务消费侧代码故障造成对应Key的成员只增不减大Key

大Key与热Key的分析并不困难我们有多种途径和手段来对Redis中的Key进行分析并找出其中的“问题”Key如Redis的内置功能、开源工具、阿里云Redis控制台中的Key分析功能等。

拆分删除

将不适合Redis能力的数据存放至其它存储并在Redis中删除此类数据。

需要注意的是删除大key可能很耗时redis又是单线程执行的很可能造成阻塞Redis自4.0起提供了UNLINK命令该命令能够异步的方式安全的删除大Key。

复制读写分离多级缓存

在使用redis集群时可以将热key复制多份每个redis节点上存放一份这样不存在请求的重定向使得压力全部定向到单个节点能有效减轻单节点的压力。

缺点是要进行复制的画只能在代码层手动操作而且复制多份存放后会存在数据一致性问题。

因此复制方案只能用于临时解决线上问题。

读写分离

热key多数是读热key的操作读写分离能保证从节点中数据的一致性并且能轻松的横向扩展能有效的分散压力只是有点浪费资源因为读写分离每个从节点上存的都是一样的数据。

多级缓存

当热key数量不多比如电商平台促销活动热key都集中在少部分key上面为此做读写分离增加机器性价比不高使用多级缓存是个不错的解决方法。

具体实现思路两种

1.本地缓存redis和业务服务器之间增加一个中间层proxy专门用来进行热key探查这个proxy专门用来监视redis来统计达到预设的热key阈值的key统计好后推送给业务服务器让业务服务器存在本地缓存。

2.单独缓存将proxy探查到的热key推送到单独的一个缓存热key的redis上去如果扛不住热key服务器再横向扩容当然这个方案也是单独增加了服务器结点去处理热key的除非保证系统中经常会有热key出现不然的话使用本地缓存性价比更高。

使用多级缓存会存在一个问题因为每次推送之间有时间间隔缓存中的数据和redis中的数据不是呈现强一致性的而是呈现最终一致性的。

这种代价也是不得不接受的在使用缓存的时候注意不要拿缓存做逻辑只用来做查询即可。