redis的“空间换时间”是其核心设计逻辑：通过可控内存开销（如多建索引、选用高效编码、同机部署），将磁盘/网络访问降维为内存寻址，实现毫秒级到微秒级的性能跃升。
Redis 的“空间换时间”不是一句空话，而是贯穿整个架构设计的底层逻辑。它本质是用可控的内存开销，换取数量级的性能提升——把原本要走磁盘、网络、复杂计算的路径，压缩成一次内存寻址。
缓存层：拦截数据库请求，把毫秒变微秒
典型 Web 架构中，MySQL 查一条记录常需 5–50ms；而 Redis 读一个 key 只要 0.1–0.3ms。这不是优化，是降维打击。
- 在用户登录、商品详情、配置信息等高频读场景，把结果存为字符串或哈希，key 设计成业务标识（如 user:10086、item:20240828）
- 采用 Cache Aside 模式：应用先查 Redis，未命中再查 DB，并写回缓存；更新时先改 DB，再删缓存（避免双写不一致）
- 注意设置合理 TTL，防止脏数据长期滞留；对强一致性要求高的字段（如库存），可配合分布式锁或延迟双删
多索引建模：用额外 key 换免遍历查询
Redis 原生不支持按 value 或字段查，但你可以主动建“反向索引”。这正是空间换时间最灵活的体现。
- 比如用户表存于 hash users（key=user_id，value=JSON），想按用户名查？那就额外存一个 hash usernames（key=username，value=user_id）
- 订单按状态分片？建 set orders:paid、orders:shipped，把 order_id 加进去，SMEMBERS 直出列表
- 这类索引占用空间小、维护成本低，却彻底规避了 O(N) 扫描，代价只是几 KB 内存和一次额外写操作
数据结构选型：匹配场景，让操作天然高效
Redis 提供的不只是 KV，每种结构都针对一类访问模式做了时空权衡。
- 需要按分数排序排行榜？用 ZSET（底层跳表），插入/查询都是 O(log N)，比自己在应用层排序+缓存快得多
- 频繁增删首尾消息？选 LIST（底层 quicklist），而非反复拼接字符串
- 存大量小对象且内存敏感？启用 ziplist 编码（自动触发），用连续内存块替代指针链表，省空间也提缓存命中率
部署与资源分配：把内存真正用在刀刃上
空间换时间的前提，是让内存离计算足够近、足够快。
- QPS 万级以下、延迟敏感的服务（如风控、会话），可将 Redis 与应用同机部署，走 127.0.0.1，实测延迟压到 0.1ms 级别
- 预留充足内存并开启 LRU/LFU 淘汰策略，确保热点数据常驻；避免 maxmemory 设置过小导致频繁驱逐，反而增加 CPU 开销
- 对超大集合类数据（如百万级用户标签），考虑用 HyperLogLog 估数、Bitmap 存状态——用固定 12KB 内存代替千万级布尔字段
