Redis on Zampo Blog

写出 Redis 的人，为什么宁愿当个糟糕的艺术家？

Fri, 10 Apr 2026 15:44:00 +0800

程序员工作场景。图片来源：Pexels

很多人认识 Redis，是从性能图表开始的。

它快，轻，几乎成了现代互联网的基础设施。缓存、排行榜、消息队列、实时分析，背后经常都站着它。可真正让我记住 Redis 的，不是这些功能，而是它的作者在 2020 年说的一句话：

“I never wanted to be a software maintainer.”

我从来不想成为一个软件维护者。

这句话很刺耳。

因为它等于承认了一件很多人不愿意承认的事：一个写出世界级系统的人，未必真的想一辈子为这个系统擦地板、补漏洞、回 issue、扛期待。

他叫 Salvatore Sanfilippo，江湖名字 antirez。1977 年出生在意大利西西里岛，后来长期住在 Catania。和硅谷叙事里那种一路融资、一路扩张、一路当 CEO 的技术偶像不一样，他更像一个写代码的隐士：住在岛上，做开源，写博客，后来还去写科幻小说。

Sat, 04 Apr 2026 12:10:00 +0800

很多人觉得 Redis 没什么门槛。

命令不难，接入也快，压测时还总能打出很漂亮的数字。于是项目上线后，大家默认它“应该不会出事”。

但我看过不少 Redis 问题，最后都不是 Redis 自己不行，而是前面的设计太随便：Key 怎么拆，TTL 怎么设，热点怎么扛，内存打满以后怎么办，这些事一开始没想清楚，后面都会用线上故障补课。

我最近刷到一条讲 Redis 避坑的短视频，里面提到的点很典型。我没有照着转写，而是按“线上最容易出事故的顺序”重新整理成这篇文章。

如果你只记一句话，那就是：

Redis 真正危险的坑，大多不是命令层面的，而是设计层面的。

Thu, 02 Apr 2026 21:30:00 +0800

1974 年，IBM 捣鼓出了世界上第一个关系数据库。

50 年过去了，Oracle、MySQL、PostgreSQL 这些 RDB 依然霸榜。年轻程序员嘴上喊着 “SQL 太土”，项目里该用还是用。

有意思的是，每隔几年就冒出一堆"未来数据库"来挑战 RDB 的地位：Key-Value Store、MapReduce、Hadoop、图数据库、向量数据库……

我都用过。所以我知道为什么它们最后都凉了。

Redis 是 KVS 的典型代表，用 Key 找 Value，简单粗暴。

缓存用它，完美。问题是做开发的总有点执念，非要把缓存以外的事情也塞给它。

我当年做物联网项目就载过这个跟头。

当时选 Redis 考虑两个因素：一是物联网系统里大部分是文件，数据库只管组件状态；二是终端用 SD 卡，磁盘 IO 寿命短，想省着用。

结果第三个月就开始出问题了。

物联网环境里，网络和电源都不可靠，随时可能断电断网。每一个组件的状态管理变得极其复杂——在 Redis 上，你要用 Array、Set、HashMap 来描述一个简单的"任务运行状态"，换成 SQLite 的话，一个表加几条 SQL 就搞定了。

最后项目里一半以上的 Bug 都跟这个定制 Redis 数据结构有关。就在写这篇文章的时候，我们还在修一个诡异的 Bug：终端下载视频时遇到网络问题，紧接着又断电，Redis 里的任务信息不完整，视频永远下不下来。

你说这值不值？

为了省 SD 卡那点读写寿命，被折腾了好几年。

第一个 KVS 是 AT&T 在 1979 年发布的，叫 DBM。发明者？又是那个男人。

MapReduce 不是数据库，是 Google 提出的一种分布式数据处理思路。

Map 对应 SQL 里的 WHERE + ORDER BY，Reduce 对应 GROUP BY。说白了就是把 SQL 的逻辑拆到多台服务器上跑。