4. 开关延迟的定义与分类：网络延迟、SDK评估延迟、缓存延迟、配置同步延迟

在Feature Flag系统中，开关延迟是指从用户请求发起至最终获取到开关决策结果之间的时间差。准确理解延迟的构成是优化MTTR（平均修复时间）的前提。根据延迟产生的环节与原因，可将其划分为以下四类核心延迟。

4.1 延迟分类总览

4.2 网络延迟

网络延迟是开关评估中最不可控的因素，主要受物理距离、网络拥塞、DNS解析、TLS握手等影响。在分布式架构中，SDK与后端服务之间的每一次RPC调用都会引入网络延迟。

• 南北向延迟：客户端（浏览器/移动端）到边缘节点或API网关的延迟，通常受用户地理位置影响较大。
• 东西向延迟：微服务之间、SDK与配置中心之间的延迟，受服务部署拓扑和网络带宽影响。
• 协议开销：HTTP/1.1的队头阻塞、gRPC的序列化/反序列化、WebSocket的长连接维护等。

4.3 SDK评估延迟

SDK评估延迟是指SDK在接收到开关请求后，执行规则匹配、条件计算、返回值确定所消耗的时间。这部分延迟虽然单次很小，但在高并发场景下会被放大。

• 规则匹配：遍历开关的匹配条件（用户ID、分组、百分比、属性等），条件越多延迟越高。
• 表达式计算：复杂条件（如自定义脚本、正则匹配、数值范围）的计算耗时。
• 日志与埋点：SDK在评估过程中同步写入日志或上报埋点数据，可能阻塞主流程。

4.4 缓存延迟

缓存是降低开关评估延迟的核心手段，但缓存本身也会引入延迟。缓存延迟包括缓存读取延迟、缓存写入延迟、缓存失效延迟以及缓存一致性维护延迟。

4.5 配置同步延迟

配置同步延迟是指开关配置从控制台修改后，经过配置中心、消息队列、SDK拉取等环节，最终在客户端生效的时间差。这是影响开关变更MTTR的最关键因素。

4.6 延迟分类在MTTR复盘中的应用

在MTTR复盘时，需要将总延迟拆解到上述四类，并针对每一类设定SLO（服务等级目标）。以下是一个典型的复盘口径示例：

# 开关延迟MTTR复盘口径示例
# 假设一次开关变更从提交到全量生效的总延迟为5秒

total_latency = 5s
network_latency = 0.8s    # 占比16%
sdk_eval_latency = 0.2s   # 占比4%
cache_latency = 0.5s      # 占比10%
sync_latency = 3.5s       # 占比70%

# 复盘结论：配置同步延迟是主要瓶颈，需优化消息队列分发策略
# 优化目标：将sync_latency降低至1s以内，总延迟控制在2s以内