【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使用率、内存容量、查询平均响应时间
  • 限流、降级,业务高峰期对非核心数据的访问进行限流,降低访问压力,牺牲一部分用户体验

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

相关文章
|
3月前
|
缓存 数据库连接 数据库
缓存三剑客(穿透、击穿、雪崩)
缓存穿透指查询数据库和缓存中都不存在的数据,导致请求直接冲击数据库。解决方案包括缓存空对象和布隆过滤器。缓存击穿是大量请求访问同一个失效的热点数据,使数据库瞬间压力剧增,解决方法有提前预热、设置永不过期、加锁限流等。缓存雪崩是大量key同时失效,导致所有请求直达数据库,可通过引入随机过期时间缓解。三者分别对应单点爆破、全面崩塌等问题,需根据场景选择合适策略优化系统性能与稳定性。
218 0
|
3月前
|
缓存 数据库
如何解决缓存穿透?
对请求增加校验机制,如ID格式和位数校验,避免无效请求;缓存空值或特殊值防止缓存穿透;使用布隆过滤器拦截不存在的请求,减轻数据库压力。
42 0
|
7月前
|
缓存 监控 NoSQL
Redis--缓存击穿、缓存穿透、缓存雪崩
缓存击穿、缓存穿透和缓存雪崩是Redis使用过程中可能遇到的常见问题。理解这些问题的成因并采取相应的解决措施,可以有效提升系统的稳定性和性能。在实际应用中,应根据具体场景,选择合适的解决方案,并持续监控和优化缓存策略,以应对不断变化的业务需求。
1298 29
|
7月前
|
缓存 数据库
什么是缓存穿透 ? 怎么解决 ?
缓存穿透是指查询一条数据库和缓存都没有的一条数据,就会一直查询数据库,对数据库的访问压力就会增大,缓存穿透的解决方案 有以下2种解决方案 : ● 缓存空对象:代码维护较简单,但是效果不好。 ● 布隆过滤器:代码维护复杂,效果很好
|
5月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
|
16天前
|
存储 缓存 NoSQL
Redis专题-实战篇二-商户查询缓存
本文介绍了缓存的基本概念、应用场景及实现方式,涵盖Redis缓存设计、缓存更新策略、缓存穿透问题及其解决方案。重点讲解了缓存空对象与布隆过滤器的使用,并通过代码示例演示了商铺查询的缓存优化实践。
100 1
Redis专题-实战篇二-商户查询缓存
|
5月前
|
缓存 NoSQL Java
Redis+Caffeine构建高性能二级缓存
大家好,我是摘星。今天为大家带来的是Redis+Caffeine构建高性能二级缓存,废话不多说直接开始~
726 0
|
16天前
|
缓存 NoSQL 关系型数据库
Redis缓存和分布式锁
Redis 是一种高性能的键值存储系统,广泛用于缓存、消息队列和内存数据库。其典型应用包括缓解关系型数据库压力,通过缓存热点数据提高查询效率,支持高并发访问。此外,Redis 还可用于实现分布式锁,解决分布式系统中的资源竞争问题。文章还探讨了缓存的更新策略、缓存穿透与雪崩的解决方案,以及 Redlock 算法等关键技术。
|
5月前
|
消息中间件 缓存 NoSQL
基于Spring Data Redis与RabbitMQ实现字符串缓存和计数功能(数据同步)
总的来说,借助Spring Data Redis和RabbitMQ,我们可以轻松实现字符串缓存和计数的功能。而关键的部分不过是一些"厨房的套路",一旦你掌握了这些套路,那么你就像厨师一样可以准备出一道道饕餮美食了。通过这种方式促进数据处理效率无疑将大大提高我们的生产力。
191 32
|
5月前
|
缓存 NoSQL Java
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
109 5
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡

热门文章

最新文章