Redis（远程字典服务）数据结构与命令语义

知识图谱编号：1.4.1。本册只回答“数据如何表示、命令如何改变状态、组合命令具有什么原子性”三个问题；事件循环、复制高可用、缓存一致性和分布式锁在后续分册展开。

1. 学习目标与版本口径

读完本册，应能从一个业务键追到 redisObject（Redis 对象）、底层编码、复杂度、内存成本和失败边界；能解释命令“单条原子”并不等于跨系统事务；能为库存、轨迹、延迟任务和报警去重选择合适结构，而不是只会背命令。

2. 对象、键空间与过期字典

2.1 redisObject（Redis 对象）与逻辑类型、物理编码

一个键首先位于数据库的键空间字典，值指针再指向 redisObject（Redis 对象）。对象头记录 type（类型）、encoding（编码）、refcount（引用计数）以及 LRU（最近最少使用）或 LFU（最不常用）相关信息，ptr（数据指针）才指向 SDS（简单动态字符串）、dict（哈希字典）或 listpack（紧凑列表）等真实结构。type（类型）决定命令语义，encoding（编码）决定内存布局；同一个 ZSet（有序集合）在元素少且短时可采用 listpack（紧凑列表），增长后可升级为 dict（哈希字典）加 skiplist（跳表）。因此排查内存不能只看逻辑类型，还要同时看元素数量、元素长度与编码。

flowchart LR
    K["键空间 dict"] --> O["redisObject 对象头"]
    O --> T["type: 逻辑类型"]
    O --> E["encoding: 物理编码"]
    O --> M["refcount 与 LRU/LFU 信息"]
    O --> P["ptr 数据指针"]
    P --> S["SDS"]
    P --> D["dict"]
    P --> L["listpack / quicklist / skiplist"]

数据演绎 1：编码升级为什么会出现瞬时成本。 假设 order:items:9001 是含 120 个短字段的 Hash（哈希），紧凑编码占用约 9 KB（千字节）。第 121 个字段值突然变成 2000 字节，超过当前阈值后，服务端需要创建 dict（哈希字典）、逐项解码并插入 121 个字段，再释放旧结构。升级后可能占 20 KB（千字节）以上；单次命令仍保持原子可见，但执行时间和内存峰值会上升。阈值只是示例，生产必须读取当前版本配置并用 OBJECT ENCODING、MEMORY USAGE 验证。

热门面试题

1. 问题：逻辑类型和底层编码有什么区别？

   • 考点：对象模型、编码升级。
   • 回答思路：先区分命令语义与内存实现，再说明编码随数据形态变化。
   • 详细答案：逻辑类型是对客户端承诺的行为，例如 Hash（哈希）支持字段读写；底层编码是服务端实现该行为的结构，例如 listpack（紧凑列表）或 dict（哈希字典）。编码切换不改变命令接口，却会改变内存、常数项和单次升级成本。面试中应把配置阈值、版本差异与验证命令一起说明。
   • 进阶追问：编码升级会回退吗？
   • 进阶回答：通常不能假设自动回退。删除元素后是否收缩或重编码取决于具体结构与版本，实现一般更重视避免频繁震荡；需要通过实测编码确认，不能把“元素变少”直接等同于恢复紧凑编码。

2. 问题：refcount（引用计数）是否等同于垃圾回收？

   • 考点：对象生命周期。
   • 回答思路：说明计数用途，再与追踪式垃圾回收区分。
   • 详细答案：refcount（引用计数）用于记录对象被共享或持有的数量，计数归零时可释放对象；它不是 JVM（Java 虚拟机）那种从根集合做可达性分析的垃圾回收器。Redis（远程字典服务）自身管理明确的对象所有权，结构删除、键删除和惰性释放会沿确定路径回收。
   • 进阶追问：大对象删除为什么仍可能慢？
   • 进阶回答：计数归零只是开始，释放大量子元素会消耗 CPU（中央处理器）时间；可以在适用场景用异步删除，把释放工作交给后台线程，但必须继续观察内存回收滞后和后台队列。

3. 问题：为什么不能只根据 TYPE 判断内存风险？

   • 考点：逻辑类型、物理编码、元素形态。
   • 回答思路：把类型、数量、长度、编码和访问模式串起来。
   • 详细答案：同为 Hash（哈希），几十个短字段可能连续存储，百万字段则是大型字典；同为 String（字符串），几十字节令牌与数百 MB（兆字节）序列化对象的阻塞和复制成本完全不同。需要组合 TYPE、OBJECT ENCODING、MEMORY USAGE、基数和慢日志判断。
   • 进阶追问：怎样建立大键治理基线？
   • 进阶回答：按业务前缀抽样记录类型、编码、字节数、元素数、最大成员长度和命令耗时，定义分级阈值；拆分后以同等流量复验延迟、内存和网络，而不是只确认键变小。

2.2 键空间字典、过期字典与键生命周期

每个逻辑数据库维护主键空间字典，键映射到值对象；设置过期时间时，过期字典保存同一键引用和绝对过期时间。读取路径会做惰性过期检查，周期任务做主动抽样清理。这里要抓住“过期是时间语义，删除是物理动作”：某键到达过期时刻后，从业务语义看已经失效，但内存可能稍后才回收。写入 SET 后原有 TTL（存活时间）可能被清除，是否保留取决于命令选项；库存幂等键和支付回调键如果更新时误丢 TTL（存活时间），会从短期状态变成永久键。

stateDiagram-v2
    [*] --> Alive: 写入键
    Alive --> Expiring: 设置过期时间
    Expiring --> Alive: 覆盖并清除 TTL
    Expiring --> LogicallyExpired: 到达过期时刻
    LogicallyExpired --> Deleted: 访问时惰性删除
    LogicallyExpired --> Deleted: 周期任务主动删除
    Alive --> Deleted: DEL / UNLINK
    Deleted --> [*]

数据演绎 2：过期时间更新。 alarm:dedup:device-17:code-4 在 10:00:00 写入并设置 300 秒过期；10:04:50 再次报警，如果只执行普通覆盖写而未显式保留或重设 TTL（存活时间），原过期语义可能消失。正确策略要先明确“窗口固定”还是“每次续窗”：固定窗口仍在 10:05:00 失效，滑动窗口则重设到 10:09:50。二者都可实现去重，但报警恢复速度不同，必须由业务语义决定。

热门面试题

1. 问题：过期键为什么不会在到点瞬间全部释放？

   • 考点：惰性删除、主动删除、性能权衡。
   • 回答思路：说明精确计时器成本与抽样清理设计。
   • 详细答案：为每个键维护高精度计时任务会带来额外内存、调度和突发删除成本，因此服务端把惰性检查与周期抽样结合。到期先代表业务失效，物理释放允许稍后发生；这种设计把清理工作摊开，但极端过期风暴仍可能增加 CPU（中央处理器）和延迟。
   • 进阶追问：大量键同一秒过期怎么处理？
   • 进阶回答：业务侧对 TTL（存活时间）增加抖动，避免同刻雪崩；服务端观察过期扫描、命中率和延迟。若这些键会触发回源，还要增加请求合并、限流和降级。

2. 问题：为什么键覆盖后要检查 TTL（存活时间）？

   • 考点：命令副作用、状态机。
   • 回答思路：从“值更新”和“期限更新”是两个维度解释。
   • 详细答案：覆盖值不天然等于续期或保留期限。不同命令和选项对原 TTL（存活时间）的处理不同，幂等键、验证码、锁和延迟状态尤其敏感。工程上应把期限当作状态的一部分，在集成测试中同时断言值和剩余时间。
   • 进阶追问：如何避免永久幂等键无限增长？
   • 进阶回答：根据上游最大重试周期、对账周期和法规保留要求设计过期窗口，并在权威数据库保留唯一约束；监控无 TTL（存活时间）键比例和业务前缀基数。

3. 问题：DEL 与 UNLINK 的选择依据是什么？

   • 考点：同步摘除、异步释放。
   • 回答思路：区分键空间可见性与内存释放执行位置。
   • 详细答案：二者都会让键从逻辑空间消失，但大对象的子结构释放可能很重。同步删除把成本放在命令路径，异步删除把实际释放交给后台，降低主执行路径停顿；后者不是免费，峰值内存会延迟下降，后台释放能力也需要监控。
   • 进阶追问：小键是否都应使用异步删除？
   • 进阶回答：不应机械统一。小键同步释放路径简单、可预测；异步机制有队列和调度成本。应按对象大小、删除频率和延迟目标选择，并用真实负载验证。

3. 基础编码与内存布局

3.1 SDS（简单动态字符串）与 String（字符串）

SDS（简单动态字符串）在字符数组外保存已用长度和可用空间，因此获取长度不必扫描终止符，二进制数据也不会被中间的零字节截断。扩容策略通过预留空间减少连续追加的重新分配次数，缩短不会自动频繁归还容量，从而用一部分空间换取摊销性能。String（字符串）值不只保存文本，也承载整数计数、Bitmap（位图）、序列化结果和锁令牌；命令能否安全组合取决于值语义，而不是“底层都是字符串”这一句话。

flowchart TB
    H["SDS 头: len / alloc / flags"] --> B["连续字节数组 buf"]
    B --> U["已使用区域"]
    B --> F["预留空间"]
    A["APPEND 追加"] --> C{"剩余空间足够?"}
    C -->|是| W["原位写入并更新 len"]
    C -->|否| R["重新分配并复制"]
    R --> W

数据演绎 3：扩容摊销。 一个缓冲区已用 60 字节、分配 64 字节，追加 3 字节可原位完成；再追加 20 字节时容量不足，需要申请更大连续空间并复制原 63 字节。若每次只按新增字节精确分配，连续 1000 次追加可能触发近 1000 次分配和复制；采用预留空间后，重分配次数接近按容量级数增长。实际扩容规则随版本和长度区间变化，面试重点是“用可控额外空间降低重复复制”，不是背固定倍数。

热门面试题

1. 问题：SDS（简单动态字符串）为什么比传统字符串适合内存数据库？

   • 考点：长度、二进制安全、摊销扩容。
   • 回答思路：从读长度、写扩容、安全边界三条线回答。
   • 详细答案：SDS（简单动态字符串）保存长度和容量，长度读取无需扫描；按长度处理数据，允许中间零字节；追加前检查并扩容，降低越界风险；预留空间减少连续追加的分配和复制。代价是对象头和空闲容量，所以并非任何短值都零开销。
   • 进阶追问：缩短字符串后内存一定立即下降吗？
   • 进阶回答：不一定。逻辑长度可立即变化，但分配容量可能保留以避免扩缩震荡；还受内存分配器和碎片影响，需用内存命令与进程指标共同验证。

2. 问题：库存计数为什么适合 String（字符串）的整数命令？

   • 考点：单命令原子性、数值语义。
   • 回答思路：说明递增递减的原子边界及不足。
   • 详细答案：单个计数器的递增递减由一条命令完成，在服务端命令执行边界内不会被另一条命令插入，适合简单库存或配额计数。但“检查库存大于零再扣减”是多步条件逻辑，必须用 Lua（脚本语言）或其他原子组合，并由数据库唯一约束或条件更新兜底。
   • 进阶追问：为什么 Redis（远程字典服务）扣减成功仍可能超卖？
   • 进阶回答：缓存与权威数据库可能不同步，锁或键可能过期，消息可能重复，故障切换还可能丢失未复制写入。库存正确性必须由数据库条件更新、版本号或唯一流水保障，缓存负责削峰和快速拒绝。

