数据库

Redis 是程序员工具箱里很容易被“过度信任”的东西。 它太顺手了。 想存个值，SET 一下。想自动过期，EXPIRE 一下。想做计数器，INCR 一下。想搞队列，LPUSH / BRPOP 一下。想搞锁，SET NX PX 一下。再看一眼 Stream，好像连消息系统也能顺手安排。 于是很多系统就这么一路滑坡： 第一天：Redis 只是缓存。 第二天：这个状态先放 Redis 吧。 第三天：队列也先放 Redis 吧。 第四天：库存扣减也先放 Redis 吧。 第五天：Redis 挂了，大家开始翻日志考古。 这篇文章想讲的观点很简单： Redis 能做很多事，但不要让它单独拥有真相。 如果一份数据不能丢、不能错、不能重复处理、不能悄悄过期、不能被内存策略淘汰，那它就不应该只待在 Redis 里。 Redis 最舒服的位置是缓存。它可以让系统跑得更快，但不应该决定系统还活不活得明白。 先看边界：缓存可以重建，事实不能只靠 Redis 先把话说在前面：这不是 Redis 不行。 Redis 很强，而且越来越强。它有 RDB，有 AOF，有复制，有 Sentinel，有 Cluster，有 Streams，还有很多高级数据结构。Redis 8 之后，JSON、Search、Time Series、概率数据结构等能力也被合进 Redis Open Source。 所以问题不是“Redis 能不能干更多活”。 问题是：你把活交给 Redis 之后，能不能接受它的失败方式。 缓存的失败方式很朴素： Redis 没了 -> 缓存 miss -> 回源数据库 -> 重新写缓存 这很烦，但不至于让业务当场失忆。 ...