2、Redis基础回顾：数据结构、持久化与集群模式
在构建多租户SaaS鉴权拦截链路时，Redis承担着会话存储、令牌缓存、速率限制与分布式锁等核心职责。本章系统回顾Redis的五大基础数据结构、两种持久化机制以及三种主流集群模式，为后续的会话管理实战打下坚实基础。
2.1 五大核心数据结构
Redis的数据结构决定了缓存策略的选择。下表从存储结构、典型命令与SaaS场景三个维度进行对比：
| 数据结构 | 内部编码 | 典型命令 | SaaS鉴权场景 |
|---|---|---|---|
| String | int / embstr / raw | SET / GET / INCR / EXPIRE | 单租户会话令牌、API Key、计数器 |
| Hash | ziplist / hashtable | HSET / HGET / HGETALL / HDEL | 租户配置、用户属性、会话元数据 |
| List | quicklist | LPUSH / RPUSH / LPOP / LRANGE | 操作日志队列、消息推送缓冲 |
| Set | intset / hashtable | SADD / SMEMBERS / SISMEMBER / SPOP | 租户白名单、角色标签、去重集合 |
| Sorted Set | ziplist / skiplist | ZADD / ZRANGE / ZREVRANGE / ZSCORE | 会话过期时间排序、租户活跃度排行 |
实战建议：多租户会话存储优先选用 Hash 结构，以租户ID+用户ID为key，字段存储令牌、过期时间、角色等属性，避免String结构导致的key膨胀问题。
2.2 Redis持久化：RDB vs AOF
持久化机制决定了缓存数据的恢复能力与性能开销。RDB基于快照，AOF基于操作日志，两者在SaaS生产环境中通常配合使用。
| 对比维度 | RDB（快照） | AOF（追加文件） |
|---|---|---|
| 数据恢复速度 | 快（直接加载二进制快照） | 慢（逐条重放命令） |
| 数据安全性 | 可能丢失最后一次快照后的数据 | 可配置每秒同步，最多丢失1秒数据 |
| 文件体积 | 紧凑，适合备份 | 较大，需定期重写（BGREWRITEAOF） |
| 对性能影响 | fork子进程，内存占用翻倍 | 写操作追加日志，磁盘IO较高 |
| SaaS推荐策略 | 每小时快照 + 每日备份 | 开启AOF + everysec同步 |
避坑提示：不要在生产环境同时关闭RDB和AOF。一旦Redis进程崩溃或服务器宕机，所有会话数据将永久丢失，导致全量租户强制重新登录。
2.3 Redis集群模式
单机Redis受限于内存容量与单点故障风险，SaaS多租户场景必须引入集群方案。三种主流模式对比如下：
| 集群模式 | 数据分片 | 高可用 | 节点数要求 | 适用场景 |
|---|---|---|---|---|
| 主从复制 | 不支持 | 手动故障转移 | 1主N从 | 读写分离、冷备 |
| 哨兵模式 | 不支持 | 自动故障转移 | 3哨兵 + 1主N从 | 中小规模高可用 |
| Cluster模式 | 16384个槽位 | 自动分片 + 自动转移 | 至少3主3从 | 大规模多租户会话 |
2.4 数据结构与持久化的协同策略
在SaaS鉴权拦截链路中，不同数据结构对持久化的依赖程度不同：
- 会话令牌（String/Hash）：必须开启AOF + everysec，避免令牌丢失导致租户强制下线。
- 速率限制计数器（String + INCR）：允许短暂丢失，RDB每小时快照即可，降低写放大。
- 操作日志队列（List）：建议AOF + 每日BGREWRITEAOF，保证日志不丢且文件可控。
- 租户白名单（Set）：RDB每日备份 + 主从复制，读多写少场景优先保证查询性能。
- 会话过期排序（Sorted Set）：AOF + 定期ZREMRANGEBYSCORE清理，避免过期数据堆积。