3. 问题：String（字符串）存整对象有什么风险？

   • 考点：序列化放大、局部更新、大键。
   • 回答思路：比较整值读写与字段级访问。
   • 详细答案：整对象序列化实现简单，但修改一个字段也要反序列化和重写全部字节，网络与复制成本随对象增长；大值还会占用单线程命令时间。字段更新频繁时可考虑 Hash（哈希），但也要控制字段数量和编码升级，不能把一个超大对象换成一个超大哈希。
   • 进阶追问：如何做选择验证？
   • 进阶回答：采集值大小分布、读写比例、字段更新比例、网络字节和命令耗时，在相同业务负载下比较两种建模；同时评估过期粒度和跨字段一致性。

3.2 dict（哈希字典）与渐进式 rehash（重新哈希）

dict（哈希字典）以哈希表提供平均常数时间查找。发生扩缩容时，服务端同时保留旧表和新表，用 rehashidx（重新哈希索引）记录迁移进度；后续增删改查以及周期维护每次搬迁少量桶，直到旧表清空。迁移期间查询先查旧表再查新表，新增通常进入新表，删除要处理两个表，因此“渐进”降低单次停顿，却增加临时双表内存和路径复杂度。哈希函数、防碰撞策略、负载因子和扩容时机共同决定平均性能，面试不能把平均 O(1)（常数复杂度）说成任何输入下的绝对 O(1)（常数复杂度）。

flowchart LR
    A["ht[0]: 8 个桶"] --> B["触发扩容"]
    B --> C["分配 ht[1]: 16 个桶"]
    C --> D["rehashidx = 0"]
    D --> E["每次操作迁移少量桶"]
    E --> F{"ht[0] 是否为空?"}
    F -->|否| E
    F -->|是| G["释放旧表并交换 ht[1]"]

数据演绎 4：双表迁移。 旧表有 8 个桶，键 sku:1、sku:9 落在旧桶 1。扩容到 16 个桶后，设置 rehashidx=0。一次 HSET 触发迁移桶 0，下一次 GET 迁移桶 1：重新计算后 sku:1 进入新桶 1，sku:9 进入新桶 9。此时查 sku:9 先确认旧表对应位置，再查新表；新键直接写新表。等 8 个旧桶全部处理，旧表释放。若在迁移期做全量扫描，游标语义允许少量重复，调用方必须去重且不能把一次扫描当强一致快照。

热门面试题

1. 问题：为什么不一次性完成 rehash（重新哈希）？

   • 考点：尾延迟、工作摊销。
   • 回答思路：比较一次搬迁和渐进搬迁的延迟形态。
   • 详细答案：一次搬迁百万条目会长时间占用命令执行线程，所有后续请求排队。渐进式 rehash（重新哈希）把工作分散到后续请求和周期维护中，显著降低单次停顿；代价是迁移期同时持有两张表、读写逻辑更复杂且持续消耗少量 CPU（中央处理器）。
   • 进阶追问：渐进式迁移是否完全没有抖动？
   • 进阶回答：不是。分配新表、搬迁大桶、内存分配器和系统负载仍会引入抖动。需要结合延迟监控、键分布和内存峰值验证，不能只凭算法名称断言平滑。

2. 问题：哈希表查询为什么说平均 O(1)（常数复杂度）？

   • 考点：碰撞、负载因子、最坏情况。
   • 回答思路：解释均匀散列假设和冲突链。
   • 详细答案：在哈希分布均匀且负载受控时，键通常只需定位桶并比较少量条目，所以平均接近常数；碰撞集中时需要遍历更多条目，最坏路径会变长。实现通过扩容和哈希策略控制概率，但复杂度结论依赖输入分布。
   • 进阶追问：业务键设计会影响分布吗？
   • 进阶回答：可靠哈希会削弱普通前缀规律，但攻击性输入、极端长键和海量小键仍会造成 CPU（中央处理器）或内存问题。键名应控制长度并避免把不可信输入原样当键。

3. 问题：迁移期间 SCAN 为什么可能重复？

   • 考点：弱一致遍历、双表迁移。
   • 回答思路：从游标遍历与桶重分布解释。
   • 详细答案：SCAN 为避免长时间阻塞采用增量游标，不提供事务快照；在扩缩容和并发修改期间，元素可能跨桶迁移，调用方可能再次遇到同一元素，也可能看不到遍历期间短暂存在的元素。它保证的是可迭代能力，不是强一致清单。
   • 进阶追问：清理任务如何安全使用 SCAN？
   • 进阶回答：让删除和重复处理幂等，限制每批数量，记录游标和速率；关键资产清单以权威数据库为准，扫描只用于辅助治理或可重跑任务。

3.3 intset（整数集合）、listpack（紧凑列表）与 quicklist（快速列表）

intset（整数集合）用有序连续整数数组保存小型纯整数集合，按值宽度选择元素编码；插入更大范围整数时可能整体升级并搬移，升级后通常不降级。listpack（紧凑列表）把多个短元素连续放在一段内存中，减少指针和分配器元数据，提高缓存局部性，但中部插入删除可能移动后续字节。quicklist（快速列表）把多个紧凑节点串成双向链表，在“两端操作方便”和“节点内部连续”之间折中；节点过大则修改成本高，节点过小则指针开销增加。三者共同体现：数据量小时，常数项和局部性往往比理论复杂度更重要。

flowchart TB
    S["Set 仅含少量整数"] --> I["intset 连续有序数组"]
    I --> X{"加入非整数或超过条件?"}
    X -->|是| D["升级为 dict"]
    H["小 Hash / ZSet"] --> L["listpack 连续记录"]
    L --> Y{"元素数量或长度越界?"}
    Y -->|是| G["升级为常规编码"]
    Q["List"] --> QL["quicklist 链接多个紧凑节点"]

数据演绎 5：结构升级与局部性。 一个 Set（集合接口）保存 {1, 2, 300}，若按 16 位整数连续存储只需少量数据字节；加入 70000 后元素宽度需要升级，4 个元素都要按更宽编码重写。再加入 "A-1" 后不再是纯整数，需转换为 dict（哈希字典）。另一个包含 80 个短字段的 Hash（哈希）连续扫描时，listpack（紧凑列表）能减少随机指针跳转；但若把一个 100 KB（千字节）轨迹描述塞入其中，编码升级和复制成本会突然增大。

热门面试题

1. 问题：为什么小集合使用连续结构可能更快？

   • 考点：缓存局部性、指针开销。
   • 回答思路：不要只比较大 O（复杂度上界），要比较常数项。
   • 详细答案：连续结构让多个元素落在相邻内存，CPU（中央处理器）缓存一次可带入更多数据，且不需要为每个节点保存指针和单独分配。即使某些插入是 O(N)（线性复杂度），在 N（元素数量）很小时，实际成本仍可能低于多次随机访问和分配。
   • 进阶追问：何时连续结构反而变慢？
   • 进阶回答：元素变大、数量增长、频繁中部修改时，需要移动大量字节；达到阈值后升级为更适合动态增长的结构，避免线性搬移放大尾延迟。

2. 问题：intset（整数集合）为什么升级后通常不降级？

   • 考点：震荡控制、实现复杂度。
   • 回答思路：解释升级成本和反复转换风险。
   • 详细答案：降级需要扫描、判断范围并重新编码全部元素，会占用命令执行时间；若数据在边界附近来回变化，反复升降会造成抖动。保留较宽编码用少量空间换取稳定性，符合避免热路径复杂化的设计取舍。
   • 进阶追问：删除最大整数后怎样回收空间？
   • 进阶回答：不能假设自动降级。真正需要压缩时应评估重建键或离线迁移，但要考虑双份内存、并发写入和原子切换，通常不为微小空间收益冒险。

3. 问题：quicklist（快速列表）的设计折中了什么？

   • 考点：链表操作、连续节点、配置权衡。
   • 回答思路：从纯链表和单块连续数组的两个极端切入。
   • 详细答案：纯链表每个元素指针开销高、局部性差；单块连续数组中部修改和超大扩容成本高。quicklist（快速列表）用链表连接多个紧凑节点，两端操作只影响少数节点，节点内部保持连续。节点大小和压缩参数决定内存、CPU（中央处理器）与访问延迟。
   • 进阶追问：轨迹列表能无限追加吗？
   • 进阶回答：不能。应按运单设置最大保留条数或时间窗口，历史轨迹落到数据库或对象存储；否则单键会变大，网络、复制、删除和恢复都会被放大。

3.4 skiplist（跳表）与 radix tree（基数树）

skiplist（跳表）通过多层前向指针建立概率索引，查找、插入和删除平均为 O(log N)（对数复杂度），底层有序链保持范围遍历顺序。ZSet（有序集合）的常规编码同时使用 dict（哈希字典）按成员快速定位分数，用 skiplist（跳表）按分数和成员排序，换取点查与范围查询兼顾。radix tree（基数树）按公共前缀压缩路径，适合保存有序标识和范围定位；Stream（流）使用类似结构组织条目区段，并配合消费者组元数据，不应简单等同于“一个列表”。

flowchart LR
    H3["L3: head"] --> N30["30"]
    H2["L2: head"] --> N20["20"] --> N40["40"]
    H1["L1: head"] --> N10["10"] --> N20b["20"] --> N30b["30"] --> N40b["40"]
    Q["查找 30"] --> J["高层跳跃后下沉"]

flowchart TB
    R["radix root"] --> A["171000-"]
    A --> B["0001"]
    A --> C["0002"]
    A --> D["1000-"]
    D --> E["0001"]
    P["公共前缀只保存一次"] -.-> A

数据演绎 6：ZSet（有序集合）同分排序。 延迟任务成员为 task:1002、task:1001、task:1003，分数都为时间戳 1710000000000。按分数相同时再依据成员字节序形成稳定总序，所以结果可能是 task:1001、task:1002、task:1003。若业务要求同毫秒严格按创建顺序，仅靠相同分数不足，应把序列信息编码进分数或成员，并评估浮点精度；取出任务后还需用状态机与幂等键防止多消费者重复执行。

热门面试题

1. 问题：ZSet（有序集合）为什么同时需要字典和跳表？

   • 考点：多索引、空间换时间。
   • 回答思路：分别对应成员点查和分数范围查询。
   • 详细答案：dict（哈希字典）让按成员查询、更新分数接近平均常数时间；skiplist（跳表）维护按分数和成员的全序，支持排名和范围遍历。维护两份索引增加指针和更新成本，但避免任何一种主要查询退化为全量扫描。
   • 进阶追问：更新分数发生什么？
   • 进阶回答：先通过字典定位成员，若顺序位置改变，需要从跳表旧位置删除并按新分数插入，同时保持两套索引一致；整个命令对其他命令原子可见。

2. 问题：为什么不用平衡树替代 skiplist（跳表）？

   • 考点：实现复杂度、范围遍历、概率结构。
   • 回答思路：承认两者都可达对数复杂度，再讲工程取舍。
   • 详细答案：平衡树可提供严格的对数上界，skiplist（跳表）以随机层高获得期望对数性能，插入删除只调整局部指针，实现和范围遍历直观。选择并不表示树不可行，而是复杂度、可维护性与实际性能的综合结果。
   • 进阶追问：随机层高会导致结果不稳定吗？
   • 进阶回答：层高影响内部搜索路径和内存，不改变由分数与成员定义的外部排序结果；极端层高概率很低，但复杂度表述应使用平均或期望，而非绝对保证。

