知识卡片
请求重要性分级决定过载时舍弃谁
内容
系统过载时”该拒绝谁”不该无差别处理，而应基于请求携带的重要性标签分四级：最重要级拒绝会 造成严重用户可见问题，重要级次之，两个可丢弃级可以容忍延后重试或经常性不可用。重要性和请求 的延迟敏感度是独立维度——搜索联想词请求延迟要求很高，重要性却很低，过载时不返回也无妨。 更关键的是该属性会在整条调用链上自动透传：高重要性请求触发的下游子请求继承同样重要性， 过载发生在系统深处也能按最初业务优先级正确取舍。
参考来源
- 位置：《SRE：Google运维解密》第21章《应对过载》"重要性"一节（源文件：_epub-src/OEBPS/Text/0009_0012.xhtml）
- 结论依据：原文定义 CRITICAL_PLUS/CRITICAL/SHEDDABLE_PLUS/SHEDDABLE 四级重要性并说明"当某个任务开始进入过载状态时，低优先级的请求会先被拒绝"；同时指出"请求的优先级和该请求的延时性要求……是不相关的"，并说明"如果后端接收到请求A，在处理过程中发出了请求B和C给其他后端，请求B和C会使用与A相同的重要性属性"。
- 原始内容：某个发往后端的请求都会被标记为以下4类中的一种……请求的优先级和该请求的延时性要求，也就是底层的网络服务质量（QoS）信息是不相关的……我们同时增强了RPC系统，可以自动传递重要性信息。