Zig 事件循环架构手册：调度预算、回压链路与可恢复并发

如果把并发系统比作交通网络，事件循环就是总调度中心。它的职责不是“把任务都跑完”，而是在资源有限、负载波动、失败频发的现实里，持续做可解释决策：哪些任务先执行，哪些任务排队，哪些任务要取消，哪些任务必须降级。很多系统在低负载下表现优雅，一到高峰就雪崩，本质是没有把调度规则工程化。

Zig 的价值在于把系统控制权交回开发者：你可以明确 I/O 轮询策略、任务数据结构、错误传播路径、内存所有权。代价是你必须承担设计责任。尤其在 async/await 仍处于演进背景下，团队更需要“可替换、可回滚、可观测”的事件循环方案，而不是把并发逻辑写成不可维护的技巧集合。

先定义并发预算，再谈执行模型

事件循环设计常见误区是先选模型再补预算。正确顺序应该相反：先定义预算，再选模型。预算至少包括四项：每周期最大任务数、每任务最大执行片段、队列上限、取消延迟上限。没有预算，就没有稳定性。系统会默认朝“吞掉所有输入”的方向演化，最终在最忙的时候失控。

预算定义后，再选择执行模型：单循环 + 非阻塞 I/O、多循环分片、或混合线程池。单循环的优点是状态一致性强、调试路径短，缺点是单核瓶颈明显；多循环吞吐更高，但跨循环协调复杂。对多数业务系统，推荐从“单循环 + 明确配额”起步，再按瓶颈演进。不要一开始就追求复杂架构，复杂度会先吞掉你的可观测能力。

事件源治理：输入必须被驯化，不能无限注入

事件循环的稳定性首先取决于事件源。网络套接字、定时器、内部通道、文件 I/O 都会不断注入任务。如果你只优化执行器而不治理输入，结果就是“处理速度提升但排队更快增长”。因此事件源要有准入策略：限速、分级、背压、丢弃规则。

建议把事件分成三层：

强实时层：心跳、超时、取消信号，优先级最高。
主业务层：请求处理、响应输出，受预算控制。
延迟容忍层：日志刷新、缓存回写、统计汇总，可在压力下降级。

这三层必须在调度队列上物理区分，而不是只靠优先级字段。因为统一队列在高压下容易被主业务占满，导致取消与超时信号延后，最终让系统失去自我修复能力。

flowchart LR
    A["事件源: socket/timer/channel"] --> B["准入层: 速率与配额"]
    B --> C["强实时队列"]
    B --> D["主业务队列"]
    B --> E["延迟容忍队列"]
    C --> F["调度器: 周期预算"]
    D --> F
    E --> F
    F --> G["执行片段"]
    G --> H{"完成?"}
    H -- 否 --> I["重入队/让出"]
    H -- 是 --> J["收尾与指标上报"]
    I --> F

取消传播与超时语义：失败要沿着同一条路径回流

在并发系统里，“取消”比“成功”更考验架构质量。成功路径通常在开发期被反复测试，而取消路径经常被忽略，直到线上高峰才暴露漏洞。事件循环中必须把取消传播做成一等机制：父任务取消时，子任务如何接收信号、何时停止、怎样回收资源、是否需要补偿，都要有明确语义。

超时语义同理。超时不应该只是“日志里多一行 timeout”，而应该触发可验证动作：中断 I/O、释放缓冲、记录耗时分位、更新失败预算、必要时触发降级。尤其在多阶段任务里，超时要区分“排队超时”和“执行超时”，否则你无法判断瓶颈是在入口还是执行器内部。

建议做一条铁律：任何取消或超时都必须可追踪到同一个 trace_id，并在事件循环层统一收敛。这样值班时才有完整链路，而不是到处翻日志拼碎片。

性能路径：让任务“短跑”，不要“长跑霸占”

事件循环最怕长任务霸占。即使平均耗时不高，只要少量长任务卡住循环，P99 就会明显恶化。应对策略是“任务切片化”：把可中断的逻辑拆成多个短片段，每个片段执行后主动让出。切片化不是为炫技，而是保证调度公平性。

另一个关键点是内存行为。频繁创建临时任务对象会放大 GC 语言常见问题，在 Zig 里虽然没有 GC，但同样会导致 allocator 压力和缓存抖动。建议为任务元数据使用池化或固定缓冲，避免在热点路径反复堆分配。事件循环应该把 CPU 时间花在业务处理，而不是花在管理任务壳子。

I/O 层面，非阻塞 API 与批量提交通常比逐请求系统调用更稳定。你需要关注的是“每成功请求消耗多少系统调用”“等待队列长度如何波动”“任务重入队比例是否异常”。这些指标直接反映循环是否健康。

可运维性：值班同学要能在 10 分钟内定位问题

事件循环上线后，运维指标至少应包含：

loop_tick_duration_ms：每轮调度耗时
queue_depth_{realtime,biz,deferred}：各队列长度
task_wait_p99_ms：任务等待时间
task_cancel_propagation_ms：取消传播耗时
timeout_rate：超时率
reschedule_ratio：任务重入队比例

如果这些指标缺失，任何“系统慢”都只能靠经验猜。建议将告警设计为组合条件：例如 queue_depth_biz 上升 + task_wait_p99_ms 上升 + reschedule_ratio 上升，才判定调度拥塞。单指标告警很容易误导，导致过度扩容却不解决根因。

发布策略上，建议灰度阶段打开细粒度 tracing，稳定后采样保留关键路径。不要把 tracing 和监控对立起来；前者回答“为什么慢”，后者回答“慢到什么程度”。两者缺一不可。

兼容演进：面向 async 语义变化做“结构稳定”

Zig 社区关于 async/await 与协程模型一直在推进，工程上更应避免把实现绑死在单一语法特性上。可行策略是把“调度接口”和“任务语义”解耦：上层仅依赖抽象任务接口，底层可替换为不同运行策略（阻塞线程池、单线程事件循环、用户态协程）。

这类解耦的好处是：语言或工具链特性变化时，你只需替换运行层，不必重写业务层。很多团队忽视这一点，结果每次升级 Zig 都要大面积改并发代码。你要追求的不是“一次写死”，而是“长期可演进”。

演练机制：没有故障演练，就没有并发可信度

事件循环的健康不能只靠线上观察，必须周期性演练。建议每个迭代至少演练三类故障：

输入突增：模拟事件洪峰，验证限流和回压。
外部依赖抖动：模拟 I/O 延迟上升，验证取消传播。
内部热点阻塞：模拟长任务插入，验证切片和公平性。

每次演练后要形成结构化复盘：触发条件、监控信号、自动化动作、人工介入点、回滚效果。把复盘沉淀为 runbook，才算完成一次有效演练。