1

简介: 1

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

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

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

目录
相关文章
|
9月前
|
关系型数据库 MySQL 数据库
【MySQL实战笔记】 06 | 全局锁和表锁 :给表加个字段怎么有这么多阻碍?-01
【4月更文挑战第17天】MySQL的锁分为全局锁、表级锁和行锁。全局锁用于全库备份,可能导致业务暂停或主从延迟。不加锁备份会导致逻辑不一致。推荐使用`FTWRL`而非`readonly=true`因后者可能影响其他逻辑且异常处理不同。表级锁如`lock tables`限制读写并限定操作对象,常用于并发控制。元数据锁(MDL)在访问表时自动加锁,确保读写正确性。
172 31
|
9月前
|
定位技术 计算机视觉
|
9月前
|
数据库 索引
评论功能里数据库的设计
【4月更文挑战第2天】本文探讨了评论系统的树形结构设计,提出了四种方法:邻接表、分段式path、Nested Set和Closure Table。针对评论业务功能,如加载评论页和查看回复,优先考虑邻接表和分段式path。采用邻接表思路,设计了评论表结构,包括Uid、Biz、BizID、RootID、PID、Content、索引和级联删除规则。同时提到了索引设计,如Uid、Biz+BizID、PID和Ctime/Utime,以优化查询性能。
166 3
|
5月前
|
人工智能
|
6月前
|
开发者
【第十六期乘风伯乐奖】获奖名单出炉,快来看看本期谁是社区伯乐!
【第十六期乘风伯乐奖】获奖名单出炉,快来看看本期谁是社区伯乐!
113 11
|
7月前
|
中间件 索引
分库分表键的选择 重试方案
【7月更文挑战第19天】
79 5
|
8月前
|
运维 开发者
|
8月前
|
NoSQL Redis 存储
Redis大key问题 - 优化、清理
【6月更文挑战第14天】Redis内置命令如STRLEN、LLEN等用于检测不同类型Key的大小。避免使用DEBUG OBJECT和MEMORY USAGE因高资源消耗。大Key优化包括业务设计避免大Key、数据拆分、更换存储方案、数据压缩和合理清理。清理大Key应选低峰期或分批异步进行,以减少阻塞。使用如HSCAN、SREM等命令避免一次性操作大量数据。
114 1
|
8月前
|
NoSQL Redis 容器
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文件。注意,某些特定需求可能需额外工具。
130 1