【Redis核心知识 九】Redis企业级解决方案【缓存预热、热备、雪崩、击穿、穿透】(二)

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: 【Redis核心知识 九】Redis企业级解决方案【缓存预热、热备、雪崩、击穿、穿透】(二)

可以看到Redis对各种命令进行了压测。

[root@192 redis-6.0.8]# redis-benchmark -h 192.168.5.101
====== PING_INLINE ======
  100000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
0.01% <= 0.1 milliseconds
48.89% <= 0.2 milliseconds
86.78% <= 0.3 milliseconds
94.35% <= 0.4 milliseconds
97.30% <= 0.5 milliseconds
98.63% <= 0.6 milliseconds
99.26% <= 0.7 milliseconds
99.58% <= 0.8 milliseconds
99.75% <= 0.9 milliseconds
99.86% <= 1.0 milliseconds
99.94% <= 1.1 milliseconds
99.98% <= 1.2 milliseconds
99.99% <= 1.3 milliseconds
100.00% <= 1.4 milliseconds
100.00% <= 1.4 milliseconds
117647.05 requests per second
====== PING_BULK ======
  100000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
0.02% <= 0.1 milliseconds
47.76% <= 0.2 milliseconds
84.99% <= 0.3 milliseconds
93.23% <= 0.4 milliseconds
96.76% <= 0.5 milliseconds
98.54% <= 0.6 milliseconds
99.12% <= 0.7 milliseconds
99.47% <= 0.8 milliseconds
99.69% <= 0.9 milliseconds
99.84% <= 1.0 milliseconds
99.93% <= 1.1 milliseconds
99.97% <= 1.2 milliseconds
99.99% <= 1.3 milliseconds
99.99% <= 1.4 milliseconds
100.00% <= 1.5 milliseconds
100.00% <= 1.6 milliseconds
117508.81 requests per second
====== SET ======
  100000 requests completed in 0.84 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
0.00% <= 0.1 milliseconds
53.79% <= 0.2 milliseconds
87.07% <= 0.3 milliseconds
94.75% <= 0.4 milliseconds
97.48% <= 0.5 milliseconds
98.93% <= 0.6 milliseconds
99.44% <= 0.7 milliseconds
99.68% <= 0.8 milliseconds
99.81% <= 0.9 milliseconds
99.88% <= 1.0 milliseconds
99.91% <= 1.1 milliseconds
99.93% <= 1.2 milliseconds
99.96% <= 1.3 milliseconds
99.97% <= 1.4 milliseconds
99.98% <= 1.5 milliseconds
99.99% <= 1.6 milliseconds
99.99% <= 1.7 milliseconds
100.00% <= 1.8 milliseconds
100.00% <= 1.9 milliseconds
118764.84 requests per second
====== GET ======
  100000 requests completed in 0.90 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
0.00% <= 0.1 milliseconds
45.58% <= 0.2 milliseconds
78.84% <= 0.3 milliseconds
88.70% <= 0.4 milliseconds
93.91% <= 0.5 milliseconds
97.42% <= 0.6 milliseconds
98.88% <= 0.7 milliseconds
99.44% <= 0.8 milliseconds
99.68% <= 0.9 milliseconds
99.81% <= 1.0 milliseconds
99.86% <= 1.1 milliseconds
99.90% <= 1.2 milliseconds
99.90% <= 1.5 milliseconds
99.91% <= 1.6 milliseconds
99.93% <= 1.7 milliseconds
99.93% <= 1.8 milliseconds
99.95% <= 1.9 milliseconds
99.96% <= 2 milliseconds
100.00% <= 2 milliseconds
110741.97 requests per second
====== INCR ======
  100000 requests completed in 0.82 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.96% <= 1 milliseconds
100.00% <= 1 milliseconds
121802.68 requests per second
====== LPUSH ======
  100000 requests completed in 0.83 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.95% <= 1 milliseconds
100.00% <= 1 milliseconds
120048.02 requests per second
====== RPUSH ======
  100000 requests completed in 0.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.86% <= 1 milliseconds
100.00% <= 1 milliseconds
116414.43 requests per second
====== LPOP ======
  100000 requests completed in 0.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.86% <= 1 milliseconds
100.00% <= 1 milliseconds
116279.07 requests per second
====== RPOP ======
  100000 requests completed in 0.83 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.96% <= 1 milliseconds
100.00% <= 1 milliseconds
120772.95 requests per second
====== SADD ======
  100000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.85% <= 1 milliseconds
100.00% <= 1 milliseconds
117370.89 requests per second
====== HSET ======
  100000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.92% <= 1 milliseconds
100.00% <= 1 milliseconds
117785.63 requests per second
====== SPOP ======
  100000 requests completed in 0.84 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.88% <= 1 milliseconds
100.00% <= 1 milliseconds
118483.41 requests per second
====== ZADD ======
  100000 requests completed in 0.83 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.92% <= 1 milliseconds
100.00% <= 1 milliseconds
120048.02 requests per second
====== ZPOPMIN ======
  100000 requests completed in 0.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.84% <= 1 milliseconds
100.00% <= 1 milliseconds
116959.06 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.94% <= 1 milliseconds
100.00% <= 1 milliseconds
117096.02 requests per second
====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 0.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.78% <= 1 milliseconds
100.00% <= 1 milliseconds
116414.43 requests per second
====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 0.84 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.82% <= 1 milliseconds
100.00% <= 1 milliseconds
118623.96 requests per second
====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 0.82 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.96% <= 1 milliseconds
100.00% <= 1 milliseconds
121802.68 requests per second
====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 0.84 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.90% <= 1 milliseconds
100.00% <= 1 milliseconds
118483.41 requests per second
====== MSET (10 keys) ======
  100000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
  host configuration "save": 10 2
  host configuration "appendonly": yes
  multi-thread: no
