系统设计演练：高吞吐规则引擎

设计一个服务：它把事件与一套持续变化的规则做匹配，然后返回或发布决策。这道题之所以有用，是因为它逼你在吞吐、规则新鲜度、延迟和正确性之间做取舍。

1. 澄清契约#

先把控制面和数据面分开。

• 控制面让有权限的用户创建、校验、版本化、审批和回滚规则。
• 数据面用一份生效的规则快照去评估高吞吐的事件流。

要问清楚：峰值事件速率、事件体积、P99 决策延迟、规则数量与复杂度、可接受的规则生效延迟、保序需求，以及部分故障时期望的行为。

2. 定一条简单的链路#

异步方案：

生产者 → 持久化事件日志 → 分区评估器 → 决策 topic → 消费方
                              ↑
                         带版本的规则缓存

按产品真正需要保序的键分区，比如账户或设备。评估器消费的是本地、不可变的规则快照，这样热路径不必为每个事件去查规则库。

如果需要同步决策，就在同一套评估模型前面加一层很薄的 API，并明确定义超时与降级行为。

3. 给规则变更做版本#

控制面校验新规则集，作为一个版本存储，然后发布一个激活事件。评估器先加载并校验快照，再原子地切换。每条决策都记录事件 ID 和规则集版本。

这让决策变得可解释，也让回滚变得安全，同时避免出现「半更新的集群对同一事件给出不同结果且无从追溯」的局面。

4. 处理重复与重放#

假设至少一次投递。如果下游动作必须只执行一次，消费方就需要基于决策 ID 的幂等。事件流和决策流要保留足够长的时间，以便在出现缺陷或规则修正后重放，并配上与数据敏感度匹配的访问控制。

5. 把运维写进答案里#

需要观测：入流速率、消费积压与积压时长、评估延迟、规则加载失败、决策分布，以及资源饱和度。为高风险的规则变更加上灰度激活，并提供一个不需要重新发布就能关停单条规则的 kill switch。

最后，点名最大的几个风险：热点分区、开销过大的规则、状态膨胀、毒消息，以及规则灰度过程中的关联性故障。一个好的系统设计答案，会说清楚假设被打破时系统会怎么表现。