用高并发技巧解决redis热key问题

最新推荐文章于 2024-05-11 19:57:37 发布
最新推荐文章于 2024-05-11 19:57:37 发布
阅读量1.1k 收藏 1
点赞数 2
文章标签： redis java 程序人生 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Java_LingFeng/article/details/127595370
版权

​

这篇文章我将介绍工作中处理热key问题的常用手段，可能介绍的不是很全，毕竟不同的业务场景可能有不同的解决方案，但是相信通过这部分的介绍能提供一个热key问题的思路。

热key问题，简单来说就是对某一资源的访问量过高问题，再简单一点来说就是对某个资源访问的qps过高，而解决访问量高的问题通常我们使用分布式缓存，最常见的就是redis，这个资源对应redis的一个key简称热key。热key在开发中是非常常见的，比如各种app的榜单，活动页面上的一些资源。

虽然redis号称单节点能扛住10Wqps，但是开发中肯定不能这样去估计，毕竟安全第一，比如5000似乎就可能就可以作为上限。如果超过5000该怎么处理呢？下面将提供几种常见的解决方案。

冗余写/随机读

假设在做活动，活动总金额为amount，用户每次完成任务会得到一笔奖金，每天结算一次，在页面会展示剩余金额restAmount。我们将剩余金额存到redis中，{key: pool, value: restAmount}

由于每天统一结算，所以写的qps不会很高，毕竟我们能自己控制流量，比如用户完成后发个延迟结算消息到mq，然后由消费者来处理计算剩余金额最后更新到redis中。

但是在页面的读的qps是很高的。显然奖池pool就是个热key。

既然单节点扛不住，那么显然可以