3. 问题：radix tree（基数树）为什么适合 Stream（流）标识？

   • 考点：前缀压缩、有序范围。
   • 回答思路：从时间序列标识共享前缀和区间读取解释。
   • 详细答案：相邻流标识通常具有共同的高位时间部分，radix tree（基数树）压缩公共前缀，减少重复存储，并按有序字节路径支持范围定位。实际 Stream（流）还会把多条记录组织成紧凑区段，消费者组状态另有元数据，不能只看树结构。
   • 进阶追问：它能保证消息恰好一次吗？
   • 进阶回答：不能。数据结构只支持存储与定位；消费者确认、故障恢复、重复投递和业务副作用仍需待确认列表、认领机制及幂等处理共同解决。

4. 逻辑数据类型与业务建模

4.1 String（字符串）、Hash（哈希）、List（列表接口）、Set（集合接口）与 ZSet（有序集合）

五类核心类型代表五种访问意图：String（字符串）强调单值、计数和位操作；Hash（哈希）强调对象字段；List（列表接口）强调两端有序序列；Set（集合接口）强调唯一性与集合运算；ZSet（有序集合）强调“唯一成员 + 可更新分数 + 有序范围”。选型应从主查询路径、原子边界、单键上限和淘汰粒度出发。运单轨迹按事件顺序追加可用 List（列表接口）或 Stream（流），需要确认和重试时更偏向 Stream（流）；延迟任务按执行时间排序适合 ZSet（有序集合），但“取出并删除”必须原子组合并配套处理中状态。

flowchart TB
    Q{"主要访问意图"}
    Q -->|单值/计数| S["String"]
    Q -->|字段读写| H["Hash"]
    Q -->|两端队列| L["List"]
    Q -->|唯一/交并差| E["Set"]
    Q -->|分数排序/范围| Z["ZSet"]
    S --> G["库存计数、位状态"]
    H --> O["订单摘要、设备属性"]
    L --> T["简单轨迹缓冲"]
    E --> U["报警去重集合"]
    Z --> D["延迟任务、优先级"]

数据演绎 7：命令复杂度如何影响业务。 一个仓库用 stock:available:sku-7 保存可用量 100，单次原子扣 1 成本稳定；若把 50 万 SKU（库存单位）全部放进一个 Hash（哈希），字段点查仍快，但迁移、删除、备份和故障恢复形成大键风险。轨迹列表保留最近 100 条时，两端追加与裁剪可控；若从不裁剪增长到 200 万条，网络读取和释放会显著放大。结构正确只是第一步，必须同时建立单键容量边界。

热门面试题

1. 问题：Hash（哈希）和多个 String（字符串）键如何选择？

   • 考点：字段操作、过期粒度、集群路由、内存开销。
   • 回答思路：先比较访问与过期边界，再比较键头开销和故障域。
   • 详细答案：Hash（哈希）把相关字段聚合，减少键名与对象头重复并支持字段读写；多个 String（字符串）键可独立过期、独立迁移和限流。若字段必须一起失效且规模受控，Hash（哈希）更自然；若字段生命周期不同或单对象可能无限增长，应拆分。最终用真实内存和请求模式验证。
   • 进阶追问：Hash（哈希）字段能独立设置 TTL（存活时间）吗？
   • 进阶回答：必须按具体版本能力核对，传统生产基线通常以整个键过期为主，不能默认所有版本都支持字段级过期。跨版本系统应采用最低共同能力或显式兼容方案。

2. 问题：List（列表接口）能否替代专业 MQ（消息队列）？

   • 考点：交付语义、确认、重试、观察能力。
   • 回答思路：承认简单队列可行，再讲可靠性边界。
   • 详细答案：List（列表接口）适合简单入队出队，配合阻塞弹出可低成本消费；但确认、消费者组、待处理追踪、重投、保留和治理都需自行设计。关键订单履约若要求可审计交付，更适合 Stream（流）或专业 MQ（消息队列），并在数据库保存业务状态。
   • 进阶追问：弹出后消费者崩溃怎么办？
   • 进阶回答：直接弹出的元素已离开源列表，可能丢失。可原子移动到处理中列表并在成功后删除，失败由补偿任务恢复，但这实际上是在手工构建确认协议。

3. 问题：ZSet（有序集合）做延迟队列的核心风险是什么？

   • 考点：原子领取、重复执行、时间与容量。
   • 回答思路：从到期扫描、领取、执行、确认四阶段回答。
   • 详细答案：按时间分数查询到期成员本身简单，风险在多个消费者同时读取后重复处理、取出后崩溃导致任务丢失、客户端时钟和服务端时钟差异以及大范围扫描阻塞。应使用 Lua（脚本语言）原子领取，转入处理中状态，业务执行幂等，超时任务可重新投递。
   • 进阶追问：为什么不能只执行查询后删除？
   • 进阶回答：查询与删除是两个命令，中间可被其他消费者插入，双方都会拿到同一任务；即使事务打包，若业务执行与删除顺序设计不当，崩溃窗口仍然存在。

4.2 Bitmap（位图）、HyperLogLog（基数统计）与 Geo（地理位置）

Bitmap（位图）不是独立对象类型，而是在 String（字符串）字节上按位读写，适合稠密编号的布尔状态。若用户编号跨度巨大且极稀疏，最高位决定字符串长度，空间可能浪费。HyperLogLog（基数统计）使用概率寄存器估算去重基数，以固定量级内存换取可接受误差，不能返回具体成员，也不适合作为计费或资金精确值。Geo（地理位置）把经纬度编码并借助有序结构做邻近查询，适合候选粗筛；球面模型、坐标精度和业务路网距离仍需上层处理。

flowchart LR
    B["Bitmap: 一位代表一天是否签到"] --> C["精确计数与位运算"]
    H["HyperLogLog: 寄存器摘要"] --> E["近似 UV 基数"]
    G["Geo: 坐标编码与有序索引"] --> N["附近候选点"]
    C --> P["空间随最大位偏移增长"]
    E --> R["固定量级内存但存在误差"]
    N --> D["不等于真实道路距离"]

数据演绎 8：空间与误差。 100 万个连续设备编号只记录“今天是否报警”，Bitmap（位图）理论数据位约 125 KB（千字节），明显小于存 100 万个字符串成员；但若只记录编号 1 和 10 亿，最高偏移会迫使字符串扩到约 125 MB（兆字节），此时 Set（集合接口）可能更合适。每日 UV（独立访客数）约 500 万时，HyperLogLog（基数统计）用固定量级空间给出近似值，适合容量趋势；若结算广告费必须精确到人，则应使用可审计明细或离线精确去重。

热门面试题

1. 问题：Bitmap（位图）为什么适合签到？

   • 考点：稠密编号、位运算、空间模型。
   • 回答思路：以一位表示一个布尔状态，再说明稀疏边界。
   • 详细答案：一个用户一个月可用约 31 位表示每天是否签到，设置、读取和统计都直接；多个时间窗口还能做位运算。它适合偏移连续且上界可控的状态，不适合随机超大编号，因为字符串长度由最高偏移决定。
   • 进阶追问：并发设置不同位会丢数据吗？
   • 进阶回答：服务端单条位命令按命令边界串行执行，不会出现客户端读改写整字节导致的覆盖；但跨多个键或“检查后设置”仍需原子组合。

2. 问题：HyperLogLog（基数统计）为什么能省内存？

   • 考点：概率结构、误差边界。
   • 回答思路：讲哈希结果的前导零统计与寄存器聚合思想，不必死背公式。
   • 详细答案：它不保存所有成员，而把哈希结果分组，只保留能反映罕见前导零长度的摘要，再通过统计估算总体基数。固定数量寄存器让空间基本不随成员线性增长，代价是结果存在概率误差且无法反查成员。
   • 进阶追问：能否用于库存去重扣减？
   • 进阶回答：不能。库存要求精确且可追溯，概率误差会直接造成资产错误；HyperLogLog（基数统计）适合趋势和分析指标，不承担业务唯一约束。

3. 问题：Geo（地理位置）查询出的最近仓一定是配送最优仓吗？

   • 考点：索引候选与业务决策分层。
   • 回答思路：区分直线邻近与路网、库存、时效约束。
   • 详细答案：Geo（地理位置）适合快速筛出距离附近的候选仓，但配送最优还受可售库存、跨境清关、道路距离、承运商服务区和截单时间影响。正确架构是先做空间粗筛，再由履约规则或路线服务精排。
   • 进阶追问：坐标更新如何处理旧结果？
   • 进阶回答：更新索引后仍需考虑应用缓存和并发查询窗口；可携带仓库配置版本，关键下单环节再次校验可履约性，而非把附近查询当最终承诺。

4.3 Stream（流）、消费者组与待确认列表

Stream（流）是追加式有序日志：条目带有递增标识和字段值，消费者组维护每个组的最后投递位置，并为已投递未确认消息维护 PEL（待确认列表）。新消息读取、历史待确认读取、确认和认领是不同动作。XACK 只移除组内待确认状态，不会删除流条目；修剪控制日志保留，不等于消费确认。它提供构建至少一次交付的材料，但业务副作用仍需幂等，生产者写业务库与写流之间也存在跨系统一致性窗口。

sequenceDiagram
    participant P as 生产者
    participant S as Stream
    participant G as 消费者组
    participant C1 as 消费者一
    participant C2 as 消费者二
    P->>S: XADD 追加 1000-0
    C1->>G: XREADGROUP 读取新消息
    G-->>C1: 投递并加入 PEL
    Note over C1: 处理时崩溃，未确认
    C2->>G: 查看超时待确认
    G-->>C2: 认领 1000-0
    C2->>G: XACK 确认

数据演绎 9：PEL（待确认列表）状态变化。 轨迹事件 1710000000000-0 投递给消费者 A，组的 PEL（待确认列表）新增 {消息, A, 投递次数1, 空闲0}。A 写数据库前崩溃，60 秒后消费者 B 认领，投递次数变 2；B 以“运单号 + 轨迹事件号”做数据库唯一键，插入成功后执行确认。若 A 实际已写库但确认前崩溃，B 的插入命中唯一约束并视为已处理，再确认即可，避免重复轨迹。

热门面试题

1. 问题：Stream（流）为什么仍需要业务幂等？

   • 考点：至少一次交付、确认窗口。
   • 回答思路：演绎“副作用成功、确认失败”的崩溃窗口。
   • 详细答案：消费者完成数据库写入后、发送确认前可能崩溃，消息仍在 PEL（待确认列表）并会被再次投递。基础设施无法知道外部副作用是否成功，因此必须以业务唯一键、状态机或幂等记录把重复投递变成重复读取而不是重复副作用。
   • 进阶追问：先确认再写数据库可以吗？
   • 进阶回答：确认后崩溃会永久丢失尚未执行的业务，通常风险更高。应先做可幂等的业务提交，再确认，并用补偿任务持续扫描超时待确认消息。

