Redis读写那些事儿，怎么用才更顺手和高效呢？

引用自知乎专栏“Redis实战精讲”、掘金小册“Redis深度历险”以及部分官方文档的解读）

Redis这个东西，说白了就是一个速度超快的“大字典”，数据都放在内存里，所以读写的速度比传统数据库快上百倍，但要想用得顺手，不让它成为系统的瓶颈，还是有不少门道的,咱们今天就聊聊怎么把它用得更高效。

写数据：不只是简单的SET

很多人觉得写Redis就是SET key value,但其实里面有不少讲究。

要不要等它写完？ Redis默认的写操作是“发后即忘”的，也就是说，客户端发一个SET命令，收到一个“OK”的回复，就认为成功了，这在绝大多数场景下没问题，速度也最快，但如果你对数据一致性要求极高，比如扣减库存，绝对不能出错，那么可以考虑使用WAIT命令（来源于Redis官方文档关于数据同步的说明），WAIT命令能强制要求当前写操作至少同步到指定数量的从库上，才算成功，这样能极大降低数据丢失的风险，但代价是写操作的延迟会变高，这是一把双刃剑,要根据业务场景权衡。

一次写一个还是一批？ 如果你需要初始化一批数据，比如一万个用户信息，最笨的办法是循环一万次SET命令，但这样做效率极低，因为每次命令都有网络往返的时间开销，正确的做法是使用管道（Pipeline）（参考“Redis深度历险”核心原理篇），管道可以把多个命令打包，一次性地发送给Redis服务器，服务器处理完后再一次性返回结果，这大大减少了网络IO的次数，性能提升非常显著，有时能达到10倍甚至更高的效果，这就好比你要搬十箱书下楼，一趟一趟跑效率低,找个大箱子一次全搬下去就快多了。

写的时候要注意Key的生存时间，很多数据是有时效性的，比如短信验证码、网页缓存，直接用SETEX命令或者在SET后使用EXPIRE命令给Key设置一个过期时间（TTL），让Redis自动帮你清理过期数据，这是非常棒的特性，能省去你手动管理的麻烦,也防止内存被无用数据占满。

读数据：避开陷阱，找对方法

读数据看似简单,但坑也不少。

最经典的坑就是缓存穿透（知乎专栏“Redis实战精讲”中高频面试题解析），它指的是去查询一个根本不存在的数据，有人恶意攻击，频繁请求一个不存在的用户ID，这个请求会穿过Redis（因为没缓存），直接打到后端的数据库上，导致数据库压力巨大，解决办法有两个：一是如果从数据库没查到，也在Redis里缓存一个空值（比如SET key-null 5），并设置一个很短的过期时间，二是使用布隆过滤器（Bloom Filter） 这种数据结构，在查询前先做个初步筛选，如果布隆过滤器说“不存在”，那这个Key肯定不存在，直接返回,就不用查Redis和数据库了。

另一个常见问题是缓存雪崩，它指的是在同一时刻，大量的缓存Key同时失效，导致所有请求瞬间都涌向数据库，造成数据库崩溃，避免的方法很简单：给缓存Key的过期时间加上一个随机值，原本都设置1小时过期，现在可以改成1小时加上一个0到5分钟的随机数，这样就能保证Key不会在同一时间点大面积失效,把请求分摊开。

选择合适的读命令也很重要，你要获取一个哈希（Hash）类型的所有字段和值，不要用HGETALL吗？对于字段非常多的Hash，HGETALL可能会一次性返回大量数据，占用很多网络带宽，如果你只需要其中几个字段，用HMGET指定字段来获取会更高效，同样，对于列表（List）类型，如果不确定长度，尽量不要用LRANGE 0 -1一次性获取所有元素,可能会很慢。

数据结构和命令的“门当户对”

Redis快，很大程度上是因为它丰富的数据结构，用对数据结构,效率天差地别。

• String（字符串）：最简单的类型，缓存简单的字符串、数字、序列化后的对象都很合适。
• Hash（哈希）：非常适合存储对象，比如一个用户的姓名、年龄、城市等信息，可以用一个Key（user:123）对应多个字段，这样在修改用户某个属性时，可以直接操作单个字段,而不用序列化整个对象。
• List（列表）：可以做简单的消息队列（LPUSH/RPOP），或者记录最新N个动态（LTRIM）。
• Set（集合）：天然去重，适合存储标签、共同好友等。
• ZSet（有序集合）：带分数的集合，可以做排行榜、延时队列等。

选对了数据结构，你的操作命令自然就会更高效，比如要做排行榜,你用List和ZSet的实现复杂度和性能完全不是一个量级。

一些“顺手”的小贴士

1. Key的设计要清晰：使用冒号分隔的命名空间，user:1001:profile，order:20231001:items，这样既清晰，又方便用KEYS或SCAN命令模式查找（生产环境慎用KEYS）。
2. 警惕大Key：一个String类型的Value有好几MB，或者一个Hash有几万个字段，这都是“大Key”，大Key会拖慢持久化、主从复制的速度，在集群模式下还可能导致数据倾斜,尽量把大Key拆小。
3. 使用SCAN替代KEYS：KEYS命令在数据量大的时候会阻塞Redis，非常危险,遍历Key一定要用非阻塞的SCAN命令。
4. 监控不能少：关注Redis的内存使用率、连接数、慢查询日志，慢查询日志能帮你发现哪些命令执行得太慢,从而有针对性地优化。

想让Redis更顺手高效，核心思路就是：写数据时考虑批量化和持久化需求，读数据时做好防护避免击穿底层数据库，并根据业务特点选择最合适的数据结构。 它不是简单的键值存储，而是一个功能丰富的内存数据结构服务器，理解并善用它的特性,才能真正发挥其威力。