Redis 常被简单理解成“内存缓存”，但它不只是一个能设置过期时间的 key-value 存储。真正用好 Redis，需要同时理解三件事：它为什么快、它有哪些数据结构、它适合放在哪些业务边界里。
这篇按工程视角整理 Redis 的基础概念，避免只背“单线程、高性能、五种数据类型”这类碎片。
Redis 为什么快
Redis 的核心数据主要放在内存里，读写不需要像传统数据库那样频繁等待磁盘随机 IO，这是它快的基础。
另外，Redis 的命令执行模型比较简单。很多命令在服务端串行处理，避免了复杂锁竞争。对业务来说，这意味着单个命令通常具有很低延迟，也更容易推导原子性边界。
但“快”不代表可以无节制使用。Redis 受内存容量限制，数据结构选错、key 设计混乱、value 过大、慢命令滥用，都会让它从加速器变成故障源。
常见数据类型怎么选
Redis 不是只有字符串。不同数据类型适合不同业务模型。
String 适合简单缓存、计数器、开关值、token 和序列化对象：
user:1001:name -> "zhao"
article:1553:view_count -> "1024"Hash 适合存储对象的多个字段，尤其是字段需要独立读写时：
user:1001 -> name, avatar, levelList 适合按插入顺序处理的队列、时间线片段或简单消息缓冲。
Set 适合去重集合、标签、关系判断和交并差运算。
Sorted Set 适合排行榜、延迟队列、按分值排序的任务列表和时间窗口统计。
选型时不要只问“能不能存”，还要问后续怎么查、怎么更新、怎么过期、数据量会不会膨胀。
Redis 和 Memcached 的差别
如果只做最简单的字符串缓存，Redis 和 Memcached 都能胜任。但 Redis 的优势在于数据结构更丰富，还支持持久化、主从复制、发布订阅、Lua 脚本等能力。
简单理解：
- Memcached 更像纯缓存。
- Redis 更像内存数据结构服务器。
也正因为 Redis 能做的事更多，工程上更需要克制。不要把所有临时状态、队列、排行榜、锁、限流、会话和配置都随手塞进去，而要按业务重要性、容量和恢复方式分层设计。
持久化不是万能保险
Redis 支持 RDB 和 AOF 等持久化方式，但这不等于它可以无脑当主数据库。
RDB 更像定期快照，恢复快，但可能丢失最近一段时间的数据。AOF 记录写命令，数据安全性更高一些，但文件增长、重写和恢复成本也要考虑。
对于缓存场景，允许丢失、可从数据库重建，持久化压力可以低一些。对于队列、计数、会话这类场景，就要明确故障时能不能丢、丢多少、如何补偿。
常见使用场景
Redis 最常见的落点有几类。
第一类是缓存。把热点数据放进 Redis，减少数据库压力。关键是设置合理过期时间，并处理缓存穿透、击穿和雪崩。
第二类是计数器。比如浏览量、点赞数、接口调用次数。Redis 的自增命令很方便，但要考虑最终是否回写数据库。
第三类是排行榜。Sorted Set 可以自然表达分数和排名，适合游戏积分、活跃榜、热度榜。
第四类是队列和延迟任务。List、Stream、Sorted Set 都能实现不同层次的队列，但如果业务已经需要严格投递、消费组、积压治理和可观测性，专业 MQ 往往更合适。
第五类是分布式协调，比如锁和限流。这里要非常谨慎，必须明确超时时间、重入、续期、失败释放和时钟问题。
实用结论
Redis 的价值不只是“快”，而是用内存数据结构把一些高频访问、轻量计算和短生命周期状态从主数据库里拆出来。
用 Redis 前先想清楚三件事：数据结构怎么选，数据丢了怎么恢复，容量和过期策略怎么控制。把边界想清楚，Redis 才是系统加速器；边界混乱，它就会变成另一个更难排查的状态库。
