wordpress 移动站,drupal wordpress joomla,网站建设公司价位,网站标题的优化一、先讲讲什么是redis的热key问题
在Redis中#xff0c;我们把访问频率高的Key#xff0c;称为热Key。比如突然有几十万的请求去访问redis中某个特定的Key#xff0c;那么这样会造成redis服务器短时间流量过于集中#xff0c;很可能导致redis的服务器宕机。那么接下来对这…一、先讲讲什么是redis的热key问题
在Redis中我们把访问频率高的Key称为热Key。比如突然有几十万的请求去访问redis中某个特定的Key那么这样会造成redis服务器短时间流量过于集中很可能导致redis的服务器宕机。那么接下来对这个Key的请求都会直接请求到我们的后端数据库中数据库性能本来就不高这样就可能直接压垮数据库进而导致后端服务不可用。
1.1 热Key产生的原因
1、用户消费的数据远大于生产的数据如商品秒杀、热点新闻、热点评论等读多写少的场景。
双十一秒杀商品短时间内某个爆款商品可能被点击/购买上百万次或者某条爆炸性新闻等被大量浏览此时会造成一个较大的请求Redis量这种情况下就会造成热点Key问题。
2、请求分片集中超过单台Redis服务器的性能极限。
在服务端读数据进行访问时往往会对数据进行分片切分例如采用固定Hash分片hash落入同一台redis服务器如果瞬间访问量过大超过机器瓶颈时就会导致热点 Key 问题的产生。
1.2 热点Key的危害
缓存击穿压垮redis服务器导致大量请求直接发往后端服务并且DB本身性能较弱很可能进一步导致后端服务雪崩。
1.3 如何解决热key问题
Redis集群扩容增加分片副本分摊客户端发过来的读请求
读写分离主节点处理写请求从节点处理读请求
使用二级缓存将热key存放一份到JVM本地内存中减少Redis的读请求
二、什么是Big key
Redis中的大key问题指的是某个key对应的value值所占的内存空间比较大这会导致Redis的性能下降、内存不足、数据不均衡以及主从同步延迟等一系列问题。大key的具体定义并不固定通常认为字符串类型的key对应的value值占用空间大于1MB或者集合类型的key元素数量超过1万个就视为大key。但这一标准也会根据Redis的实际运用以及业务需求来综合评估。
本质上是大value问题。key往往是程序可以自行设置的value往往不受程序控制因此可能导致value很大。
用几个实际的例子对大Key的特征进行描述
● 一个String类型的Key它的值为5MB数据过大 ● 一个List类型的Key它的列表数量为20000个列表数量过多 ● 一个ZSet类型的Key它的成员数量为10000个成员数量过多 ● 一个Hash格式的Key它的成员数量虽然只有1000个但这些成员的value总大小为100MB成员体积过大
在实际业务中大Key的判定仍然需要根据Redis的实际使用场景、业务场景来进行综合判断。通常都会以数据大小与成员数量来判定。
2.1 Big Key产生的场景
1、redis数据结构使用不恰当
将Redis用在并不适合其能力的场景造成Key的value过大如使用String类型的Key存放大体积二进制文件型数据。
2、未及时清理垃圾数据
没有对无效数据进行定期清理造成如HASH类型Key中的成员持续不断的增加。即一直往value塞数据却没有删除机制value只会越来越大。
3、对业务预估不准确
业务上线前规划设计考虑不足没有对Key中的成员进行合理的拆分造成个别Key中的成员数量过多。
4、明星、网红的粉丝列表、某条热点新闻的评论列表
假设我们使用List数据结构保存某个明星/网红的粉丝或者保存热点新闻的评论列表因为粉丝数量巨大热点新闻因为点击率、评论数会很多这样List集合中存放的元素就会很多可能导致value过大进而产生Big Key问题。
2.2 大key问题的影响
内存占用过高大key占用过多的内存空间可能导致可用内存不足从而触发内存淘汰策略。性能下降大key的读写操作会消耗更多的CPU和网络资源导致Redis整体性能下降。阻塞操作删除或修改大key时可能会阻塞Redis实例影响其他操作。数据不均衡大key的存在可能导致数据在Redis集群中的分布不均衡。主从同步延迟在主从复制场景中大key的同步可能会增加延迟。
2.3 如何识别Big Key
使用SCAN命令结合其他命令如STRLEN、LLEN、SCARD、HLEN等逐步遍历数据库中的所有key识别出大key。使用redis-cli命令客户端连接Redis服务时加上--bigkeys参数可以扫描每种数据类型数量最大的key。使用开源工具如Redis RDB Tools分析RDB文件扫描出Redis中的大key。
2.4 如何解决Big Key问题
1.分析原因
分析为何会产生大key并根据业务场景考虑是否可以通过更好的设计来避免大key的产生。
2.拆分大key
如果大key是不可避免的尝试将其拆分成更多的小key来分散数据。例如对于列表、集合和有序集合可以通过散列hashing某个属性把它们分散到不同的小key中。对于哈希表可以使用一致性哈希等算法将大哈希表拆分成多个小哈希表。
3.设置合理的过期时间
为每个key设置过期时间并设置合理的过期时间以便在数据失效后自动清理避免长时间累积的大key问题。
4.启用内存淘汰策略
启用Redis的内存淘汰策略如LRULeast Recently Used最近最少使用以便在内存不足时自动淘汰最近最少使用的数据防止大key长时间占用内存。
5.使用数据压缩
对于String类型的大key可以使用压缩算法如LZF、QUICKLZ、GZIP等减少value的大小。
6.渐进式删除
如果要删除大key为了避免一次性删除所带来的长时间阻塞可以使用Redis的HSCAN、SSCAN、ZSCAN和SCAN命令配合DEL命令对大key进行渐进式删除。
7.数据迁移
如果单个Redis实例无法处理大key问题可以考虑将数据迁移到使用集群以此来分散负载和存储。
8.优化数据结构
优化数据结构可能是处理大key最有效的方法。如果不必使用哈希表、列表、集合或有序集合的全部特性可以考虑使用更简单的数据结构来替代。
9.监控与预防
定期监控Redis实例的内存使用情况和各种key的大小能够帮助及时发现并处理大key问题。在开发和部署Redis系统时充分考虑大key问题并采取相应的措施来预防和避免这些问题的出现。