2. 问题：PEL（待确认列表）无限增长说明什么？

   • 考点：消费者健康、毒消息、容量治理。
   • 回答思路：从生产消费差、失败重试和确认遗漏分类。
   • 详细答案：可能是消费者吞吐不足、处理异常后未确认、毒消息反复失败、消费者标识漂移或认领机制缺失。应看待确认数量、空闲时间、投递次数和业务失败原因，设置重试上限与隔离区，而不是直接批量确认掩盖问题。
   • 进阶追问：如何处理长期毒消息？
   • 进阶回答：记录失败原因与原消息，达到阈值后移入人工或死信处理流程，保留关联标识；隔离成功后再确认原消息，修复后通过幂等入口重放。

3. 问题：Stream（流）和 List（列表接口）怎么选？

   • 考点：交付协议、复杂度、保留策略。
   • 回答思路：按是否需要多组消费、确认、重试和审计判断。
   • 详细答案：简单临时队列、失败可重建时 List（列表接口）足够；需要多个消费者组、待确认追踪、认领、历史回放和日志保留时 Stream（流）更合适。Stream（流）能力更强也带来 PEL（待确认列表）治理、修剪和容量监控成本。
   • 进阶追问：关键订单能只依赖 Stream（流）吗？
   • 进阶回答：不建议把它当唯一权威状态。订单状态和幂等流水应落数据库，Stream（流）承担异步传播；通过本地消息表、变更日志或补偿扫描解决双写窗口。

5. 原子组合、批处理与通知

5.1 MULTI（开启事务）、EXEC（执行事务）、WATCH（监视）、Lua（脚本语言）与 Function（函数）

MULTI（开启事务）之后的命令先入队，EXEC（执行事务）时连续执行，中间不会插入其他客户端命令；它不提供关系型数据库式回滚。入队阶段的语法错误可能使事务整体不执行，执行阶段某条命令因类型错误失败时，其他已排队命令仍继续。WATCH（监视）提供乐观并发控制：被监视键在执行前发生变化，EXEC（执行事务）返回未执行结果，客户端负责重试。Lua（脚本语言）把读取、判断和写入放入服务端一次执行，适合库存条件扣减和任务原子领取，但长脚本会占住命令执行路径。Function（函数）把服务端逻辑作为可管理函数库保存，改善部署与复用；它仍受原子执行时长、版本兼容和可观测性约束。

sequenceDiagram
    participant A as 客户端 A
    participant R as Redis
    participant B as 客户端 B
    A->>R: WATCH stock
    A->>R: GET stock = 10
    B->>R: DECR stock，值变 9
    A->>R: MULTI + SET stock 8
    A->>R: EXEC
    R-->>A: 监视冲突，事务不执行
    A->>R: 重新读取并重试

flowchart LR
    C["客户端请求"] --> L["Lua / Function 原子执行"]
    L --> R["读取库存"]
    R --> J{"库存是否足够"}
    J -->|是| W["扣减并记录令牌"]
    J -->|否| F["返回不足"]
    W --> O["一次返回结果"]
    F --> O

数据演绎 10：WATCH（监视）冲突与重试。 客户端 A 监视库存键并读到 10，计划扣 2；客户端 B 先扣 1，使值变 9。A 的 EXEC（执行事务）检测版本变化，不执行设置 8，A 必须重新读取 9 并计算为 7。若每秒 500 个客户端争抢一个热键，冲突重试会显著增加往返与 CPU（中央处理器），此时服务端 Lua（脚本语言）条件扣减更直接，但数据库仍要做最终条件更新和幂等流水。

热门面试题

1. 问题：Redis（远程字典服务）事务为什么不回滚？

   • 考点：事务语义、设计取舍。
   • 回答思路：区分连续执行与数据库事务的原子回滚。
   • 详细答案：事务主要保证排队命令在执行阶段不被其他客户端命令插入，命令参数和类型问题通常被视为编程错误；为任意命令保存撤销日志会增加实现、内存和执行成本。执行期某条失败不撤销其他命令，因此应用必须预校验类型并设计可重试、幂等的状态变化。
   • 进阶追问：那它还算原子吗？
   • 进阶回答：要精确表述：执行序列具有隔离的连续性，但不具备“全部成功或全部撤销”的完整数据库原子性。面试时必须先说明所用原子定义。

2. 问题：WATCH（监视）和 Lua（脚本语言）怎么选？

   • 考点：乐观重试、服务端计算、竞争度。
   • 回答思路：按逻辑复杂度、竞争和网络往返比较。
   • 详细答案：WATCH（监视）适合冲突少、逻辑主要在客户端且可安全重试的场景；Lua（脚本语言）把读判写放在服务端一次完成，适合短小高竞争条件更新。脚本必须限制输入规模和执行时长，并做好返回码、版本和监控。
   • 进阶追问：脚本执行到一半报错会回滚吗？
   • 进阶回答：不能按数据库回滚理解。报错前已经完成的写入可能保留，所以脚本应先完成类型与参数检查，再进行写操作；部署前覆盖异常路径并让操作幂等。

3. 问题：Function（函数）相比 Lua（脚本语言）临时脚本解决什么？

   • 考点：服务端逻辑治理。
   • 回答思路：强调函数库的部署、命名和复用，不夸大执行语义。
   • 详细答案：Function（函数）把服务端逻辑作为函数库管理，减少每个客户端各自携带脚本造成的版本漂移，便于命名、权限和发布。它没有消除长执行阻塞、业务双写或外部副作用问题；仍需版本控制、灰度、回滚预案和容量验证。
   • 进阶追问：能在函数里调用外部支付接口吗？
   • 进阶回答：不能把服务端原子函数当外部事务协调器。原子执行应只操作本实例数据，外部调用延迟不可控且无法与内部写入原子提交；支付通过状态机、幂等和异步补偿协调。

5.2 Pipeline（管道）、Pub/Sub（发布订阅）与能力边界

Pipeline（管道）让客户端不等待每条响应就连续发送多条命令，服务端仍逐条执行并缓存响应；收益来自把多次 RTT（往返时延）摊到较少网络交互，而不是把命令变成一个原子单元。批次过大会放大客户端请求缓冲、服务端响应缓冲和单连接占用，应按响应字节而非只按命令条数定批量。Pub/Sub（发布订阅）把消息实时推给当时在线的订阅者，不保存离线积压，也没有确认、重试和消费进度；适合在线通知或缓存失效提示，不适合作为订单履约唯一消息通道。

sequenceDiagram
    participant C as 客户端
    participant R as Redis
    Note over C,R: 非管道：每条命令等待一次 RTT
    C->>R: 命令 1
    R-->>C: 响应 1
    C->>R: 命令 2
    R-->>C: 响应 2
    Note over C,R: Pipeline 批量发送，命令仍逐条执行
    C->>R: 命令 3 + 命令 4 + 命令 5
    R-->>C: 响应 3 + 响应 4 + 响应 5

flowchart LR
    P["发布者"] --> C["频道"]
    C --> S1["在线订阅者 A"]
    C --> S2["在线订阅者 B"]
    O["离线订阅者"] -.->|不补历史消息| C
    S2 --> X["断线后期间消息不保留"]

数据演绎 11：Pipeline（管道）批处理收益与上限。 客户端到服务端 RTT（往返时延）为 2 毫秒，单命令服务端耗时 0.05 毫秒。顺序执行 100 条命令约消耗 205 毫秒；一次管道理论接近 2 + 5 毫秒，再加序列化和写回成本。但若每条响应 200 KB（千字节），100 条会产生约 20 MB（兆字节）响应缓冲，可能拖慢连接并放大内存。工程上可按 100 到 1000 条或更小字节预算分批，并观察吞吐、P99（99 分位响应时间）和输出缓冲，而不是追求最大批次。

热门面试题

1. 问题：Pipeline（管道）为什么不是事务？

   • 考点：网络批处理、执行交错、错误处理。
   • 回答思路：区分“发送方式”和“服务端原子调度”。
   • 详细答案：Pipeline（管道）只是客户端批量写请求并批量收响应，服务端按收到的命令逐条处理；多个连接的命令可能按事件顺序交错，某条失败也不影响其他命令。它优化 RTT（往返时延），不提供连续执行、冲突检测或回滚。
   • 进阶追问：有依赖关系的命令能放同一管道吗？
   • 进阶回答：若后续命令参数依赖前一响应，普通管道无法在发送前得到结果；应分批、使用 Lua（脚本语言）或重新设计服务端原子命令，不能由客户端猜测结果。

2. 问题：Pipeline（管道）批次是否越大越好？

   • 考点：缓冲、排队、公平性。
   • 回答思路：建立 RTT（往返时延）收益与内存、尾延迟成本模型。
   • 详细答案：批次增大最初能摊薄 RTT（往返时延），但请求与响应会占用客户端和服务端缓冲，单连接长时间占用也可能增加其他请求排队。应按响应总字节、命令复杂度和延迟目标选择批次，并在生产相似网络下压测。
   • 进阶追问：批量轨迹查询如何防止大响应？
   • 进阶回答：限制运单数和每单轨迹条数，只返回必要字段，按字节预算分页；若需要全量导出，转异步任务并把结果放对象存储，不让单个在线请求吞吐全部数据。

3. 问题：Pub/Sub（发布订阅）为什么不适合订单履约？

   • 考点：持久化、确认、断线恢复。
   • 回答思路：演绎订阅者断线时的消息缺口。
   • 详细答案：Pub/Sub（发布订阅）只把消息推给当前在线订阅者，不保存离线期间消息，没有消费进度、确认和重试。订单履约要求事件可追溯、失败可恢复，应使用可靠消息通道或 Stream（流），并由数据库状态机与补偿任务兜底。
   • 进阶追问：它适合什么场景？
   • 进阶回答：适合允许丢失且能从权威源重新读取的通知，例如提示应用刷新配置或刷新本地缓存；订阅者收到信号后再拉取当前完整状态，避免把通知本身当权威数据。

6. 设计思想与项目决策表

项目决策时可以用四问收口：第一，主查询是按键、字段、范围还是消费进度；第二，单键最大元素数和最大字节是多少；第三，失败后能否从数据库重建；第四，命令原子性是否覆盖完整业务副作用。回答完这四问，再选择类型、编码和组合机制，能够避免“因为快所以都放 Redis（远程字典服务）”的低维设计。

7. 综合面试题库

综合题使用说明

以下问题用于三到五分钟完整口述。回答顺序统一为：业务语义与逻辑类型、底层编码与复杂度、失败边界、项目落地、验证证据。该小节是题库过渡，不标记为知识小节。

