1

简介: 1

也可以使用降级来保护这个缓存 - 数据库结构。正常来说,使用缓存基本都是先从缓存里读数据,然后缓存里没有数据,再从数据库中读取。
在触发降级的情况下,可以考虑只从缓存里读取。如果缓存里没有,也不会再去数据库读取。这样可以保证缓存里有数据的请求可以得到正常处理,也就是提供了有损服务。

这种降级方案背后的逻辑也很简单。如果完全不考虑从数据库里取数据,那么你的性能瓶颈就完全取决于缓存或者说 Redis,那么服务能够撑住的 QPS 会非常高。但是,如果缓存不命中的时候要去数据库取数据,那么服务的性能会衰退得非常快,即极少数缓存未命中的请求会占据大部分的系统资源。

你可以这样回答,关键词是只查缓存。

目录
打赏
0
0
0
0
108
分享
相关文章
|
7月前
|
【第十六期乘风伯乐奖】获奖名单出炉,快来看看本期谁是社区伯乐!
【第十六期乘风伯乐奖】获奖名单出炉,快来看看本期谁是社区伯乐!
120 11
|
8月前
|
分库分表键的选择 重试方案
【7月更文挑战第19天】
91 5
|
9月前
|
Redis大key问题 - 优化、清理
【6月更文挑战第14天】Redis内置命令如STRLEN、LLEN等用于检测不同类型Key的大小。避免使用DEBUG OBJECT和MEMORY USAGE因高资源消耗。大Key优化包括业务设计避免大Key、数据拆分、更换存储方案、数据压缩和合理清理。清理大Key应选低峰期或分批异步进行,以减少阻塞。使用如HSCAN、SREM等命令避免一次性操作大量数据。
131 1
|
9月前
|
Redis大Key问题 - 标准、原因、查找
【6月更文挑战第13天】**大Key标准**在不同场景各异,一般string超1MB或容器超10k元素视为大;高并发场景中,string超10KB,容器超5k或整体10MB。**阿里云Redis**中,大Key可能表现为String值5MB,ZSET成员10k,或Hash总值100MB。**大Key影响**包括高读取成本、操作阻塞、存储压力不均。**产生原因**多源于业务设计、动态增长管理和程序错误。**查找大Key**可通过云服务的实时/离线统计,`redis-cli --bigkeys`或使用Redis RDB Tools分析RDB文件。注意,某些特定需求可能需额外工具。
156 1
MongoDB优化分页
【7月更文挑战第5天】
112 0