最低0.47元/天 解锁文章
Java_LingFeng
关注
  • 2
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
redis的bigkey扫描脚本深入介绍
12-16
【Redis大键值扫描脚本深入...通过结合`pipeline`和`debug object`，我们可以创建更高效的扫描脚本，以应对高并发环境下的大键值问题。对于更多Redis操作和管理技巧，建议查阅相关文档和最佳实践，以提升整体运维能力。
PHP使用Redis实现防止大并发下二次写入的方法
10-19
在高并发环境中，确保数据的一致性和唯一性是至关重要的。PHP使用Redis作为缓存或数据库时，可能会遇到多个进程同时尝试写入同一数据的问题，这可能导致数据的二次写入，从而破坏数据的一致性。为了解决这个问题，...
Redis——热点key问题
娜娜米的博客
06-06 8922
本篇主要介绍Redis中的热点Key问题，包括热点Key产生的原因、如何监控发现热点key以及热点Key的解决方案；
Redis热Key问题解决方案汇总
loseyourself94的博客
03-29 777
Redis热Key问题解决方案汇总
【退役之重学Java】Redis 高并发与高可用
weixin_41899098的博客
05-11 1296
sentinel，哨兵。是 Redis 集群架构中非常重要的一个组件，主要功能如下集群监控，负责监控 Redis master 和 slave 进程是否正常工作消息通知，如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员故障转移，如果 master node 挂掉了，会自动转移到 slave node 上配置中心，如果故障转移发生了，通知client 客户端新的 master 地址哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。
Redis的一些高并发处理，QPS超过1万的读写
weixin_43504955的博客
11-15 1810
了解Redis高性能处理方案，qps超过1万的读写
Redis热点Key发现及常见解决方案
weixin_33755557的博客
11-23 728
热点Key问题产生的原因大致有以下两种： 1、用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。 在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。 同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这...
Redis中的热点Key问题
qq_46130027的博客
05-05 676
在Redis中，我们把访问频率高的key，称为热key。比如突然有几十万的请求去访问redis中某个特定的key，那么这样会造成redis服务器短时间流量过于集中，很可能导致redis的服务器宕机。那么接下来对这个key的请求，都会直接请求到我们的后端数据库中，从而可能导致后端服务不可用。进而导致服务雪崩。简单理解，热Key就是访问频率高的那些Key。
MySql高并发基础之性能优化
06-17
MySQL性能优化是提升系统在高并发环境下运行效率的关键。在处理大量并发请求时，数据库的性能直接影响了应用程序的响应时间和整体用户体验。以下是对标题和描述中提到的知识点的详细解释： 1. **优化目标**： - **...
Redis语法，Key值设计及常用案例介绍
04-30
Redis是一种高性能的键值对数据库，常用于缓存、消息队列等场景。...通过合理使用Redis的语法、Key设计和各种特性，可以有效地解决多种IT问题，提升系统性能。在实践中不断优化和调整，才能更好地发挥Redis的优势。
redis高级命令实践.zip
最新发布
06-09
Redis Sentinel是高可用性的解决方案，它可以监控、故障检测和自动故障转移，确保在主节点出问题时，能将从节点提升为主节点，保证服务的连续性。 12. **Cluster集群**： Redis Cluster实现了数据的分布式存储，...
Redis缓存及热点key问题解决方案
08-19
主要介绍了Redis缓存及热点key问题解决方案,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
阿里Java三面：了解热点key问题？说说它的的产生原因和解决方案
jjc4261的博客
04-05 253
此时就完成了缓存的访问跟重建。通过上述对比分析可以看出，阿里云在解决热点Key上较传统方法相比都有较大的提高，无论是基于读写分离方案还是热点数据解决方案，在实际处理环境中都可以做灵活的水平能力扩充、都对客户端透明、都有一定的数据不一致性。对于db上热点数据的发现，首先会在一个周期内对Key进行请求统计，在达到请求量级后会对热点Key进行热点定位，并将所有的热点Key放入一个小的LRU链表内，在通过Proxy请求进行访问时，若Redis发现待访点是一个热点，就会进入一个反馈阶段，同时对该数据进行标记。
如何解决Redis热Key问题？
飞乐鸟的博客
12-12 1247
如何解决Redis热点key问题
Redis 热 Key 发现以及解决办法
kaili_0230的博客
05-08 253
在这一篇文章中我们首先分析了在 Redis 中热 Key 带来的一些问题，同时也介绍了在海量的 Redis Key 中找到热 Key 的一些方法，最后也提到了在解决热 Key 问题中我们常用的一些办法；总结来说，Redis 热 Key 问题首先是请求流量过大造成的，但是更深层次原因还是出现了流量倾斜，单个 Redis 实例承担的流量过大造成的，了解到了本质原因，解决的思路也就简单了，就是要想尽一切办法将单个实例承担的流量打散，让每个机器均衡承担热 Key 的流量，不要出现流量倾斜，保证系统的稳定性。
达到物理网卡上限，突然几十万的请求访问Redis的某个key如何解决
weixin_33834628的博客
05-29 1294
热Key问题 所谓热key问题就是，突然有几十万的请求去访问redis上的某个特定key。那么，这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机。 那接下来这个key的请求，就会直接怼到你的数据库上，导致你的服务不可用。 怎么发现热key 方法一:凭借业务经验，进行预估哪些是热key 其实这个方法还是挺有可行性的。比如某商品在做秒杀，那这个商品的key就可以判断出是热...
QPS过万，Redis大量连接超时怎么解决？
有才而性缓，定属大才。有智而气和，斯为大智。
04-25 277
来自公众号：艾小仙 之前负责的一个服务总是在高峰时刻和压测发生大量的redis连接超时的异常redis.clients.jedis.exceptions.JedisConnectionException，根据原有的业务规则，首先会从数据库查询，然后缓存到redis中，超时时间设置为3分钟。 并且由于业务的特性，本身未做降级、限流等处理措施，而在巅峰的QPS基本上快达到20000的样子，虽然这个现象只是单纯的一个异常，并不会导致整个主链路的流程不可用，但是我们还是要找出问题的原因并且解决。 首先我们.
redis 对单个key进行大数据量incr
三少说
04-09 1262
利用 redis incr 做超高并发延迟累加器（一亿数量级） 前景提要： 公司有一个字段，需要支持 qps 为 1000万。 但是可以将结果作为延迟结果发送过来，比如 20秒发一次结果。但是不能直接 incr 1000万次，redis即使是集群 也扛不住。 提示： redis只有在网络读取请求利用了多线程，在磁盘io等处理数据方面依然是单线程。 思路： 多应用示例部署，利用多应用本地jvm缓存，来进行分流，各应用本地之间近行多线程本地累加。利用时间段来提交多应用的累加结果，此时再利用incr原子特性进行多
Redis：解决分布式高并发修改同一个Key的问题
05-25
在分布式系统中，多个节点可能同时尝试修改同一个 key 的值，这会导致数据的不一致性和冲突。Redis 通过使用乐观锁来解决这个问题。 乐观锁是一种基于版本号的锁机制。当一个节点要修改某个 key 的值时，它会先读取该 key 的版本号，然后修改该 key 的值，并把版本号加一。如果在这个过程中，其他节点也尝试修改该 key 的值，它们也会先读取该 key 的版本号，然后尝试修改该 key 的值，但是由于版本号已经被修改了，它们的修改请求就会被拒绝。这样就保证了同一时间只有一个节点能够修改该 key 的值，避免了数据的冲突和不一致性。 在 Redis 中，可以使用 WATCH 和 MULTI 命令来实现乐观锁。WATCH 命令会监视一个或多个 key，如果这些 key 在执行 MULTI 命令之前被修改了，那么 EXEC 命令就会失败。这时候应该重新执行整个事务。 示例代码： ``` WATCH key val = GET key val = val + 1 MULTI SET key val EXEC ``` 在这个代码中，我们先使用 WATCH 命令监视 key。然后使用 GET 命令获取 key 的值，执行逻辑处理后，再使用 MULTI 命令开启一个事务，将修改后的值设置回 key 中。如果在这个过程中，其他节点修改了 key 的值，那么 EXEC 命令就会失败，这时候应该重新执行整个事务。 除了乐观锁外，Redis 还支持悲观锁，可以使用 SETNX 和 GETSET 命令来实现。SETNX 命令可以原子性地设置一个 key 的值，只有当该 key 不存在时才会执行设置操作。GETSET 命令可以原子性地获取一个 key 的值，并设置一个新的值。这两个命令都可以用来实现悲观锁。但是，悲观锁会带来更多的性能开销，因为它需要不断地检查锁是否被占用。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值