1. 问题：请完整解释 Redis（远程字典服务）对象模型，以及为什么类型相同内存表现却可能完全不同。

   • 口述答案：我会先把客户端看到的逻辑类型和服务端实际使用的物理编码分开。数据库的键空间字典先把键映射到值对象，值对象由 redisObject（Redis 对象）承载，头部保存 type（类型）、encoding（编码）、refcount（引用计数）以及 LRU（最近最少使用）或 LFU（最不常用）相关信息，数据指针再指向 SDS（简单动态字符串）、dict（哈希字典）、listpack（紧凑列表）、quicklist（快速列表）或 skiplist（跳表）等结构。逻辑类型决定命令语义，编码决定内存布局和实际常数项。同一个 Hash（哈希），少量短字段可能连续存放，缓存局部性好；字段数量或长度跨过当前版本阈值后，会升级为字典，增加桶、指针和分配器开销。升级命令对其他命令仍原子可见，但转换过程可能产生复制、瞬时双份内存和延迟尖峰。因此线上分析不能只看 TYPE，还要看编码、元素数量、成员长度、内存用量和访问命令。我在 WMS（仓储管理系统）中会给仓库库存哈希设置字段数与字节预算，避免把全部 SKU（库存单位）放进单一大键；变更前后以 OBJECT ENCODING、MEMORY USAGE、慢日志和 P99（99 分位响应时间）验证，而不是凭类型名称判断安全。还要把编码切换看成容量事件：在预发布环境构造阈值前后一组数据，比较命令耗时、内存峰值和恢复时间，才能确认线上余量。
   • 进阶追问 1：编码升级是否对客户端可见？ 直接回答：接口和逻辑结果不变，但延迟、内存和编码观测值会变化。
   • 进阶追问 2：删除字段后一定降级吗？ 直接回答：不能假设自动降级，应按版本实测，避免在阈值附近反复转换。
   • 进阶追问 3：refcount（引用计数）是不是垃圾回收？ 直接回答：不是追踪式垃圾回收，它服务于明确对象所有权和释放。
   • 详细知识：对象与编码

2. 问题：SDS（简单动态字符串）为什么这样设计，扩容和缩容对业务有什么影响？

   • 口述答案：SDS（简单动态字符串）的核心不是“换了一个字符数组”，而是把已用长度、分配容量和字节缓冲作为一个受控结构。读取长度不必扫描终止符，按长度访问使它可以保存中间含零字节的二进制内容，写入前检查容量降低越界风险。追加空间不足时会申请更大的连续区域并复制旧数据，预留空间把连续追加的多次重新分配摊薄；缩短逻辑长度时通常不会为了几字节收益频繁缩容，因此用可控空间换取热路径稳定。代价也必须讲清：对象头与预留区不是免费，高峰写入后的容量可能继续驻留，超大值重分配会复制很多字节，并放大网络传输、复制和持久化成本。在库存系统里，整数计数可以使用 String（字符串）的原子数值命令；订单详情若整体序列化成数百 KB（千字节），修改一个字段也要整值读写，就应比较 Hash（哈希）字段建模或把权威详情留在数据库。验收不能只看平均延迟，要观察值大小分布、内存碎片、网络字节和高分位延迟，并在相同数据规模下验证扩容边界。若线上出现“数据删除但进程内存不降”，我会区分逻辑长度、SDS（简单动态字符串）分配容量、分配器碎片和操作系统驻留集，不会直接判断泄漏。治理时先限制最大值和整值更新频率，再通过分片、字段化或外置大对象减少复制；迁移期间保留旧数据回读和校验，避免为了省内存破坏兼容性。 面试收口时我还会强调，结构优化不能替代数据建模：先控制单值上限，再谈扩容策略；告警同时看逻辑字节、已分配字节和进程驻留内存，才能区分业务增长、预留空间与碎片。迁移方案必须可回滚，并以读写结果校验保证没有截断二进制数据。
   • 进阶追问 1：长度读取为何是常数时间？ 直接回答：已用长度保存在结构头部，不需要逐字节扫描。
   • 进阶追问 2：二进制安全是什么意思？ 直接回答：数据按显式长度处理，中间零字节不会被误认为结束。
   • 进阶追问 3：字符串缩短后进程内存为何不降？ 直接回答：容量、分配器碎片和延迟释放都可能让物理内存继续驻留。
   • 详细知识：SDS 与字符串

3. 问题：请用数据演绎解释 dict（哈希字典）的渐进式 rehash（重新哈希）。

   • 口述答案：字典在稳定期使用一张哈希表，键经过哈希后定位桶，在分布均匀和负载受控时平均接近 O(1)（常数复杂度）。扩容时如果一次搬完百万条目，命令执行线程会长时间被占用，所以实现会分配新表，同时保留旧表，用迁移索引记录进度。假设旧表 8 个桶，新表 16 个桶，旧桶 1 有 sku:1 和 sku:9；一次普通增删改查顺带迁移少量桶，重新计算后两键分别进入新桶 1 和 9。迁移期间查询可能先查旧表再查新表，新增通常写新表，删除必须兼顾两表；全部旧桶清空后才释放旧表并完成指针交换。这个设计把一次大停顿拆成持续小成本，但迁移期需要双表内存，并非没有延迟抖动。在线上，我会把内存峰值、负载因子、键分布、命令延迟和扫描任务放在同一时间轴观察。SCAN 在扩缩容与并发修改期间不是强一致快照，可能返回重复项，因此清理任务要幂等并限速，关键库存清单仍以数据库为权威。更高一层的设计思想是把不可避免的 O(N)（线性复杂度）工作摊到多个安全点，而不是假装它消失。容量评审要预留迁移期双表空间，压测要覆盖扩容过程中持续写入和扫描并发；若在内存接近上限时才触发扩容，算法正确也可能被物理资源击穿。 如果迁移期间出现延迟尖峰，我会先对齐内存扩张、请求量和扫描任务，确认是新表分配、大桶搬迁还是业务大命令，而不是立即调高超时掩盖排队。止血可暂停非关键扫描和限制写入突发，根治则调整分片与容量水位，并复测完整迁移周期。
   • 进阶追问 1：为何是平均 O(1)（常数复杂度）？ 直接回答：结论依赖哈希均匀和冲突链较短，极端碰撞会让路径变长。
   • 进阶追问 2：迁移期间新键写哪里？ 直接回答：通常写入新表，避免继续扩大待迁移旧表。
   • 进阶追问 3：渐进迁移会额外占什么？ 直接回答：新旧两张表的桶空间、搬迁 CPU（中央处理器）和更复杂的查询路径。
   • 详细知识：字典与渐进迁移

4. 问题：为什么 Redis（远程字典服务）为小集合设计 intset（整数集合）和 listpack（紧凑列表）？

   • 口述答案：只看理论复杂度容易误判小数据结构。小集合若每个元素都单独分配并保存多个指针，分配器元数据、指针和缓存未命中可能比有效数据还贵。intset（整数集合）把纯整数按宽度有序连续保存，没有逐元素指针，查找可二分；加入更大范围整数时需要整体升级宽度，加入非整数时则转为一般集合编码。listpack（紧凑列表）把多个短元素连续编码，遍历时相邻数据更容易进入同一 CPU（中央处理器）缓存行，适合小型 Hash（哈希）与 ZSet（有序集合）；代价是中部插入删除可能移动后续字节，大元素或大量元素会放大复制成本。升级后通常不能假设自动降级，因为反复重编码会造成震荡。工程上应把阈值视为版本和配置相关条件，不背永久数字。我会用字段数、最大字段长度、更新位置和访问比例建立容量模型；例如报警去重集合若只有数十个短整数，连续编码划算，增长到海量设备后则应分片并监测编码升级、内存峰值与延迟。判断结构不能只看平均元素数，还要看最长成员和突发写入，因为一个超长值就可能触发整体升级。上线前我会构造阈值减一、等于阈值、阈值加一三组样本，记录编码、命令耗时和内存；升级后不依赖自动回退，必要时通过新键重建和原子切换治理，但重建必须兼容并发写。 这种优化的边界必须量化：连续结构节省的是逐元素头部和随机访问成本，付出的是插入搬移与升级复制。评审时要拿真实成员长度分布，而不是只用十字节样本；若异常长字段可能进入，就在入口限长或把大字段拆到独立键，避免一个值触发全体升级。
   • 进阶追问 1：为什么连续结构局部性更好？ 直接回答：一次缓存加载能带入相邻多个元素，减少随机指针跳转。
   • 进阶追问 2：intset（整数集合）升级为何可能慢？ 直接回答：所有元素可能要按更宽表示重写并移动位置。
   • 进阶追问 3：阈值能否写死在代码里？ 直接回答：不应，需读取部署版本配置并用编码和内存命令验证。
   • 详细知识：紧凑结构

5. 问题：quicklist（快速列表）解决了什么问题，List（列表接口）做轨迹队列有什么边界？

   • 口述答案：如果 List（列表接口）每个元素都是独立链表节点，指针和分配开销高、内存局部性差；如果全部元素放在一块连续内存中，两端以外的修改和大规模扩容又会搬移太多字节。quicklist（快速列表）用双向链接组织多个紧凑节点，节点内部连续保存多个元素，因此两端操作通常只影响少量节点，同时减少逐元素指针开销。节点大小与压缩策略决定空间、CPU（中央处理器）和访问延迟的折中，不能只说“底层是链表”。在跨境物流中，若只缓存每票运单最近 100 条轨迹，追加后同步裁剪，单键边界明确，List（列表接口）可以承担快速展示；如果需要消费者确认、故障认领、多组独立消费和历史回放，则应使用 Stream（流）或专业 MQ（消息队列）。无论哪种结构，完整轨迹仍应进入权威数据库或可审计存储。上线前要用最大元素长度、每单轨迹上限、批量读取字节和删除成本压测，防止少数异常运单形成大键。队列语义还要单独设计：直接弹出后宕机会丢任务，原子移动到处理中列表虽能恢复，却要自己维护确认、超时和毒消息。容量上应按租户或业务分片，读取只取最近窗口，删除大列表优先异步释放；通过故障注入验证消费者在弹出前、业务提交后和确认前崩溃时都能收敛。 我还会为轨迹缓存建立可验证的不变量：每票最多保留固定条数，数据库事件数不能少于缓存展示数，消费失败必须进入可重试状态。监控同时覆盖列表长度、最大元素字节、批量读取响应和异步释放积压，任何一项越界都能定位到运单并降级回源。
   • 进阶追问 1：为什么不能无限追加轨迹？ 直接回答：读取、复制、删除和恢复成本都会随单键增长被放大。
   • 进阶追问 2：弹出后消费者崩溃如何处理？ 直接回答：直接弹出可能丢任务，需要原子移入处理中状态或采用有确认机制的流。
   • 进阶追问 3：节点越大越省内存吗？ 直接回答：指针比例会下降，但节点修改和解压成本上升，需要按负载平衡。
   • 详细知识：紧凑结构与快速列表

6. 问题：skiplist（跳表）为什么适合 ZSet（有序集合），同分成员如何排序？

   • 口述答案：ZSet（有序集合）有两个主要访问方向：按成员快速查分数或更新分数，以及按分数做排名和范围遍历。常规编码因此同时维护 dict（哈希字典）与 skiplist（跳表）：字典负责成员点查，平均接近 O(1)（常数复杂度）；跳表按分数和成员建立全序，查找、插入和删除平均 O(log N)（对数复杂度），底层有序链适合范围遍历。维护两份索引增加内存和写入成本，却避免任何一个主要查询退化为全量扫描。跳表通过随机层高取得期望对数性能，内部层高不会改变外部排序。分数相同时，成员字节序用于形成确定顺序，所以同毫秒延迟任务不能把“同分”误解为严格创建顺序。项目中我会把任务唯一标识放入成员，把到期时间放分数，领取时用 Lua（脚本语言）原子地从待执行集合转入处理中集合；业务处理以任务号幂等，超时可重投。若需要同毫秒顺序，可引入序列字段，但必须验证分数精度和成员编码，不能牺牲可辨识性。跳表的概率层级是设计取舍，不影响业务顺序，却意味着复杂度应说“期望对数”而非绝对保证。工程验证要同时测成员点查、分数范围、批量删除和分数更新，监控集合基数、最旧任务滞留和领取耗时；否则结构层面查询很快，也可能被无限积压拖成大键。 延迟任务方案还要区分“到期可见”和“业务完成”：排序结构只回答何时应尝试，处理中集合回答谁已领取，数据库状态回答副作用是否成功。容量测试要覆盖大量同分任务和超时重投，验证成员全序、批量领取上限和失败恢复，而不是只测正常均匀到期。
   • 进阶追问 1：为何不用单独一棵树？ 直接回答：树能做范围，但按成员点查不如额外字典直接，双索引用空间换两类查询速度。
   • 进阶追问 2：更新分数有什么成本？ 直接回答：字典定位后，成员可能从跳表旧位置删除并在新位置插入。
   • 进阶追问 3：跳表最坏复杂度是什么？ 直接回答：面试应表述期望或平均对数性能，不把概率结构说成绝对上界。
   • 详细知识：跳表与同分排序

