1. 课程导入与平台全景

在开始写第一行代码之前，我们需要先建立一张“地图”。本课程要构建的不是一个简单的 Redis 缓存示例，而是一个面向真实业务的会话与实时状态平台：它要同时承载用户登录态、在线状态、设备心跳、消息未读计数、限流令牌、排行榜、分布式锁等高频读写数据，并在多实例、多机房、高并发条件下保持低延迟与一致性。Redis 之所以成为这类平台的核心，是因为它把“内存级读写速度”和“丰富的数据结构”结合在了一起，让会话与状态这类生命周期短、访问频繁、结构多样的数据有了天然归宿。

先看整体定位。传统做法把会话放在应用进程内存里，一旦扩容或重启就会丢失，多实例之间也无法共享；放进关系型数据库，又会因为每次请求都要读写磁盘而拖垮连接池。Redis 处在应用与持久化存储之间，扮演高速状态层的角色：应用把“当前这一刻必须快速读到、且允许按 TTL 自动过期”的数据交给 Redis，把“必须长期留存、可审计”的数据交给 MySQL 或对象存储。理解这条边界，是后续所有设计决策的起点。

这张全景图自上而下分为四层。最上面是接入层，负责把用户请求安全地送进来；第二层是应用服务层，按职责拆成会话、状态、计数、协调四类服务；第三层是 Redis 高速状态层，用不同数据结构承载不同形态的状态；最下面是持久化与审计层，负责把需要长期保留的数据异步落库。箭头方向表示数据流向：请求自上而下进入，状态读写集中在 Redis 层，异步落库自 Redis 向持久层流动。理解这个分层，就能明白为什么 Redis 不是“可选项”，而是整个平台的性能枢纽。

关键模块与数据形态的对应关系

平台里每一类业务状态，几乎都能在 Redis 中找到最匹配的数据结构。会话对象通常是一个包含用户 ID、角色、登录时间、设备指纹的 Hash，键名形如 sess:{sessionId}，并设置 1800 秒 TTL；在线状态用 Set 维护 online:users，配合每个用户的心跳键 hb:{userId} 设置 30 秒过期，过期即视为离线；未读计数用 Hash 的 HINCRBY 原子递增；排行榜用 ZSet 的 ZINCRBY 累加分数；分布式锁用 SET lock:order:{id} token NX PX 10000 实现。这些不是随意选择，而是由“读写频率、是否需要排序、是否需要原子计数、是否允许过期”四个维度共同决定的。

举个具体的会话写入例子。用户登录成功后，应用执行：

HSET sess:a1b2c3 uid 10086 role "vip" loginAt 1735689600 device "ios-15"
EXPIRE sess:a1b2c3 1800
SET hb:10086 1 EX 30

这三条命令分别完成：写入会话主体、设置 30 分钟过期、刷新心跳。后续每次请求携带 a1b2c3，应用先 EXISTS sess:a1b2c3 判断会话是否有效，再 HGETALL 取出用户信息。如果返回空，说明会话已过期，需要重新登录。这里的关键判断依据是：EXISTS 返回 1 表示会话有效，返回 0 表示已过期或不存在。心跳键则用于在线状态判断，EXISTS hb:10086 为 1 即在线。

学习路径与工程关注点

本课程后续会沿着“数据建模 → 读写路径 → 过期与淘汰 → 高可用与分片 → 一致性与并发 → 监控与排障”这条主线展开。每一章都会落到具体命令、参数和判断依据上，而不是停留在概念介绍。比如讲到过期策略时，会区分惰性删除与定期删除的触发条件；讲到分片时会讨论 Redis Cluster 的 16384 个槽位如何映射；讲到并发时会分析 WATCH 与 Lua 脚本在原子性上的差异。