Redis缓存模式多样，实际用起来才发现它真不止一种玩法

综合参考自知乎专栏“架构师之路”、微信公众号“码农翻身”的部分文章观点，以及一些技术博客如“程序员小灰”关于缓存模式的通俗解读）

说起Redis，很多人第一反应就是：“哦，那个缓存数据库。” 然后脑子里可能浮现出一个简单的场景：查询数据库太慢，就把数据丢到Redis里，下次来查，直接读Redis，速度飞快，这没错，这是Redis最经典、最基础的玩法，通常被叫做“缓存”（Cache-Aside Pattern），但如果你以为Redis就这点本事，那可就太小看它了，在实际用起来之后，你会发现，根据不同的业务场景，Redis能变换出好几种“花样”,每种玩法都能解决特定的大麻烦。

第一种玩法：经典挡箭牌（Cache-Aside）

这就像你家门口有个专门帮你收快递的保安，你要拿快递（查询数据），先问保安（查Redis），保安手上有（缓存命中），直接给你，省得你跑一趟快递柜（数据库），保安手上没有（缓存未命中），你就得自己去快递柜取，拿回来之后，顺手告诉保安一声，下次再有这个快递，你就直接找他，这种方式最简单直接，代码也好写，但缺点是你得每次都“问”一下保安，如果遇到像“双十一”那种疯狂查一种商品信息的场景，万一保安那里没有（缓存失效），瞬间所有人都会涌向快递柜（数据库），可能导致柜子被挤爆（数据库压力激增），这就是所谓的“缓存击穿”风险。

第二种玩法：先知预加载（Read-Through/Write-Through）

这种方式更省心一点，你还是找保安拿快递，但这个保安特别有责任心，他跟快递柜（数据库）是联动的，只要你问的快递他那里没有，他不会让你自己去取，而是他主动跑去帮你取回来，登记好，再递给你，甚至，当你买了新东西要寄存（写入数据）时，你只需要交给保安，保安会负责同时做好两件事：一是自己登记一份，二是帮你存进快递柜，这样你就完全不用操心数据库了，所有操作都通过缓存层代理，这种模式通常需要一些专门的缓存框架来支持,让你的应用代码更简洁。

第三种玩法：后勤总管（Write-Behind）

这个玩法就更高级了，还是那个保安，但这次你寄快递时，只需要把快递交给保安就可以走了，非常快，保安不会立刻跑去存快递柜，而是先帮你收着，攒一波之后，再找个空闲时间批量存进快递柜，这样做的好处是，写数据的速度飞快，用户体验极好，因为应用不需要等待慢速的数据库操作，特别适合像秒杀扣库存、频繁更新用户点赞数这类场景，先保证操作快速完成，后续的数据持久化由缓存层异步慢慢处理，但风险在于，如果保安突然下岗了（缓存服务崩溃），他手里那一批还没存进柜子的快递（数据）就可能丢失,这种玩法用在允许少量数据丢失的场景下非常给力。

第四种玩法：保险柜（Cache-As-SoR）

这种模式下，Redis不再是单纯的“缓存”了，它自己就变成了一个主要的“保险柜”（System of Record），一些对速度要求极高、且数据量不是天大的数据，就直接存在Redis里，把它当成一个高性能的数据库来用，比如用户的购物车信息、游戏的实时会话数据、排行榜等，这些数据的特点是需要极快的读写，而且即使偶尔丢失一部分，也能从其他逻辑中恢复或重建，这时候，Redis就从“临时工”升级成了“正式工”。

第五种玩法：热点数据狙击手（应对缓存穿透/雪崩）

这不算一种独立的模式，而是基于经典玩法之上的“神操作”，有人恶意查询一个根本不存在的数据（比如不存在的商品ID），每次都会绕过缓存打到数据库上，这就是“缓存穿透”，对付它，可以在保安那里放一个“黑名单”（缓存空值），告诉他，这个编号的快递不存在，你直接回复我没有就行，别再去问快递柜了，而“缓存雪崩”是指大量缓存同时失效，导致请求像雪崩一样砸向数据库，解决办法可以是给不同的缓存数据设置随机的过期时间，让它们别在同一时刻集体失效，就像把员工的休息时间错开,保证始终有人站岗。

你看，Redis这玩意儿，真不是一把简单的钥匙，它像是一把多功能瑞士军刀，基础功能是开瓶器，但用熟了你会发现它还有小刀、锯子、螺丝刀……不同的场景，掏出不同的工具组合，才能最高效、最稳妥地解决问题，刚开始你可能只用了最简单的缓存，但随着业务变得复杂，你会自然而然地探索到这些更精细的玩法，那时候你才会真正感叹：“原来它还有这一手！”