7. 问题：五种核心数据类型应该如何从业务查询路径选择？

   • 口述答案：我不会从“哪个类型更高级”开始，而会先问主要访问意图。单值、计数和位状态优先 String（字符串）；对象字段局部读写可考虑 Hash（哈希）；只需要两端有序入队出队可用 List（列表接口）；唯一性、交并差和成员判断适合 Set（集合接口）；按分数排序、排名和时间范围适合 ZSet（有序集合）。然后继续问四个边界：单键最大元素和字节是多少，元素是否需要独立过期，跨字段更新是否必须一起原子，故障后是否能从数据库重建。例如库存快速计数可用 String（字符串），但最终防超卖由数据库条件更新和幂等流水兜底；订单摘要字段生命周期一致且规模受控时用 Hash（哈希），不能把全仓百万 SKU（库存单位）塞进一个键；短期轨迹展示可用受限 List（列表接口），可靠异步处理改用 Stream（流）；延迟任务用 ZSet（有序集合），领取和重试另建状态机。最终用真实值大小、命令比例、网络字节、P99（99 分位响应时间）和故障恢复演练验证，不以命令复杂度表代替容量设计。类型选择之后还必须定义键生命周期和故障域：是否按租户、仓库或日期分片，最大基数和字节是多少，如何过期、重建和灰度迁移。对于任何“平均 O(1)（常数复杂度）”命令，我都会追问批量参数和单键规模，因为单次处理百万成员仍会占住执行路径。设计评审最终以业务不变量和降级方案收口。 最后把选型写成数据契约：键格式、字段含义、最大规模、过期规则、允许命令、失败降级和权威来源都要明确。这样后续开发不会因为看到某命令平均很快就任意追加成员；线上发现越界时，也能按契约定位责任业务并执行拆分，而不是全库猜测。
   • 进阶追问 1：一个大 Hash（哈希）和多个键怎么选？ 直接回答：比较字段生命周期、独立过期、路由、键头开销和单键故障域。
   • 进阶追问 2：Set（集合接口）交集能在线算大集合吗？ 直接回答：高基数集合运算可能长时间占用执行路径，应离线化、预计算或限制规模。
   • 进阶追问 3：缓存能否成为库存权威？ 直接回答：通常不能，数据库条件更新和唯一流水承担最终正确性，缓存负责加速和削峰。
   • 详细知识：核心类型建模

8. 问题：Bitmap（位图）为什么省空间，又为什么可能突然浪费空间？

   • 口述答案：Bitmap（位图）是在 String（字符串）字节上把一个偏移对应为一位，因此表达大量稠密布尔状态时空间接近理论下限。100 万个连续设备只记录“今天是否报警”，数据位约 125 KB（千字节），而把每个设备号存成集合成员会附带对象、哈希桶和指针成本。位设置、位读取和位统计也便于做日活、签到或状态交集。但空间由最大位偏移决定，而不是已设置位的数量：只有编号 1 和 10 亿两个设备时，设置第 10 亿位会让字符串扩展到约 125 MB（兆字节），稀疏场景反而浪费。还要考虑编号映射、时间分片和过期边界，例如按租户和日期拆键，避免一个全局位图永久增长。在 IoT（物联网）报警治理中，我会先确认设备编号是否连续可控；连续编号可用位图记录某日是否出现某类报警，随机字符串设备号则先做稳定映射或改用 Set（集合接口）。位图只负责状态加速，报警明细仍在数据库。验收时模拟最大偏移、统计命令和跨日轮换，观察内存与延迟，避免只用平均编号测试。编号映射本身也要稳定可追溯，不能因设备删除后复用旧偏移造成历史状态串扰。跨日统计可按日期键做位运算，但要估算结果键的临时内存并限制时间范围；当设备集合高度稀疏时，应通过样本数据比较 Set（集合接口）实际内存，而不是坚持位图一定更省。 位图迁移也要谨慎：编号映射表一旦变化，旧位含义就会改变。应给映射和位图都带版本，新旧版本并行写入一段时间，按样本设备核对后再切换统计；若发现极端偏移，先阻止继续扩展并转存稀疏结构，避免单个异常编号持续放大内存。
   • 进阶追问 1：Bitmap（位图）是独立类型吗？ 直接回答：不是，它建立在 String（字符串）的位操作之上。
   • 进阶追问 2：设置不同位是否会互相覆盖？ 直接回答：使用服务端位命令时每条命令原子执行，不等于客户端整值读改写。
   • 进阶追问 3：如何控制时间范围？ 直接回答：按日或月分键并设置合理 TTL（存活时间），避免单键无限增长。
   • 详细知识：位图与空间模型

9. 问题：HyperLogLog（基数统计）的设计思想是什么，为什么不能用于精确业务？

   • 口述答案：HyperLogLog（基数统计）解决的是“海量去重数量大概是多少”，它不保存全部成员，而是对成员做哈希分组，记录能反映罕见前导零长度的寄存器摘要，再通过统计校正估算总体基数。因为寄存器数量固定，内存不会随成员数线性增长，这就是用概率误差换空间；不同统计集合还可以合并摘要，适合 UV（独立访客数）、活跃设备数量和趋势监控。代价有三点：结果有误差，不能返回具体成员，单个成员是否已出现也不能由估算值可靠判断。因此它不能用于库存扣减、支付人数结算、唯一订单计费或报警精确去重，这些场景要求可审计的精确集合、数据库唯一约束或明细计算。在 IoT（物联网）平台中，我可以用它估算某小时活跃设备，指导容量和趋势告警；真实故障设备清单仍来自明细表或集合索引。验证时要用已知基数的数据集测试误差分布，并覆盖重复率、数据倾斜和合并场景；产品指标需要标注“估算”，不能把单次估算波动解释为真实业务突变。多个窗口合并前还要保证成员规范化规则一致，例如设备号大小写、租户前缀和匿名化算法一致，否则技术误差之外会叠加业务口径误差。告警应结合滑动平均和明细采样复核，不能因为一次估算下降就直接判断设备离线；这体现概率结构必须和指标治理共同设计。 指标平台还应把估算口径写入元数据，展示采样窗口、去重字段、合并范围和是否近似；当业务方要求追查具体设备时，必须跳转到明细系统。这样既利用固定量级内存承载趋势，又不会让近似指标越权成为审计事实或自动触发财务动作。
   • 进阶追问 1：它为何不能判断某成员存在？ 直接回答：寄存器保存统计摘要而非成员集合，无法反向恢复成员。
   • 进阶追问 2：可以统计支付用户数吗？ 直接回答：可做运营近似趋势，不能作为资金结算依据。
   • 进阶追问 3：概率结构是否意味着结果随机乱跳？ 直接回答：误差有统计边界，应通过大样本和时间窗口理解，不是任意结果。
   • 详细知识：概率基数统计

10. 问题：Geo（地理位置）如何参与海外仓选仓，为什么不能直接给出最终履约答案？

• 口述答案：Geo（地理位置）能力适合把经纬度编码后做邻近范围查询，它能快速从大量仓库或网点中筛出地理上接近的候选，减少后续规则计算范围。但“直线距离近”不等于“订单可履约且总成本最低”：海外仓还受可售库存、保质期、承运商服务区、道路与海运网络、清关主体、截单时间、时区和配送承诺影响。正确设计是分层决策：先用 Geo（地理位置）按坐标与半径粗筛候选，再读取库存与仓配置版本，由履约规则引擎计算成本和 SLA（服务等级协议），最后在创建出库单前再次做库存条件扣减与能力校验。坐标索引属于派生数据，可以从仓库主数据重建；不能让索引更新成功就代表仓库配置事务成功。在线上我会记录候选数量、粗筛耗时、二次淘汰原因和最终仓差异率，抽样与权威地图或路线服务对比。若索引不可用，可降级为按国家区域或固定优先级选择并标记人工复核，而不是无约束承诺时效。索引更新流程应携带仓库配置版本，消费者只接受不旧于当前版本的变更；重建时从数据库分页加载并双写到新键，完成数量和抽样校验后再切换读流量。这样即使坐标缓存损坏，也只是候选检索降级，不会改变订单和库存的权威事实。 对外承诺必须使用最终规则结果而不是缓存候选；候选为空时记录坐标、半径、配置版本和淘汰原因，便于判断是索引陈旧、库存不足还是服务区配置错误。通过历史订单回放比较改造前后选仓结果和履约成本，才能证明空间索引确实提升决策而非只缩短一次查询。
• 进阶追问 1：Geo（地理位置）距离是道路距离吗？ 直接回答：不是，它适合作为地理邻近粗筛，路线成本需专业服务计算。
• 进阶追问 2：仓坐标变更会怎样？ 直接回答：更新派生索引并携带配置版本，关键下单环节重新校验。
• 进阶追问 3：索引丢失是否丢订单？ 直接回答：不应，仓主数据和订单状态在数据库，索引可重建。
• 详细知识：地理位置索引

11. 问题：请解释 Stream（流）消费者组、PEL（待确认列表）和至少一次交付。

• 口述答案：Stream（流）是可保留的追加日志，条目有有序标识与字段；消费者组维护该组的新消息投递位置，并把已投递但未确认的消息记录到 PEL（待确认列表），其中包含归属消费者、空闲时间和投递次数。消费者读取新消息后，先完成可幂等的业务副作用，再执行确认；确认只移除待确认状态，不会自动删除流条目，日志保留由修剪策略控制。至少一次交付的关键崩溃窗口是“数据库已经写成功，但确认尚未发出”，消费者重启或其他消费者认领后会再次收到同一条消息，所以业务必须用运单号与轨迹事件号的唯一约束、状态机版本或幂等流水消除重复副作用。另一个窗口是生产者写业务库成功而写流失败，需用本地消息表、变更日志或补偿扫描修复。上线后不能只看流长度，还要看 PEL（待确认列表）数量、最大空闲、投递次数、确认速率和毒消息原因；达到重试阈值的消息应隔离并保留上下文，不能直接确认后丢弃。轨迹消费的状态机还要明确“新建、处理中、成功、可重试失败、人工失败”，认领只改变消息所有者，不应绕过业务状态检查。修剪策略要大于最大故障恢复与审计窗口，并在缩短前确认不存在仍需回放的消费者组；通过让消费者在写库后确认前强制退出，验证重复投递确实被唯一约束吸收。 生产环境还要定期盘点长时间空闲且投递次数高的记录，把业务异常、依赖超时和永久非法数据分开；可恢复错误退避重试，永久错误进入隔离区并保留原始内容。修复后从幂等入口重放，确认数据库结果正确再清理隔离记录，形成可审计闭环。
• 进阶追问 1：XACK 会删除消息吗？ 直接回答：不会，只清理消费者组中的待确认记录。
• 进阶追问 2：消费者崩溃后谁处理？ 直接回答：其他消费者扫描超时待确认消息并认领，再通过幂等入口重试。
• 进阶追问 3：能做到业务恰好一次吗？ 直接回答：基础设施单独不能，需要消息标识与业务存储的幂等约束共同实现效果上的一次。
• 详细知识：流与消费者组

