Redis 不只是“更快的 key-value”。它的价值在于数据结构丰富、过期机制简单、读写性能高，并且能在缓存、计数、队列、排行榜、分布式锁等场景里提供轻量能力。
先把基础命令记成语义
SET 的几个选项很常用：
EX：设置过期时间。NX：key 不存在时才写入，常用于抢锁或防重复创建。XX：key 已存在时才更新。
遇到 (error) NOAUTH Authentication required，说明实例开启了密码认证，需要先执行认证命令。
命令不必死记，关键是理解它们的业务语义：是否允许覆盖，是否需要过期，是否必须原子。
数据结构要按业务模型选
String 适合最简单的 key-value，例如验证码、配置、简单计数。
Hash 适合对象详情，例如用户详情、商品详情、文章摘要。它比把整个对象序列化成字符串更方便局部字段更新。
List 保持顺序，适合简单队列、最新列表、固定长度列表。LPUSH + RPOP 可以表达队列，LPUSH + LTRIM 可以维护有限集合。
Set 无序且去重，适合标签、好友关系、抽奖候选、交集并集差集。
Sorted Set 增加 score，适合排行榜、延迟队列、按权重排序的数据。
选结构前先问：是否需要顺序，是否需要去重，是否需要按分数排序，是否需要局部字段更新。
缓存模式要关注一致性
最常见的是旁路缓存：先读 Redis，没命中再读数据库，然后回填 Redis。这个模式简单，但要处理缓存穿透、击穿和过期后的重建。
另一种是写入时同步更新缓存，实时性更好，但业务代码和缓存逻辑耦合更强，也更容易出现数据库成功、缓存失败的边界。
很多场景优先选择删除缓存，而不是直接更新缓存。数据库更新成功后删除缓存，下次读取再重建，可以减少缓存和数据库之间的复杂同步逻辑。
分布式锁要小心过期和释放
Redis 单线程执行命令，配合 SET key value NX EX seconds 可以做基础分布式锁。
但分布式锁不能只写 setnx。至少要考虑：
- 锁必须有过期时间，避免持锁进程挂掉后永久死锁。
- value 要有唯一标识，释放时只能释放自己持有的锁。
- 业务执行时间可能超过锁过期时间，需要评估续期或缩短临界区。
- 锁保护的代码范围越小越好。
复杂场景建议使用成熟客户端，例如 Redisson，而不是手写半套锁协议。
秒杀类场景要先削峰
秒杀系统用 Redis 的目标不是把所有逻辑塞进缓存，而是减少数据库直面高并发。
常见做法包括：提前预热商品和库存，库存扣减在 Redis 中先做原子控制，订单创建异步化，再通过消息队列和数据库做最终落库。活动结束后还要做数据核对和补偿。
这里 Redis 承担的是削峰、计数和快速状态判断，不应该替代所有业务一致性设计。
实用结论
Redis 设计的关键是先选对数据结构，再明确一致性边界。
String、Hash、List、Set、Sorted Set 对应不同业务模型；过期时间、原子命令、分布式锁和持久化只是工具。真正稳定的 Redis 方案，一定会同时考虑缓存失效、数据库回源、故障降级和数据修复。