99.90% <= 1 milliseconds
100.00% <= 1 milliseconds
117924.53 requests per second
[root@192 redis-6.0.8]#

可以看到性能还是很高的。多数命令都在2ms内执行完成了。第二个命令就是monitor:

第三个命令就是慢查询,可以通过这种方式进行查询较慢的统计:

今天聊到的所有问题的通用解决方案从长期来看分为以下几个手段,结合各个问题和性能指标配合食用:

  • 让数据获取不再那么频繁,更多的页面静态化处理。
  • 给缓存加个缓存,构建多级缓存架构,Nginx缓存+Redis缓存+ehcache缓存
  • 让数据库更快,对数据库进行严重耗时的性能排查和优化,对数据库的瓶颈进行排查
  • 灾难预警机制,监控Redis服务器性能指标:CPU占用率、CPU使用率、内存容量、查询平均响应时间
  • 限流、降级,业务高峰期对非核心数据的访问进行限流,降低访问压力,牺牲一部分用户体验

这个解决方案其实适用于今天所有的缓存相关的问题,从入口到最终落地点整体进行把控,再结合各个具体问题的实践处理手段,达到一个稳定的防御机制。还有一个概念是缓存热备,缓存热备即当一台缓存服务器不可用时能实时切换到备用缓存服务器,不影响缓存使用。集群模式下,每个主节点都会有一个或多个从节点来当备用,一旦主节点挂点,从节点立即充当主节点使用,所以天然支持,这里不做讨论了

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
相关文章
|
4月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
|
2月前
|
缓存 数据库连接 数据库
缓存三剑客(穿透、击穿、雪崩)
缓存穿透指查询数据库和缓存中都不存在的数据,导致请求直接冲击数据库。解决方案包括缓存空对象和布隆过滤器。缓存击穿是大量请求访问同一个失效的热点数据,使数据库瞬间压力剧增,解决方法有提前预热、设置永不过期、加锁限流等。缓存雪崩是大量key同时失效,导致所有请求直达数据库,可通过引入随机过期时间缓解。三者分别对应单点爆破、全面崩塌等问题,需根据场景选择合适策略优化系统性能与稳定性。
162 0
|
2月前
|
存储 缓存 NoSQL
如何解决缓存击穿?
缓存击穿是指热点数据失效时大量请求直接冲击数据库,可能导致系统崩溃。解决方案包括:永不过期策略避免缓存失效瞬间的穿透;互斥锁控制并发访问;热点预热提前刷新缓存;熔断降级在数据库压力大时返回默认值;二级缓存降低Redis压力。实际中常组合使用多种方案,如热点预热+互斥锁+熔断降级,以提升系统稳定性与性能。
279 0
|
4月前
|
缓存 NoSQL Java
Redis+Caffeine构建高性能二级缓存
大家好,我是摘星。今天为大家带来的是Redis+Caffeine构建高性能二级缓存,废话不多说直接开始~
637 0
|
1月前
|
缓存 监控 安全
告别缓存击穿!Go 语言中的防并发神器:singleflight 包深度解析
在高并发场景中,多个请求同时访问同一资源易导致缓存击穿、数据库压力过大。Go 语言提供的 `singleflight` 包可将相同 key 的请求合并,仅执行一次实际操作,其余请求共享结果,有效降低系统负载。本文详解其原理、实现及典型应用场景,并附示例代码,助你掌握高并发优化技巧。
148 0
|
2月前
|
缓存 NoSQL 数据库
什么是缓存击穿
缓存击穿是指热点缓存key突然失效,导致大量并发请求直接冲击数据库,造成巨大压力。常见于高并发场景,如热门商品信息失效时。解决方法包括设置热点key永不过期、使用分布式锁、预热数据、熔断降级等,以保障系统稳定性。
378 0
|
4月前
|
消息中间件 缓存 NoSQL
基于Spring Data Redis与RabbitMQ实现字符串缓存和计数功能(数据同步)
总的来说,借助Spring Data Redis和RabbitMQ,我们可以轻松实现字符串缓存和计数的功能。而关键的部分不过是一些"厨房的套路",一旦你掌握了这些套路,那么你就像厨师一样可以准备出一道道饕餮美食了。通过这种方式促进数据处理效率无疑将大大提高我们的生产力。
168 32
|
4月前
|
缓存 NoSQL Java
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
94 5
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
|
6月前
|
缓存 监控 NoSQL
Redis--缓存击穿、缓存穿透、缓存雪崩
缓存击穿、缓存穿透和缓存雪崩是Redis使用过程中可能遇到的常见问题。理解这些问题的成因并采取相应的解决措施,可以有效提升系统的稳定性和性能。在实际应用中,应根据具体场景,选择合适的解决方案,并持续监控和优化缓存策略,以应对不断变化的业务需求。
1055 29
|
6月前
|
缓存 NoSQL Java
Redis应用—8.相关的缓存框架
本文介绍了Ehcache和Guava Cache两个缓存框架及其使用方法,以及如何自定义缓存。主要内容包括:Ehcache缓存框架、Guava Cache缓存框架、自定义缓存。总结:Ehcache适合用作本地缓存或与Redis结合使用,Guava Cache则提供了更灵活的缓存管理和更高的并发性能。自定义缓存可以根据具体需求选择不同的数据结构和引用类型来实现特定的缓存策略。
361 16
Redis应用—8.相关的缓存框架