12. 问题：Stream（流）、List（列表接口）和 Pub/Sub（发布订阅）如何选择？

• 口述答案：三者解决的是不同层次的问题。List（列表接口）适合简单的两端队列，模型轻、命令直接，但如果直接弹出后消费者崩溃，元素可能丢失；要可靠处理就需手工增加处理中列表、超时恢复和幂等。Stream（流）提供可保留条目、消费者组、PEL（待确认列表）、认领和历史范围读取，更适合轨迹事件或异步任务，但必须治理待确认堆积、日志修剪和重复投递。Pub/Sub（发布订阅）只向当前在线订阅者实时推送，不保存离线积压，没有确认和消费进度，适合“提醒刷新”的非关键通知，不适合订单履约。选择时我会问：消息能否丢、是否需要回放、是否有多个独立消费组、失败后是否要认领、保留多久、业务是否已有专业 MQ（消息队列）。跨境物流轨迹进入可靠消息或 Stream（流），数据库保存权威事件；应用缓存刷新可以用 Pub/Sub（发布订阅）发信号，接收方再拉取当前版本。无论使用哪种结构，生产业务状态与发消息的双写窗口都要用本地事件、变更日志或补偿任务解决。容量方面，List（列表接口）要限制待处理和处理中长度，Stream（流）要同时预算日志与 PEL（待确认列表），Pub/Sub（发布订阅）要关注慢订阅者输出缓冲。运维上还要演练消费者扩缩容、标识变更和长时间停机恢复；若系统已经有成熟 MQ（消息队列），不应仅为减少组件而用数据结构重造一套可靠协议。 选型结论还要包含退出策略：数据如何导出、消费者如何双读、积压如何对齐、何时停止旧通道。尤其订单履约不能在迁移时重复触发副作用，因此新旧通道共享事件唯一号，消费端只认数据库幂等结果；完成数量与异常对账后，才逐步关闭旧消费者。
• 进阶追问 1：List（列表接口）原子移动能否实现可靠队列？ 直接回答：能构建基础处理中协议，但确认、重试、监控和扩展都要自行维护。
• 进阶追问 2：Pub/Sub（发布订阅）断线后能补消息吗？ 直接回答：不能，断线期间消息不会为该订阅者积压。
• 进阶追问 3：Stream（流）能替代所有 MQ（消息队列）吗？ 直接回答：不能，需要比较跨机房、路由、生态、吞吐、保留和运维能力。
• 详细知识：流与通知能力

13. 问题：Redis（远程字典服务）的单命令原子性到底是什么意思？

• 口述答案：单命令原子性要在明确边界内表达：对同一服务端命令执行序列而言，一条命令开始改变数据后，不会被另一条普通命令插入到它的内部，因此计数递增、集合添加等单条命令具有不可分割的可见结果。但它不等于数据已经同步到副本或磁盘，不等于故障切换后一定保留，更不等于 Redis（远程字典服务）写入和 MySQL（关系型数据库）、支付渠道或 MQ（消息队列）组成跨系统事务。多条客户端命令即使紧邻发送，也有被其他连接命令穿插的窗口；“读库存大于零再扣减”必须由 Lua（脚本语言）或受监视事务组合。即使脚本内扣减原子成功，客户端可能收不到响应而重试，主节点也可能在复制前故障，所以仍需请求唯一号、数据库条件更新与对账。面试时我会把执行原子性、持久化保证、复制一致性和业务幂等拆成四层。验证则使用并发压测检查不变量，故障注入检查超时重试与切换窗口，最后以数据库库存和流水对账确认系统级正确性。接口协议必须让调用方区分“明确失败”和“结果未知”：超时属于后者，不能直接换请求号重试，否则会制造双扣。服务端查询幂等流水返回原结果，补偿任务核对缓存预占、数据库扣减和订单状态；这样才把局部原子命令提升为可恢复的业务流程。 事故复盘时也要按四层分别取证：命令是否执行、持久化是否完成、复制是否到达可提升节点、业务流水是否提交。只有业务流水和订单状态能回答客户是否应得到商品；缓存值可以重建，不能为了让缓存数字好看而反向覆盖已经确认的权威交易。
• 进阶追问 1：原子递减能完全防超卖吗？ 直接回答：不能，它只保护缓存键，最终库存还需权威数据库条件更新。
• 进阶追问 2：客户端超时是否代表命令没执行？ 直接回答：不代表，可能已执行但响应丢失，所以写请求必须幂等。
• 进阶追问 3：主从切换会影响结论吗？ 直接回答：会，未复制写入可能丢失，复制与故障边界在后续高可用章节分析。
• 详细知识：原子组合边界

14. 问题：MULTI（开启事务）与 EXEC（执行事务）提供什么保证，为什么执行错误不回滚？

• 口述答案：MULTI（开启事务）之后，客户端命令先进入队列，EXEC（执行事务）触发服务端连续执行这一组命令，执行阶段不会插入其他客户端的普通命令。这解决的是执行顺序隔离，而不是关系型数据库那种带撤销日志的完整事务。入队时可识别的语法或参数问题可能使事务不执行；真正执行时若某条命令因值类型错误失败，其他命令仍会继续，之前成功的写也不会撤销。原因在于 Redis（远程字典服务）把命令错误视为应用编程问题，没有为任意数据操作维护通用回滚日志，从而保持实现与热路径简单。因此应用应在写入前校验类型和参数，避免依赖执行期错误做分支；需要读判写时使用 WATCH（监视）乐观冲突检测或短 Lua（脚本语言）。在库存场景中，简单把“读取、判断、扣减”排进事务仍无法让客户端根据读取结果动态决定后续命令，脚本更合适。测试要覆盖错误命令、客户端断线、超时重试和部分成功后的补偿，并对业务不变量做最终核对。事务队列也不应该塞入未知规模的集合运算，否则虽然没有其他命令插入，整个队列仍会长时间占用执行路径。代码审查应把命令类型、键槽、返回值逐项列出，执行响应必须逐条检查；只有业务可以接受部分成功或每步都幂等可补偿时，才适合使用这种事务语义。 如果业务真的要求“全部成功或全部不发生”，应重新设计为一条服务端状态转换、数据库事务或带补偿的状态机，而不是依赖命令队列名称。事务响应要逐项解析并记录请求号，任何部分错误都进入明确补偿分支；没有补偿设计的多命令写入，不应进入资金和库存关键链路。
• 进阶追问 1：它算不算原子事务？ 直接回答：执行队列连续，但不保证执行错误时全部回滚，需说明原子定义。
• 进阶追问 2：队列中的命令何时真正运行？ 直接回答：在 EXEC（执行事务）触发后按队列顺序执行。
• 进阶追问 3：能否根据队列前一条结果决定后一条？ 直接回答：普通事务队列不适合这种动态依赖，应使用脚本或拆分流程。
• 详细知识：事务语义

15. 问题：WATCH（监视）的乐观并发控制如何工作，高竞争下为什么不合适？

• 口述答案：WATCH（监视）让客户端在事务执行前监视一个或多个键。客户端通常先监视、读取当前状态并在本地计算，再进入事务队列；如果监视后到 EXEC（执行事务）前相关键发生变化，事务不会执行，客户端得到冲突结果后重新读取并重试。它类似乐观并发控制：假设冲突少时不持有锁，用失败重试换取简单并发。假设库存为 10，客户端 A 计划扣 2，客户端 B 先扣 1 使其变为 9，A 的执行会因版本变化放弃，重新计算后才能写 7，避免覆盖 B 的结果。但热点库存每秒有数百并发时，大量客户端都会读旧值、冲突、重试，网络往返与服务端读压力被放大，还可能出现无界重试。此时短 Lua（脚本语言）把读、判断和扣减放在服务端一次完成更稳定；数据库仍用条件更新或版本号提供最终正确性。工程上要设置重试上限、指数退避和失败降级，监控冲突率与重试分布；不能在收到冲突后原样重发旧计算结果，也不能把 WATCH（监视）当悲观锁理解。重试逻辑必须重新读取所有相关键并重新计算，不允许只刷新其中一个值，否则会把跨键不变量建立在混合版本上。压测要从低竞争逐步提高并发，画出冲突率、成功吞吐和平均重试次数的拐点；超过阈值后转为原子脚本、排队或直接限流，而不是无限增加客户端线程。 客户端还要保证重试本身没有外部副作用：在事务成功之前不能先发送支付、消息或邮件。若计算依赖远程服务，监视窗口会被拉长并提高冲突率，应先获取稳定输入或把流程改为状态机；达到重试上限后返回繁忙并排队，而不是继续占用热点键。
• 进阶追问 1：监视冲突会自动重试吗？ 直接回答：不会，客户端负责重新读取、重新计算和控制重试次数。
• 进阶追问 2：适合什么场景？ 直接回答：冲突概率低、逻辑主要在客户端且重试无副作用的短事务。
• 进阶追问 3：重试为什么要退避？ 直接回答：避免大量竞争者立即再次碰撞，形成请求风暴。
• 详细知识：WATCH 冲突

16. 问题：Lua（脚本语言）如何保证库存条件扣减，失败边界是什么？

• 口述答案：Lua（脚本语言）的价值是把多个读判写步骤移到服务端一次执行。例如脚本先读取库存和请求幂等键，若请求已处理就返回旧结果；若库存不足返回明确码；否则扣减库存并记录有期限的请求令牌。脚本执行期间不会被其他普通命令插入，因此避免两个客户端都读到库存 1 后分别扣减。设计时要先做键类型、参数和数值范围校验，再进行写操作，因为脚本不是关系型数据库事务，执行中报错不能假设之前写入会自动撤销。脚本还必须短小且限制遍历规模，长循环或大集合操作会占住命令执行路径，使其他请求排队；所有键在集群环境还受同槽约束，不能把单实例原子性夸大成跨分片原子。客户端超时也不代表脚本未执行，重试必须携带相同请求号。库存最终落库时，用数据库条件更新和唯一扣减流水兜底；若落库失败，状态机和补偿任务决定释放预占还是重试。验证包括高并发不变量、重复请求、脚本错误、超时重试和故障切换后的数据库对账。脚本返回值应是稳定的业务码和必要状态，不把内部异常文本直接暴露给调用方；请求令牌的过期时间要覆盖最大重试与补偿窗口。发布时保留脚本版本、摘要和调用指标，先以生产规模键做最坏路径基准，限制一次扫描元素数；遇到慢脚本先止血限流，再根据业务流水判断是否已经产生副作用。 设计评审中我会给脚本列出最大键数、最大成员数、最坏循环次数和预期耗时，任何无界遍历都必须改写。返回结果包含是否重复、是否成功和当前状态，调用方按业务码处理；监控发现执行时间超过预算时，先暂停批量调用，再从请求流水确认哪些操作需要补偿。
• 进阶追问 1：脚本越复杂是否越能保证一致性？ 直接回答：不是，复杂长脚本会阻塞并扩大失败面，应只承载短原子状态转换。
• 进阶追问 2：脚本报错会回滚吗？ 直接回答：不能按数据库回滚理解，应先校验后写并保持操作幂等。
• 进阶追问 3：为何还需要数据库条件更新？ 直接回答：脚本只保护缓存实例，不能覆盖复制丢失、跨系统提交和权威库存。
• 详细知识：Lua（脚本语言）原子组合

