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

本文涉及的产品
云数据库 Redis 版,标准版 2GB
推荐场景:
搭建游戏排行榜
云原生内存数据库 Tair,内存型 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数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
27天前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
27天前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题?分布式情况下如何添加分布式锁
这篇文章介绍了如何在SpringBoot项目中整合Redis,并探讨了缓存穿透、缓存雪崩和缓存击穿的问题以及解决方法。文章还提供了解决缓存击穿问题的加锁示例代码,包括存在问题和问题解决后的版本,并指出了本地锁在分布式情况下的局限性,引出了分布式锁的概念。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题?分布式情况下如何添加分布式锁
|
28天前
|
缓存 数据库
缓存穿透和击穿
【8月更文挑战第16天】
32 0
缓存穿透和击穿
|
21天前
|
缓存 NoSQL 网络安全
【Azure Redis 缓存】Azure Redis服务开启了SSL(6380端口), PHP如何访问缓存呢?
【Azure Redis 缓存】Azure Redis服务开启了SSL(6380端口), PHP如何访问缓存呢?
|
21天前
|
缓存 NoSQL Redis
【Azure Redis 缓存】Redission客户端连接Azure:客户端出现 Unable to send PING command over channel
【Azure Redis 缓存】Redission客户端连接Azure:客户端出现 Unable to send PING command over channel
|
21天前
|
缓存 NoSQL 网络协议
【Azure Redis 缓存】Lettuce 连接到Azure Redis服务,出现15分钟Timeout问题
【Azure Redis 缓存】Lettuce 连接到Azure Redis服务,出现15分钟Timeout问题
【Azure Redis 缓存】Lettuce 连接到Azure Redis服务,出现15分钟Timeout问题
|
17天前
|
缓存 NoSQL Java
Redis深度解析:解锁高性能缓存的终极武器,让你的应用飞起来
【8月更文挑战第29天】本文从基本概念入手,通过实战示例、原理解析和高级使用技巧,全面讲解Redis这一高性能键值对数据库。Redis基于内存存储,支持多种数据结构,如字符串、列表和哈希表等,常用于数据库、缓存及消息队列。文中详细介绍了如何在Spring Boot项目中集成Redis,并展示了其工作原理、缓存实现方法及高级特性,如事务、发布/订阅、Lua脚本和集群等,帮助读者从入门到精通Redis,大幅提升应用性能与可扩展性。
39 0
|
21天前
|
缓存 NoSQL Redis
【Azure Redis 缓存】使用StackExchange.Redis,偶发ERROR - Timeout performing HSET (15000ms)
【Azure Redis 缓存】使用StackExchange.Redis,偶发ERROR - Timeout performing HSET (15000ms)
|
21天前
|
缓存 NoSQL Java
【Azure Redis 缓存】示例使用 redisson-spring-boot-starter 连接/使用 Azure Redis 服务
【Azure Redis 缓存】示例使用 redisson-spring-boot-starter 连接/使用 Azure Redis 服务
|
1天前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案