Redis 入门：从历史到核心特性，再到与 Memcached 的对比
好，咱们正式开始聊 Redis。说实话，每次我带新人或者做技术分享，Redis 总是绕不开的一环。它太常用了，几乎成了后端缓存的代名词。但很多人用归用，对它的来龙去脉、核心优势，以及它和 Memcached 到底差在哪，其实是一笔糊涂账。
今天这一讲，我就带你把这些事儿理清楚。咱们不搞那些虚头巴脑的，直接上干货。
Redis 发展史：一个意大利小伙的逆袭
Redis 的全称是 Remote Dictionary Server，远程字典服务。名字很直白，就是个跑在远程的 key-value 存储。
它的作者叫 Salvatore Sanfilippo，意大利人，圈内都叫他 antirez。这哥们儿最早是想做一个实时 Web 日志分析器，叫 LLOOGG。但做着做着发现，传统数据库根本扛不住这种高并发写入和实时统计的需求。于是他一拍大腿，自己撸了一个底层数据结构，用 C 语言写的，这就是 Redis 的雏形。
2009 年，Redis 正式开源。我记得那会儿我刚入行不久，还在用 Memcached 做缓存。第一次看到 Redis 的文档时，我心想：这玩意儿能支持 list、set 这些数据结构？还能做持久化？这不就是个数据库吗？
后来的故事大家都知道了。Redis 迅速蹿红，从 2.6 版本开始支持 Lua 脚本，2.8 引入主从复制，3.0 推出 Redis Cluster 实现分布式，5.0 引入 Stream 数据结构，再到 6.0 支持多线程 IO 和 ACL 权限控制。每一步都踩在了后端开发的痛点上。
我个人觉得，Redis 能火，核心原因就一个：它把「简单」和「强大」平衡得特别好。你用它做缓存，几行代码就能搞定；你想用它做分布式锁、消息队列、排行榜，它也能胜任。这种「瑞士军刀」般的定位，让它在后端架构里几乎无处不在。
Redis 核心特性：凭什么它能这么火？
咱们来拆解一下 Redis 的核心特性。说白了，就是它到底牛在哪。
1. 纯内存操作，速度极快
这是 Redis 的立身之本。数据全在内存里，读写速度能达到每秒十万甚至百万级别。我在项目中遇到过，用 Redis 做热点数据缓存，接口响应时间从 200ms 直接降到 5ms 以内。嗯，这个提升是立竿见影的。
2. 丰富的数据结构
这一点是 Redis 和 Memcached 最大的区别。Redis 不只是存字符串，它还支持：
- String：最基础的 key-value，缓存、计数器都用它
- List：双向链表，适合做消息队列、最新列表
- Set：无序集合，适合做去重、共同好友
- Sorted Set (ZSet)：有序集合，排行榜的绝配
- Hash：字典结构，适合存对象
- Bitmap、HyperLogLog、GEO、Stream：这些是高级玩法，后面会细讲
你想想看，一个缓存中间件能直接帮你做排序、去重、聚合，这得省多少业务代码？
3. 持久化机制
Redis 虽然是内存数据库，但它支持把数据持久化到磁盘。主要有两种方式：
- RDB (快照)：定期把内存数据 dump 到磁盘。适合做备份和灾难恢复。
- AOF (追加文件)：记录每次写操作命令。数据安全性更高，但文件体积大。
我曾经在线上遇到过 Redis 宕机，就是因为没开持久化，重启后缓存全丢了，导致数据库被打爆。那次教训之后，我建议所有生产环境至少开启 AOF 持久化，哪怕牺牲一点性能。
4. 高可用与分布式
Redis 提供了多种高可用方案：
- 主从复制：一主多从，读写分离
- Sentinel：哨兵模式，自动故障转移
- Cluster：集群模式，数据分片，支持水平扩展
这些机制保证了 Redis 在生产环境中的稳定性。说白了，你不用担心单点故障。
5. 单线程模型与多线程 IO
Redis 6.0 之前，核心处理逻辑是单线程的。很多人不理解：单线程怎么还能这么快？其实原因很简单：Redis 的瓶颈不在 CPU，而在内存和网络 IO。单线程避免了锁竞争和上下文切换的开销，反而更高效。
6.0 之后，Redis 引入了多线程 IO，用于处理网络读写。但核心命令执行仍然是单线程的。这个设计很巧妙，既提升了 IO 吞吐量，又保持了数据操作的原子性。
核心总结：Redis 的核心竞争力，就是「内存 + 丰富数据结构 + 持久化 + 高可用」的组合拳。它不是一个简单的缓存，而是一个轻量级的数据库。
Redis vs Memcached：到底选哪个？
这个问题，我几乎每次面试都会被问到。咱们直接上对比表：
| 对比维度 | Redis | Memcached |
|---|---|---|
| 数据结构 | 丰富（String、List、Set、ZSet、Hash 等） | 仅支持 String |
| 持久化 | 支持 RDB 和 AOF | 不支持 |
| 主从复制 | 支持 | 不支持 |
| 集群模式 | 支持 Redis Cluster | 客户端分片，无原生集群 |
| 内存管理 | 灵活，支持多种淘汰策略 | 固定内存块分配，有内存碎片问题 |
| 性能 | 极高，但复杂操作略慢 | 极高，纯 KV 操作更快 |
| 适用场景 | 缓存、分布式锁、排行榜、消息队列等 | 纯 KV 缓存，简单场景 |
从表里能看出来，Redis 几乎是 Memcached 的「全面升级版」。那是不是说 Memcached 就该被淘汰了？
也不尽然。我个人的经验是：
- 如果你的需求只是简单的 key-value 缓存，对持久化、数据结构没要求，而且你特别在意极致的内存效率，那 Memcached 依然是个不错的选择。它的内存管理确实比 Redis 更省。
- 但如果你需要复杂的数据操作、持久化、高可用，或者你希望一个中间件能解决多个问题，那 Redis 是毫无疑问的首选。
我的建议：新项目直接上 Redis。别纠结。Memcached 的维护成本并不比 Redis 低，但功能差了一大截。除非你是在维护老系统，否则没必要给自己找麻烦。
避坑指南：我踩过的那些 Redis 坑
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路。
坑一：把 Redis 当数据库用
我曾经在一个项目里，把用户的核心业务数据全存在 Redis 里，没做持久化。结果一次机房断电，数据全丢了。虽然 Redis 支持持久化，但它本质上是内存数据库，数据安全性远不如 MySQL 这类磁盘数据库。记住：Redis 是缓存，不是真正的数据库。重要数据一定要落盘到 MySQL 或其它关系型数据库。
坑二：大 key 问题
有一次线上 Redis 突然变慢，排查了半天，发现是一个 Hash 里存了上百万个字段。每次操作这个 key，Redis 都要遍历整个 Hash，导致其他请求也被阻塞。后来我把这个大 key 拆成了多个小 key，问题就解决了。记住：单个 key 的 value 不要太大，建议控制在 10KB 以内。
坑三：忽略连接数限制
Redis 默认最大连接数是 10000。我在压测时遇到过连接数打满，导致新请求无法建立连接。后来我调整了 maxclients 参数，并在客户端加了连接池，才搞定。记住：生产环境一定要配置连接池，并监控连接数。
好了，这一讲的内容就到这里。Redis 入门其实不难，但要把这些核心概念吃透，后面用起来才能得心应手。下一讲，咱们会深入 Redis 的数据结构，看看它们到底怎么用、怎么选。