【Envoy 数据面】Main / Worker 与配置快照：事件循环、TLS 与几乎无锁热路径
内容提要
本文介绍Envoy数据面代理的线程模型与配置分发机制。Main线程负责xDS解析和编排，不处理高并发流量；Worker线程通过独立Dispatcher处理绑定到本线程的连接，实现shared-nothing并行。配置更新通过Thread Local Storage快照分发，热路径读取配置无需全局锁，但存在新旧快照并存的短暂窗口，不保证全进程瞬时一致。
延伸解读
线程模型与常见误区
文章指出两个常见误区：一是把 Main 线程当作也会处理请求的 master，二是把 TLS 快照当作全进程瞬间一致的共享内存。实际上，Main 线程只负责管理面任务，不承载高并发流量；TLS 快照是线程本地的，更新是异步的，存在新旧快照并存的窗口。理解这些有助于避免在排障时找错方向。
连接绑定与性能排查
连接在 accept 后绑定到单个 Worker，终生不迁移，这实现了 shared-nothing 并行。因此，排查单连接延迟尖刺时，应关注该连接所在 Worker 是否卡在某个 filter 或上游，而不是平均所有 Worker。CPU 不均时，需区分连接数不均与单连接 CPU 重，后者无法靠迁移连接解决。
TLS 快照的局限与工程权衡
TLS 快照让热路径读配置无需全局锁，但并非零成本：大对象重建和引用计数释放仍占用 Worker 时间片，更新风暴时可能抬升延迟。此外，xDS ACK 仅表示协议层接受，不等同于流量已切换新配置。文章强调，没有免费的全局瞬时一致，静态文件 reload 用进程边界换一致性，而 xDS 用并存窗口换热更新。
Q&A
Envoy 中 Main 线程和 Worker 线程各自负责什么？
Main 线程负责 xDS 解析与编排、stats 刷新、Admin、进程信号和 hot restart 协调等管理面任务，不承载高并发下游流量。Worker 线程负责每个 listener 上的 accept、实例化 filter 栈以及连接生命周期内的全部 I/O。
Envoy 中连接是如何绑定到 Worker 的？为什么这样设计？
连接在 accept 之后绑定到单个 Worker，终生不迁移。这样设计是为了实现 shared-nothing 并行，同一连接上的 filter、buffer、codec 状态无需与其他 Worker 共享，从而避免跨线程锁竞争，提高热路径性能。
Envoy 的 TLS 机制是如何实现配置快照分发的？
TLS（Thread Local Storage）机制中，Main 线程为每类对象分配一个 slot（全局索引），配置更新时向各 Worker post 闭包，Worker 在本地构建或替换快照。热路径通过 O(1) 槽位查找读取本线程快照，无需全局锁。
Envoy 的 TLS 快照能保证全进程瞬时一致吗？为什么？
不能。因为 post 是异步的，存在新旧快照并存的短暂窗口，所以不保证全进程瞬时一致。xDS ACK 仅表示协议层接受，不等同于流量已切换到新配置。
Envoy 中配置更新是否零成本？为什么？
不是零成本。配置更新时，大对象重建和引用计数释放仍会占用 Worker 时间片，更新风暴时可能抬升延迟，而不是锁竞争造成的假象。
Envoy 的 Watchdog 线程有什么作用？
Watchdog 线程监控 Main/Worker 是否按时响应，长时间不响应会记录 Miss/MegaMiss，严重时可杀进程出 core，作为热路径被阻塞的工程保险丝。
Envoy 扩展作者应如何正确投递任务到其他线程？
扩展作者应使用 Thread::ThreadFactory，通过 runOnAllThreads 或 Dispatcher::post 投递任务，避免直接创建线程绕过线程跟踪。合法的旁路线程池包括 AsyncFile、Cache eviction、GeoIP reload、getaddrinfo DNS 等。
