【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数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 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
相关文章
|
1月前
|
缓存 NoSQL 关系型数据库
大厂面试高频:如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题
本文详解缓存雪崩、缓存穿透、缓存并发及缓存预热等问题,提供高可用解决方案,帮助你在大厂面试和实际工作中应对这些常见并发场景。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题
|
1月前
|
存储 缓存 NoSQL
【赵渝强老师】基于Redis的旁路缓存架构
本文介绍了引入缓存后的系统架构,通过缓存可以提升访问性能、降低网络拥堵、减轻服务负载和增强可扩展性。文中提供了相关图片和视频讲解,并讨论了数据库读写分离、分库分表等方法来减轻数据库压力。同时,文章也指出了缓存可能带来的复杂度增加、成本提高和数据一致性问题。
【赵渝强老师】基于Redis的旁路缓存架构
|
18天前
|
缓存 NoSQL 数据库
缓存穿透、缓存击穿和缓存雪崩及其解决方案
在现代应用中,缓存是提升性能的关键技术之一。然而,缓存系统也可能遇到一系列问题,如缓存穿透、缓存击穿和缓存雪崩。这些问题可能导致数据库压力过大,甚至系统崩溃。本文将探讨这些问题及其解决方案。
|
26天前
|
缓存 NoSQL PHP
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
37 5
|
1月前
|
缓存 NoSQL 中间件
redis高并发缓存中间件总结!
本文档详细介绍了高并发缓存中间件Redis的原理、高级操作及其在电商架构中的应用。通过阿里云的角度,分析了Redis与架构的关系,并展示了无Redis和使用Redis缓存的架构图。文档还涵盖了Redis的基本特性、应用场景、安装部署步骤、配置文件详解、启动和关闭方法、systemctl管理脚本的生成以及日志警告处理等内容。适合初学者和有一定经验的技术人员参考学习。
179 7
|
2月前
|
存储 缓存 NoSQL
数据的存储--Redis缓存存储(一)
数据的存储--Redis缓存存储(一)
99 1
|
2月前
|
存储 缓存 NoSQL
数据的存储--Redis缓存存储(二)
数据的存储--Redis缓存存储(二)
52 2
数据的存储--Redis缓存存储(二)
|
2月前
|
消息中间件 缓存 NoSQL
Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。
【10月更文挑战第4天】Redis 是一个高性能的键值对存储系统,常用于缓存、消息队列和会话管理等场景。随着数据增长,有时需要将 Redis 数据导出以进行分析、备份或迁移。本文详细介绍几种导出方法:1)使用 Redis 命令与重定向;2)利用 Redis 的 RDB 和 AOF 持久化功能;3)借助第三方工具如 `redis-dump`。每种方法均附有示例代码,帮助你轻松完成数据导出任务。无论数据量大小,总有一款适合你。
78 6
|
2月前
|
缓存 NoSQL 关系型数据库
redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿
本文深入探讨了Redis缓存的相关知识,包括缓存的概念、使用场景、可能出现的问题(缓存预热、缓存穿透、缓存雪崩、缓存击穿)及其解决方案。
214 0
redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿
|
1月前
|
缓存 NoSQL Redis
Redis 缓存使用的实践
《Redis缓存最佳实践指南》涵盖缓存更新策略、缓存击穿防护、大key处理和性能优化。包括Cache Aside Pattern、Write Through、分布式锁、大key拆分和批量操作等技术,帮助你在项目中高效使用Redis缓存。
229 22