2. 业务场景与实时性需求拆解

在 Redis 实时数据平台交付中，最容易出问题的地方不是“Redis 会不会用”，而是“业务到底要什么实时性”。很多项目在启动阶段只拿到一句模糊需求，例如“要快”“要实时”“不能丢”，但快是毫秒还是秒级？实时是端到端还是写入即可见？不能丢是允许最终一致还是必须强一致？这些差异会直接决定 Redis 的部署形态、数据结构、持久化策略、集群规模和容灾方案。因此，本章的核心任务是把业务语言翻译成可度量、可验证、可验收的实时性指标。

一、先识别业务事件流，再谈指标

实时性需求不是凭空拍出来的，它来自业务事件流。所谓事件流，就是业务系统中持续发生、需要被快速处理或快速查询的动作序列。不同场景的事件流形态差异很大：

• 用户行为场景：登录、浏览、点击、加购、下单、支付、分享。特点是写入频繁、单条价值低、允许极短时间内的聚合延迟，但要求高吞吐和低写入延迟。
• 风控场景：设备指纹上报、IP 变更、异地登录、频繁试错、交易反欺诈规则命中。特点是要求毫秒级判断，且对数据一致性、规则状态准确性要求高，不能因为缓存过期导致误放行。
• 推荐场景：用户实时兴趣标签更新、物品热度统计、曝光去重、在线特征读取。特点是读多写多、要求低延迟读取，同时允许部分统计结果最终一致。
• 排行榜/计数场景：点赞、投票、库存扣减、积分变更。特点是强并发、要求原子性，QPS 峰值可能是均值的数倍甚至数十倍。

把事件流列清楚后，才能进一步拆出 QPS、延迟、一致性、可用性四类指标。下面这张图展示了从业务场景到实时性指标的拆解关系，以及各场景对指标的侧重点差异。

二、QPS 拆解：不要只看平均值

QPS 是最常被提到的指标，但也是最容易被误用的指标。业务方通常给出“日均 100 万请求”，换算下来平均 QPS 只有约 11.6，看起来一台 Redis 就能轻松扛住。但真实系统的问题几乎都出在峰值上。拆解 QPS 时至少要问四个问题：

1. 峰值 QPS 是多少？例如电商大促开场 10 秒内，写入 QPS 可能是均值的 20~50 倍。假设日均 100 万请求，峰值系数取 30，则峰值 QPS 约为 350。
2. 读写比例是多少？推荐场景常见 10:1 甚至 50:1 的读多写少，而行为埋点可能是 1:1 或写多读少。读写比决定是否需要用主从分离、多副本读。
3. 单条命令的复杂度如何？同样是 1 万 QPS，GET 和 ZADD 加 ZRANGE 对 CPU 的消耗完全不同。大 key、热 key 会进一步放大单节点压力。
4. 连接数是否成为瓶颈？每个业务实例维持的连接数、连接池大小、是否使用 Pipeline，都会影响实际吞吐。

一个可用的估算示例：某推荐场景日均曝光去重请求 800 万次，峰值系数 25，读写比 8:1，则峰值总 QPS ≈ 8000000 ÷ 86400 × 25 ≈ 2315，其中写约 257 QPS，读约 2058 QPS。这个量级单主从即可覆盖，但如果单条读命令涉及大 ZSET 范围查询，就需要重新评估。

三、延迟拆解：区分端到端与 Redis 内部

延迟必须区分两个层面。第一层是 Redis 内部命令延迟，通常用 redis-cli --latency 或 INFO commandstats 观察，健康状态下 P99 应在亚毫秒到 1 毫秒级。第二层是业务端到端延迟，包括网络往返、序列化、业务逻辑、连接池等待，往往才是用户真正感知的延迟。

拆解延迟时建议明确三个口径：

• P50 / P95 / P99：不要只写“平均 2ms”。风控场景如果 P99 达到 80ms，就意味着每 100 次请求有 1 次可能超时，必须按 P99 设计。
• 写入可见延迟：数据写入 Redis 后，下游读取到新值的时间差。主从复制场景下，这个值受复制延迟影响，通常要求小于 100ms。
• 端到端延迟预算：例如风控决策总预算 50ms，其中 Redis 查询分配 10ms，规则计算 20ms，网络与其他 20ms。预算是拆解的依据，也是验收的标准。

四、数据一致性与可用性：明确取舍边界

一致性和可用性往往需要业务方明确取舍。Redis 主从异步复制天然存在短暂不一致窗口，如果业务要求“扣减库存后立即读到最新值”，就必须走主节点读或使用 RedLock 等更强方案；如果只是排行榜展示，允许秒级最终一致，则可以用从节点读来分摊压力。

可用性方面，需要把 SLA 翻译成具体动作。例如“99.99% 可用”意味着全年不可用时间不超过约 52 分钟，这要求至少主从加哨兵或 Cluster 三主三从，并明确故障转移时间目标。同时要定义降级策略：Redis 不可用时，风控是拒绝所有请求还是放行并记录日志？推荐是返回默认列表还是走本地缓存？这些必须在需求阶段写清楚，而不是等故障发生后再讨论。

五、把指标写成可验收的表格

需求拆解的最终交付物，是一张业务方和交付方都认可的指标表。下面给出一个示例结构，实际项目中可按场景逐行填写。表中数值为教学示例，不代表真实生产实测值。