凌晨三点程序员小王盯着爆红的服务器监控，电商大促页面突然卡死——库存显示还有货，用户却疯狂投诉"秒杀不到"。这时候要是懂Redis的字符串操作，哪用熬夜掉头发？今天咱们就用真实场景拆解，看看怎么用Redis的字符串、哈希、列表三大法宝搞定这些要命的问题。

??场景一：电商库存防超卖（字符串篇）??
当100万人同时抢100台手机，用数据库查库存就是找死。这时候掏出Redis的DECR命令：

shell复制
SET iphone15_stock 100  # 初始化库存
DECR iphone15_stock     # 原子操作减库存

这波操作妙在哪？就像超市收银员必须一个一个结账，DECR保证就算十万人同时下单，库存也不会变成负数。去年双十一某平台用这招，硬是把并发处理能力从500/s干到5万+/s。

等等！你可能要问："要是支付失败怎么回滚库存？" 这时候祭出INCR命令，再配合订单超时机制，妥妥解决。不过这里有个坑要注意：别用GET查库存给用户看，要用SETNX做分布式锁，否则照样崩给你看。

??场景二：社交平台用户资料管理（哈希篇）??
处理用户资料这种多字段数据，千万别用字符串存JSON！看看哈希结构怎么玩：

shell复制
HSET user:1001 name "张三" age 28 vip_level 5
HGET user:1001 vip_level  # 单独获取VIP等级
HINCRBY user:1001 followers 1  # 粉丝数+1

最近有个社交APP踩过大坑——他们把10万用户的资料全用字符串存，结果改个VIP等级要传输整个3KB的JSON。换成哈希结构后，数据传输量直接砍掉90%，每月省下2万多服务器费用。

??场景三：即时通讯消息队列（列表篇）??
微信消息为什么能实时收发不丢失？列表结构的LPUSH和BRPOP就是秘密武器：

shell复制
LPUSH chat:1001_2001 "晚上吃啥？"  # 左侧插入新消息
BRPOP chat:2001_1001 30           # 阻塞等待接收消息

这个组合拳比Kafka还简单粗暴，特别适合小型IM系统。上次给某在线教育平台做咨询，他们用这招实现了师生实时答疑，开发周期从3个月缩到2周。不过要注意消息堆积问题——列表长度超过1万就得考虑分片了。

??灵魂拷问时间??
Q：字符串也能存用户资料，为啥非用哈希？
A：就像你要改快递单上的收件人电话，没人会重新写整张面单。哈希可以精准修改单个字段，省流量又提速度。

Q：列表做消息队列万一服务器挂了怎么办？
A：Redis有持久化配置，设置成每秒同步一次磁盘，最多丢1秒数据。重要消息还是得走专业消息中间件，别把Redis当万金油。

（小编观点：见过最离谱的是有人用列表存了10亿条日志，结果集群内存爆到200G。记住——Redis是瑞士军刀不是砍柴刀，千万别拿它当Hadoop使！）