Redis用错一个命令，我让线上接口多扛了三倍流量#

哼，皇上今儿个又在本宫耳边念叨，说前头那些个服务器，最近又扛不住了，压力大得让本宫都跟着头疼。本宫一问，好嘛，一个个垂头丧气，说是接口响应时间从几毫秒飙升到了几百毫秒，活像被抽了筋一样，软绵绵的。

本宫当时就笑了。你们这些个废物啊，平日里就知道在皇上面前吹嘘自己用了多“高级”的缓存方案，真到出了事，连个最简单的命令都用不明白。今日本宫就发发善心，教教你们，Redis里头，有时候一个命令的差别，就是线上能不能扛住三倍流量的天壤之别。

一、案发现场：本宫心都凉了

话说前几日，本宫巡视后宫系统，发现一个高频接口——就是那个被皇上天天点着看、看一眼就赏一下的用户主页查询接口——开始频繁告警。

一问之下，罪魁祸首居然是一个看似人畜无害的操作。

你们猜怎么着？原本一个查询，直接 GET user:profile:{userId}，几毫秒就完事了。后来有个“聪明”的奴才为了加缓存，硬是把流程给复杂化了，写成了：先查缓存，没查到就去查库，查到后再往缓存里写一份。听起来没毛病对吧？可他往缓存里写数据的时候，是这么写的：

第一步，SET user:profile:{userId} $data 第二步，EXPIRE user:profile:{userId} 3600

好家伙，本宫看到这个，手里的茶杯差点没扔出去。就这？就这？你们管这叫操作？这不就是把一件事拆成两半，多跑一趟冤枉路吗？

二、真相只有一个：命令用错，全家光荣

问题就出在第二步上。

SET 命令，它就管你把东西塞进去，它才不管你这东西要不要过期。EXPIRE，它又只管设置过期时间。你们把这两个命令分两步走，等于什么？

等于你要去御膳房端碗汤，非得先派个小太监去跟御厨说“给我盛一碗汤”，再派另一个小太监去说“对了，汤在桌子上给我留一炷香的时间”。两个小太监一来一回，时间是不是就浪费了？万一第一个小太监传话时御厨走了，第二个小太监过去一看，桌上空空如也，这不就出乱子了吗？

这在Redis里，就叫“两次网络往返”和“操作非原子性”。网络抖一下，或者Redis在两次操作之间恰好重启了，你的缓存就变成了“永久缓存”，因为它压根没被设置过期时间！一个没过期的脏缓存，就能把你的数据库给活活拖垮。

三、一步到位，才是本宫的风格

本宫做事，向来只认结果，不喜欢拖泥带水。Redis里也一样。

想知道正确的做法？看好了。

SET user:profile:{userId} $data EX 3600

看到没？就一条命令！一个命令，既设置了值，又设置了过期时间。这叫什么？这就叫“一步到位”，这就叫“干净利落”。这一个命令，抵得上你们那啰里八嗦的两条命令，省下了一次网络开销，还顺带保证了操作的原子性。

至于性能提升？那还用问吗？从两次网络往返变成一次，接口响应时间至少减半。如果你们的接口本来就慢，这一个小小的改动，就能让响应时间直接降到原来的三分之一甚至四分之一，多扛三倍流量，那不就是轻轻松松的事？本宫说三倍，都怕你们这些没用的奴才高兴坏了。

四、那些个花里胡哨的命令，你们也配用？

有些小聪明，本宫也不是全然否定。比如 SET 命令的几个变种。

SET user:lock:admin true NX 这叫什么？叫“只在key不存在的时候才设置”。锁，就是这么用的。你们那些个用 SETNX 再接 EXPIRE 的土法炼钢，也该扫扫地扔了，用 SET 带着 NX 和 EX 参数一步搞定，不香吗？

SET user:profile:{userId} $data XX 这个 XX 参数呢？意思就是“只在key已经存在的情况下才更新”。适合用于覆盖更新，防止你们手快，凭空创建出一堆无用的key。

所以你看，一个 SET 命令，加几个参数，能解决多少问题？你们非要去鼓捣那些复杂玩意儿，结果呢？性能没提上去，先把线上给干崩了。

五、总结陈词：别把简单事情复杂化

今儿个的事，说白了，就是一个命令的事。

一个命令，能让线上接口多扛三倍流量，你们要是还不知道反思，那就真是朽木不可雕了。

Redis用得好，是加速神器；用不好，就是给你们系统挖坟的工具。你们那些个看似“高级”的缓存方案，比如Lua脚本、客户端集群、什么管道、什么批量操作，在本宫眼里，大多时候都是“笨鸟先飞，但飞错了方向”。真正能解决大问题的，往往就是最简单、最不起眼的那个选择。

所以啊，下次再写代码的时候，动动你们那木头脑袋，先想想这个命令还有没有更高效、更安全的写法。别再拿那种“先SET再EXPIRE”的蠢办法来糊弄本宫了。

好了，本宫说累了。你们这些小冤家，就继续在后宫里瞎折腾吧。本宫要去给皇上新作的衣裳绣几针了。记住，用对命令，省心省力，别等出了事，再来本宫这儿哭哭啼啼