2. 并发模型选型：多线程 vs 多进程 vs 协程，在QUIC场景下的优劣分析

聊到QUIC服务的并发模型，我见过不少团队一上来就拍脑袋选型。有人觉得多进程稳，有人迷信协程快。说实话，QUIC这玩意儿跟传统的TCP不太一样——它自带多路复用、连接迁移、0-RTT这些特性，选错了并发模型，后面优化起来会非常痛苦。

今天我就结合自己踩过的坑，把三种模型在QUIC场景下的表现掰开揉碎讲清楚。

2.1 三种模型的核心差异

先看一张对比表，心里有个底：

维度	多进程	多线程	协程
资源开销	高（独立地址空间）	中（共享地址空间）	低（用户态调度）
上下文切换	内核态，开销大	内核态，中等	用户态，纳秒级
内存隔离	强（进程隔离）	弱（共享内存）	弱（共享内存）
连接迁移支持	困难（需IPC）	中等（需锁）	自然（单线程内）
多核利用率	高（天然分布）	高（需锁优化）	低（单核密集）
编程复杂度	高（IPC、共享状态）	中（锁、竞态）	低（同步写法）

嗯，这张表基本能看出大方向。但QUIC场景下，有些细节会被放大，咱们一个一个说。

2.2 多进程：隔离性好，但连接迁移是噩梦

多进程模型在传统网络服务里很常见——Nginx就是典型。每个Worker进程独立处理连接，互不干扰。好处很明显：一个进程挂了，其他进程照常服务，内存泄漏也不会扩散。

但QUIC有个要命的东西叫连接迁移。客户端换个网络（比如从WiFi切到4G），Connection ID不变，但IP变了。如果这个连接之前绑定在进程A上，迁移后的包被负载均衡扔到了进程B……

我曾经踩过这个坑：线上QUIC网关用多进程+一致性哈希做连接绑定。结果用户在地铁里过隧道，WiFi切4G，连接迁移后哈希到另一个进程，握手状态全丢了。客户端只能重建连接，0-RTT的优势直接报废。

解决方案也不是没有——共享内存存连接状态，或者用内核旁路技术（比如DPDK）做进程间连接迁移。但实现复杂度直线上升，我个人不太推荐在QUIC场景下硬上多进程。

2.3 多线程：折中方案，但锁竞争要命

多线程模型在QUIC里比多进程友好一些。所有线程共享进程地址空间，连接状态可以直接用指针访问，不需要IPC。配合SO_REUSEPORT，多个线程可以同时监听同一个端口，内核做负载均衡。

但问题出在锁上。QUIC的每个连接内部有多个Stream，Stream之间需要协调流量控制和数据排序。如果多个线程同时操作同一个连接的不同Stream，锁竞争会非常激烈。

// 伪代码：多线程下QUIC连接的锁竞争
void on_stream_data(quic_conn *conn, stream_id sid, uint8_t *data) {
    pthread_mutex_lock(&conn->lock);  // 全局锁
    // 更新流量控制窗口
    // 排序数据包
    // 触发ACK
    pthread_mutex_unlock(&conn->lock);
}

你想想看，一个QUIC连接里可能同时跑几十个Stream，每个Stream的数据到达都要抢这把锁。我在项目里实测过，8核机器上锁竞争能把吞吐吃掉30%以上。

我的建议：如果非要用多线程，可以考虑连接级分片——每个线程绑定一组连接，连接内的Stream操作不跨线程。这样锁粒度从连接级降到线程级，基本无竞争。

2.4 协程：QUIC的天然搭档

聊到协程，我得说——这玩意儿跟QUIC简直是天作之合。为什么？

QUIC是多路复用的：一个连接里多个Stream，协程可以每个Stream一个协程，写法跟同步代码一样。
QUIC是异步的：数据包乱序到达、ACK延迟、Ping超时……这些异步事件用协程处理，比回调地狱舒服太多了。
上下文切换极快：QUIC连接数动辄几十万，如果用线程，光切换就能把CPU吃满。协程切换是用户态的，纳秒级，完全扛得住。

我习惯用C++20的co_await来写QUIC服务，大概长这样：

// 协程处理QUIC Stream
quic_task handle_stream(quic_conn conn, stream_id sid) {
    auto stream = co_await conn.accept_stream(sid);
    while (true) {
        auto data = co_await stream.read();
        if (data.empty()) break;
        auto result = co_await process_data(data);
        co_await stream.write(result);
    }
}

你看，没有回调，没有状态机，就是顺序写下来。每个Stream一个协程，几万个协程在一个线程里跑，调度开销几乎可以忽略。

但要注意：协程模型有个硬伤——单线程内的协程无法利用多核。如果CPU密集型操作（比如TLS加解密）占用了协程，整个线程的协程都得等。

解决方案是协程+工作线程池。协程负责I/O和调度，CPU密集操作扔给线程池。这样既享受了协程的轻量，又不浪费多核。

2.5 我的选型建议

说了这么多，直接给结论：

纯I/O密集型QUIC网关（比如代理、负载均衡）：无脑选协程。单线程+协程+异步I/O，几十万连接轻松扛。
计算密集型QUIC服务（比如视频转码、实时处理）：选多线程+协程混合。I/O部分用协程，计算部分扔线程池。
需要强隔离的场景（比如多租户、安全敏感）：选多进程，但要做好连接迁移方案。我个人不太推荐，除非你团队有内核开发能力。

下面这张图是我在项目中实际使用的架构，你可以参考：

2.6 避坑指南

最后分享几个我实战中遇到的坑：

我曾经犯过的错：

协程里做阻塞I/O：有一次在协程里调了read()从磁盘读文件，结果整个线程的协程全卡住了。记住，协程里只能用异步I/O。
忽略协程栈大小：默认协程栈只有几KB，QUIC的TLS握手状态机稍微复杂点就栈溢出了。我后来统一设了64KB栈，才稳定下来。
多线程+协程混用时的线程安全：协程在A线程挂起，被B线程恢复，如果共享数据没加锁，数据竞争会让你怀疑人生。建议用thread_local或者显式传递上下文。

说白了，没有银弹。选型要看你的业务场景——连接数、计算量、隔离需求，这三个维度定下来，模型基本就定了。我个人习惯是：默认协程，遇到瓶颈再加线程。这样起步快，后期也有优化空间。

📚 课程目录

2. 并发模型选型：多线程 vs 多进程 vs 协程，在QUIC场景下的优劣分析

2.1 三种模型的核心差异

2.2 多进程：隔离性好，但连接迁移是噩梦

2.3 多线程：折中方案，但锁竞争要命

2.4 协程：QUIC的天然搭档

2.5 我的选型建议

2.6 避坑指南