17. 问题：Function（函数）相比临时脚本有什么工程价值，又该如何发布？

• 口述答案：Function（函数）并没有改变服务端原子执行的基本边界，它主要解决脚本资产的治理。临时 Lua（脚本语言）常由各客户端携带，容易出现不同服务保存不同内容、脚本摘要失效后临时加载、权限难收敛和版本难追踪。Function（函数）把逻辑作为命名函数库部署到服务端，客户端按稳定名称调用，更便于集中版本控制、权限、复用和发布审计。但函数仍运行在命令执行路径，长循环、大结果或不受控键访问会阻塞；它也无法调用外部支付渠道并与内部写入原子提交，更不能消除数据库双写。工程发布应为函数库建立版本号、输入输出契约、兼容测试和回退方案，先在影子或低流量实例加载，验证同一输入的返回码与数据变化，再逐步切换客户端。库存扣减函数要保留旧版一段时间，让滚动发布中的客户端都能工作；监控函数耗时、错误码和调用量，异常时可切回经过验证的旧函数。不同 Redis（远程字典服务）版本对函数能力有差异，部署前必须核对版本，而非假设 6.2 与 7.x 一致。权限设计要遵循最小化原则，函数只访问约定前缀并限制调用角色；库升级和灾备恢复后检查函数是否已装载且版本一致。若新旧版本数据格式不同，先让新函数兼容旧格式并完成后台迁移，再删除旧路径，避免函数发布和数据迁移形成一次不可回退切换。 灾备切换也要把函数库纳入检查清单：目标实例不仅要有数据，还要有相同函数版本、权限和配置。自动化发布记录函数内容摘要，客户端启动时探测所需版本；发现不匹配时停止关键写并告警，不能静默回退到语义不同的旧函数继续扣减库存。
• 进阶追问 1：Function（函数）能替代业务服务吗？ 直接回答：不能，它只适合靠近数据的短原子逻辑，不承担复杂编排和外部调用。
• 进阶追问 2：如何做兼容发布？ 直接回答：新旧函数并存、契约测试、低流量验证，再滚动切换调用方。
• 进阶追问 3：函数失败如何观测？ 直接回答：统一返回码并记录调用耗时、错误率、版本和业务请求号。
• 详细知识：服务端函数治理

18. 问题：Pipeline（管道）为什么提高吞吐，如何计算合理批次？

• 口述答案：Pipeline（管道）优化的是客户端与服务端之间的 RTT（往返时延），不是单条命令的算法复杂度。没有管道时，客户端发送一条命令等待响应，再发下一条；若 RTT（往返时延）为 2 毫秒，100 条服务端各耗时 0.05 毫秒的命令，顺序模式约需 205 毫秒。把 100 条一次发送，理论时间接近一次 RTT（往返时延）加 5 毫秒执行，再加序列化和写回成本，吞吐显著提高。但命令仍逐条执行，不具备事务原子性；某条失败不会撤销其他条，后续命令若依赖前一响应也不能直接放在同一普通批次。批次也不是越大越好：请求和响应都占缓冲，若每条响应 200 KB（千字节），100 条约 20 MB（兆字节），会造成输出缓冲、网络拥塞和其他请求排队。合理批次应按总字节、命令复杂度和延迟目标决定。我在批量读取轨迹摘要时会限制运单数、字段和单单条数，分批 100 或按字节阈值动态切分，并比较吞吐、P99（99 分位响应时间）、连接输出缓冲和客户端内存，找到收益拐点。客户端还必须保持请求与响应顺序对应，逐条处理错误；对于写命令，超时重发要携带幂等标识。压测不能只在本机低 RTT（往返时延）环境运行，应模拟生产网络、响应大小和并发连接；当批量吞吐提高却让在线小请求 P99（99 分位响应时间）恶化时，应拆连接、缩批次或把批处理迁到低峰。 批处理失败恢复要记录每条命令对应的业务标识和结果位置，不能因为批次连接断开就把全部写请求换新编号重放。可查询的写先查幂等结果，纯读取可安全重试；若服务端出现输出缓冲告警，立即缩小批次并隔离离线任务连接，保护在线库存与支付请求。
• 进阶追问 1：Pipeline（管道）内命令会被其他客户端穿插吗？ 直接回答：它不提供事务保证，不能依赖批次天然连续执行。
• 进阶追问 2：一条命令错误怎么办？ 直接回答：逐条检查响应并对可重试写使用幂等请求号。
• 进阶追问 3：为什么按字节而非条数分批？ 直接回答：相同条数的响应大小可能相差几个数量级，缓冲风险由字节决定。
• 详细知识：Pipeline 批处理

19. 问题：Pub/Sub（发布订阅）的可靠性边界是什么，怎样正确用于缓存刷新？

• 口述答案：Pub/Sub（发布订阅）提供的是在线实时广播：发布者向频道发送消息，服务端把它推给当时在线且订阅该频道的连接。它不为离线订阅者保存历史消息，没有待确认列表、消费进度、自动重试和回放，因此不能承担订单支付、库存扣减或履约轨迹的唯一事件通道。正确使用场景是“通知可以丢，状态可重读”，例如应用收到配置版本变化或本地缓存失效信号后，再从数据库或 Redis（远程字典服务）键读取当前完整状态。即使某次通知在断线期间丢失，应用也应通过定期版本校验、短 TTL（存活时间）或重连全量刷新最终收敛，而不是永久停留在旧值。发布消息里尽量携带资源标识和版本，不携带唯一权威数据；订阅者处理必须幂等。部署时要监控订阅连接数、重连次数、输出缓冲和消息速率，慢订阅者可能导致连接问题。若业务要求每条通知可审计、失败可恢复，应切换到 Stream（流）或专业 MQ（消息队列），并保留数据库事件记录。缓存刷新协议可让消息只携带资源编号和单调版本，订阅者发现版本更新后拉取快照并原子替换本地缓存；若版本跳跃，直接拉取最新状态，不逐条补通知。定时全量校验和启动时预热是第二收敛路径，发布失败也不应阻塞数据库主事务，这样通知丢失只造成短暂陈旧而非永久业务错误。 发布端也要接受订阅者数量为零时消息仍可能“发送成功”，因此发布返回值不能当作业务送达证明。缓存刷新失败不会回滚数据库更新，应用通过版本比较最终发现差异；若某配置影响资金或权限，读取时直接校验权威版本，不把易丢通知作为安全边界。
• 进阶追问 1：订阅者重连会收到离线消息吗？ 直接回答：不会，应主动拉取当前版本或全量状态。
• 进阶追问 2：消息里能否放完整配置？ 直接回答：可以传输但不应作为唯一权威，推荐传资源和版本后重新读取。
• 进阶追问 3：如何避免缓存永久不一致？ 直接回答：通知之外增加版本校验、TTL（存活时间）和周期刷新形成收敛路径。
• 详细知识：发布订阅边界

20. 问题：请为库存、轨迹、延迟任务和报警去重做一套 Redis（远程字典服务）结构设计，并说明最终正确性。

• 口述答案：我会先把 Redis（远程字典服务）定位成加速与协调层，订单、库存和履约状态仍以数据库为权威。库存热点可用 String（字符串）计数或按仓库分片的 Hash（哈希）快速预检，真正扣减使用短 Lua（脚本语言）做请求去重与条件扣减，再由数据库执行 available >= quantity 的条件更新并写唯一业务流水，失败进入补偿状态。轨迹展示若只保留最近固定条数，可用受限 List（列表接口）；需要消费者组、认领和回放则用 Stream（流），以“运单号 + 事件号”唯一约束消除重复。延迟任务用 ZSet（有序集合）按执行时间排序，Lua（脚本语言）原子领取到处理中集合，任务号幂等，超时扫描重新投递，不能把查询后删除当可靠领取。IoT（物联网）报警去重若设备编号稠密可按日用 Bitmap（位图）记录状态，任意字符串事件用带 TTL（存活时间）的 Set（集合接口）或键；HyperLogLog（基数统计）只做活跃设备近似趋势，不做精确去重。所有键定义最大字节、元素数、分片和过期策略，监控编码、大键、命令延迟和失败状态；通过重复请求、超时、消费者崩溃、补偿重跑及数据库对账验证最终正确性。再补一层降级：缓存不可用时，库存请求限流后走数据库条件更新，轨迹查询回源最近窗口，延迟任务暂停领取但保留权威任务记录，报警去重缩短为进程内窗口并允许少量重复告警。恢复后按业务流水重建派生键，先影子校验数量和抽样内容再切流；整个方案的成功标准不是缓存零错误，而是任何失败都不破坏资金、库存和履约不变量。
• 进阶追问 1：为什么不全用一个 Hash（哈希）？ 直接回答：生命周期、访问路径和容量不同，单大键会扩大故障域和操作成本。
• 进阶追问 2：Redis（远程字典服务）不可用怎么办？ 直接回答：关键写走数据库权威路径并限流降级，派生缓存恢复后重建。
• 进阶追问 3：如何证明没有超卖？ 直接回答：并发故障测试后核对数据库条件更新、唯一流水、订单数量和补偿记录。
• 进阶追问 4：如何证明没有丢轨迹？ 直接回答：核对生产事件、PEL（待确认列表）、数据库唯一事件和补偿重放结果。
• 详细知识：项目决策

8. 复习清单

• 能从键空间追踪到 redisObject（Redis 对象）与实际编码，并解释编码升级的瞬时成本。
• 能画出渐进式 rehash（重新哈希）双表迁移，说明查询、写入、扫描和内存边界。
• 能用局部性、指针开销和升级成本解释 intset（整数集合）、listpack（紧凑列表）与 quicklist（快速列表）。
• 能解释 skiplist（跳表）与 dict（哈希字典）为何共同支撑 ZSet（有序集合）。
• 能按访问路径而非习惯选择 String（字符串）、Hash（哈希）、List（列表接口）、Set（集合接口）和 ZSet（有序集合）。
• 能说明 Bitmap（位图）的稀疏风险、HyperLogLog（基数统计）的误差边界和 Geo（地理位置）的粗筛定位。
• 能演绎 Stream（流）消息进入 PEL（待确认列表）、崩溃认领、幂等写入与确认的全过程。
• 能准确区分单命令、事务、WATCH（监视）、Lua（脚本语言）、Function（函数）和 Pipeline（管道）的原子性。
• 能说明 Pub/Sub（发布订阅）为什么只能承担可丢通知，不能承担订单履约可靠事件。
• 能把库存、轨迹、延迟任务和报警去重的 Redis（远程字典服务）结构与数据库最终正确性串成完整项目话术。