1. 从单机百万连接到分布式网关：高并发架构的演进逻辑
很多刚接触网络编程的朋友会有一个误区，觉得“高并发”就是把epoll用熟、把线程池调大。我在早期做压测时也这么想过，结果单机跑到80万连接之后，内存和CPU的瓶颈立刻暴露出来，再往上加机器，连接分配、状态同步、消息广播又成了新的噩梦。所以这一篇不打算重复讲epoll的API怎么调，而是把视角拉高一层，聊聊当连接数从十万级迈向百万级、甚至需要多机横向扩展时，架构上到底要做哪些取舍。
先明确一个前提：所谓“高并发网络架构”，本质上是在解决三个矛盾——连接规模与单机资源的矛盾、吞吐量与延迟的矛盾、一致性与可用性的矛盾。这三个矛盾贯穿了从Reactor模型选型到分布式网关设计的全过程。你如果只盯着某一个点优化，比如把缓冲区调大，往往会在另一个维度上付出代价。这也是为什么我在实际项目里，从来不会一上来就写代码，而是先把业务的消息模型和连接生命周期画清楚。
这篇文章适合已经写过基础epoll服务器、但一遇到真实生产场景就不知道如何扩展的开发者。我会从单机架构的边界讲起，逐步过渡到多进程、多机网关的设计，中间穿插大量我在压测和线上排查中踩过的坑。所有代码示例都是示意性的，重点在于讲清楚“为什么这么设计”，而不是给你一个能直接编译的完整工程——那种东西网上太多了，但能讲透取舍逻辑的并不多。
2. 单机Reactor的极限在哪里：一次80万连接压测的复盘
2.1 从连接数反推内存与文件描述符预算
在讨论架构之前，先算一笔账。假设你要支撑100万并发连接，每个连接在内核里至少占用一个文件描述符，以及对应的struct sockaddr_in、TCP控制块等内核对象。用户态这边，每个连接通常需要一个读缓冲区和一个写缓冲区。如果每个缓冲区给4KB，那么光缓冲区就是100万 × 8KB = 8GB。这还没算连接对象本身、定时器、业务状态机占用的内存。
我做过一次实测，在一台64GB内存的机器上，把读写缓冲区都压到2KB，连接对象精简到只保留必要字段，最终稳定在80万连接左右，再往上系统就开始频繁触发OOM。这里的关键不是“能不能再优化”，而是你要清楚单机的天花板是由内存带宽和内核调度共同决定的，不是单纯加内存就能线性扩展。
提示：不要迷信“单机百万连接”的宣传数字。那个数字通常是在极简业务逻辑、关闭所有日志、缓冲区调到最小的实验室环境下测出来的。真实业务里，能稳定跑到30万到50万就已经是很不错的成绩了。
2.2 epoll的边缘触发与水平触发在真实流量下的表现差异
epoll的ET（边缘触发）和LT（水平触发）之争，几乎是每个网络编程面试的必问题。但我想说的是，在真实的高并发场景下，这个选择往往不是性能问题，而是代码复杂度问题。
LT模式下，只要缓冲区有数据，epoll_wait就会一直返回，你不需要一次性把数据读完，写代码时心智负担小。ET模式下，你必须循环读到EAGAIN为止，否则残留的数据可能永远不会再触发事件。我在一个消息推送项目里，最初为了追求“少一次系统调用”用了ET，结果因为某个分支忘记处理EAGAIN，导致部分连接的消息延迟了整整十几秒才被处理。排查了两天才定位到。
所以我的建议是：除非你的QPS高到系统调用开销成为瓶颈，否则优先用LT。ET带来的那点性能提升，在大多数业务场景下远不如代码可维护性重要。如果你确实要用ET，务必把“读干净、写干净”封装成统一的函数，并且在代码审查时重点检查。
2.3 多线程Reactor的锁竞争：一个被低估的性能杀手
单Reactor单线程的模型，在连接数上去之后，事件处理会成为瓶颈。于是很多人转向多线程Reactor，也就是主线程负责accept，多个子线程各自持有一个epoll实例处理读写。这个模型本身没问题，问题出在跨线程的任务投递上。
我见过不少实现，子线程之间需要互相发送消息时，直接用一个全局的std::mutex保护一个任务队列。在低并发时看不出问题，一旦QPS上到几万，这个锁就成了热点。perf一看，__lll_lock_wait占了大头。后来我们改成每个子线程一个独立的任务队列，配合无锁队列或者eventfd唤醒，锁竞争才降下来。
这里有个经验：凡是涉及跨线程共享的数据结构，都要先问一句“能不能改成线程私有”。大多数情况下，连接的状态是可以绑定到某个固定线程上的，只要保证同一个连接的所有事件都在同一个线程处理，就不需要锁。这就是所谓的“连接亲和性”。
3. 多进程架构下的连接分配：SO_REUSEPORT到底解决了什么
3.1 惊群问题的历史包袱与内核的演进
早期多进程服务器有个经典问题叫“惊群”：多个进程同时阻塞在accept上，一个新连接到来时，所有进程都被唤醒，但只有一个能成功accept，其余的又回去睡。这个唤醒-竞争-失败的过程白白消耗CPU。
后来内核引入了SO_REUSEPORT，允许多个进程绑定同一个端口，由内核在TCP层做负载均衡，直接把连接分发给某个进程的accept队列。这从根本上避免了惊群，因为每个进程有自己独立的监听队列。我在一个网关项目里把模型从“主进程accept后分发fd”改成SO_REUSEPORT多进程独立accept，吞吐量提升了将近40%，而且代码简单了很多——不再需要进程间传递文件描述符。
但SO_REUSEPORT不是银弹。它的负载均衡是基于四元组哈希的，如果客户端的源端口分布不均匀，可能导致某个进程分到的连接特别多。我遇到过一种情况：某些NAT网关后面的客户端源端口范围很窄，导致哈希倾斜，某个worker进程的连接数是其他进程的三倍。解决办法是在应用层做二次调度，或者接受这种不均衡，因为长连接场景下连接数会逐渐趋于平均。
3.2 进程间共享监听套接字的代价
有些团队为了兼容旧代码，仍然采用“父进程创建监听套接字，fork出多个子进程共享”的模式。这种模式下，所有子进程共享同一个accept队列，内核会唤醒其中一个。虽然现代内核已经优化了惊群，但共享套接字意味着共享内核对象，在高频accept时仍然存在缓存行竞争。
我做过对比测试：同样8个worker，共享监听套接字的模式在新建连接速率上比SO_REUSEPORT低15%到20%。对于短连接为主的业务，这个差距非常明显。所以如果你的内核版本支持（3.9以上），我强烈建议用SO_REUSEPORT。
3.3 连接迁移与优雅重启的工程实现
线上服务免不了要发版重启。对于长连接服务，直接杀掉进程意味着所有连接断开，客户端要重连，这对用户体验和服务器冲击都很大。优雅重启的核心思路是：新老进程并存一段时间，老进程不再接受新连接，但继续服务已有连接，直到连接自然关闭或超时。
用SO_REUSEPORT实现优雅重启相对简单：新进程启动后绑定同一端口，内核会把新连接分给新进程，老进程继续处理存量连接。但这里有个坑：老进程必须停止accept，否则新连接仍可能被它拿到。我们的做法是给老进程发一个信号，让它关闭监听套接字，只保留已建立连接的读写事件。等存量连接数降到阈值以下，再退出。
这个过程中，如果业务是有状态的，还需要考虑会话的迁移。我们的做法比较粗暴但有效：对于必须保持状态的连接，在老进程退出前主动通知客户端重连到新进程，客户端配合做一次平滑切换。虽然不够优雅，但实现简单，出错概率低。
4. 分布式网关的核心难题：连接状态与消息路由
4.1 有状态网关与无状态网关的选型依据
单机架构再优化也有上限，当连接数超过单机承载能力时，就必须引入多台网关做分布式。这时候第一个要回答的问题是：网关是有状态的还是无状态的？
有状态网关自己维护连接和会话，消息路由需要知道某个用户连在哪台网关上。无状态网关则不保存会话，每个请求都携带完整上下文，或者依赖外部存储。两者的取舍很明确：有状态网关延迟低、吞吐高，但扩缩容和故障恢复复杂；无状态网关弹性好，但每次请求都要查外部存储，延迟和成本都上去了。
我的经验是：IM、推送、游戏这类长连接场景，几乎必然选择有状态网关，因为连接本身就是状态，你没法把它变成无状态的。而HTTP API网关这类短连接场景，无状态更合适。选型错了，后面怎么优化都别扭。
4.2 会话路由表的设计：从集中式到分片式
有状态网关需要一个“路由表”来记录用户和网关的映射关系。最简单的是集中式存储，比如用一个Redis集群存user_id -> gateway_id。但这里有个致命问题：每次消息投递都要查一次路由表，QPS一高，这个存储就成了瓶颈。
我们的做法是分片式路由：网关集群内部维护一个一致性哈希环，每个网关负责一部分用户的连接。当需要给某个用户发消息时，先对user_id做哈希，找到负责的网关，再转发过去。这样路由计算在本地完成，不需要查外部存储。只有网关扩缩容时，才需要迁移部分连接。
但一致性哈希也有代价：扩缩容时会有部分连接需要迁移，迁移过程中消息可能丢失或重复。我们的补偿机制是：迁移期间，旧网关把消息转发给新网关，同时客户端做一次重连。虽然复杂，但保证了消息不丢。
4.3 跨网关消息投递的可靠性与顺序性
跨网关投递消息时，最头疼的是顺序性。同一个发送者连续发的两条消息，如果经过不同的网络路径到达接收者所在的网关，可能后发的先到。对于聊天场景，这会导致消息乱序，用户体验很差。
我们的解决方案是：在发送端做序列号，接收端做重排。每条消息带一个单调递增的序列号，接收网关维护一个滑动窗口，按序列号顺序投递给客户端。如果发现缺口，就等待或向发送方请求重传。这个机制增加了复杂度，但对于需要严格顺序的业务是必须的。
另一个问题是可靠性。跨网关投递如果失败，消息就丢了。我们采用“至少一次”语义：发送方持久化消息，接收方确认后才删除。如果超时未确认，就重试。客户端侧做去重，保证即使收到重复消息也不会重复展示。
5. 内存管理与零拷贝：高并发下的数据搬运优化
5.1 从read/write到sendfile：减少数据拷贝的实战收益
传统的网络发送流程是：磁盘文件 -> 内核页缓存 -> 用户缓冲区 -> 内核socket缓冲区 -> 网卡。四次拷贝，两次系统调用。对于静态文件服务，sendfile可以把中间的用户缓冲区拷贝省掉，变成三次拷贝。如果网卡支持SG-DMA，还能进一步省掉内核内部的拷贝。
我在一个文件分发服务里把read+write改成sendfile，CPU占用直接降了30%，吞吐量提升了近一倍。但sendfile不是万能的：它只能用于文件到socket的传输，如果你需要在发送前修改数据，就用不了。而且它和TLS配合时比较麻烦，因为加密需要用户态参与。
5.2 用户态协议栈的适用边界
近几年用户态协议栈很火，核心思路是把网络协议处理从内核搬到用户态，绕过内核协议栈的开销。理论上能大幅降低延迟、提高吞吐。但我在实际评估后发现，用户态协议栈的适用场景非常窄。
它适合的是：专用硬件、固定流量模型、团队有很强的底层调优能力。对于大多数业务团队，引入用户态协议栈意味着要自己处理ARP、IP分片、TCP重传、拥塞控制等一系列问题，维护成本极高。而且一旦出问题，排查难度远超内核协议栈。我的建议是：除非你的业务对延迟极度敏感且流量模型非常固定，否则不要轻易上用户态协议栈。把内核参数调优、把应用层逻辑写高效，收益已经足够。
5.3 内存池与对象复用的坑：什么时候不该用内存池
内存池是减少malloc/free开销的常用手段。在高并发场景下，频繁分配释放小对象确实会导致内存碎片和锁竞争。但内存池不是没有代价的：它会掩盖内存泄漏，增加内存占用，并且在多线程下需要精细的线程本地缓存设计。
我踩过一个坑：在一个连接对象池里，对象被回收后没有完全重置状态，导致下一个复用的连接继承了上一个连接的残留数据，出现了串消息的严重bug。后来我们规定：凡是进入内存池的对象，必须在回收时调用统一的reset()，并且用断言检查关键字段。这个教训让我明白，内存池带来的性能收益，必须用严格的代码规范来兜底。
另外，对于生命周期长、大小不固定的对象，内存池反而可能降低性能，因为池的碎片整理成本可能高于直接分配。判断标准很简单：如果对象的分配频率远高于其生命周期，且大小固定，才考虑内存池。
6. 压测与线上排查：那些文档里不会写的经验
6.1 压测工具的选择与流量模型的真实性
压测工具我用过不少，从ab到wrk再到自己写的分布式压测框架。最大的体会是：压测结果的真实性取决于流量模型，而不是工具本身。你用wrk打一个返回"hello world"的接口，测出来的QPS再高，也不能说明你的业务能扛住。
真实的流量模型要考虑：连接建立频率、消息大小分布、读写比例、客户端行为（比如是否有思考时间）。我在一个推送项目里，最初用固定大小的消息压测，结果很漂亮。上线后真实消息大小波动很大，大消息导致缓冲区频繁扩容，性能直接腰斩。后来我们在压测里引入了真实的消息大小分布，才暴露出问题。
注意：压测时一定要监控服务端的CPU、内存、网络带宽、文件描述符数量。很多时候瓶颈不在你的代码，而在系统配置。比如
ulimit -n没调，连接数一上去就报EMFILE。
6.2 用perf和eBPF定位锁竞争与系统调用热点
线上性能问题，十有八九出在锁竞争和系统调用上。perf top能快速看出CPU花在哪些函数上。如果看到__lll_lock_wait、futex占比高，基本就是锁的问题。这时候用perf record抓一段火焰图，就能定位到具体的锁。
eBPF更强大，可以动态追踪内核和用户态函数，而且开销小。我常用bpftrace写一些单行脚本，比如统计某个系统调用的延迟分布、追踪某个函数的调用次数。有一次线上出现偶发的延迟毛刺，用bpftrace追踪sendto的延迟，发现是某个网卡的队列满了导致排队。这种问题用传统工具很难定位。
6.3 连接泄漏的常见根因与排查路径
连接泄漏是高并发服务里最隐蔽的问题之一。表现是：连接数缓慢上涨，最终耗尽文件描述符。常见根因有几个：异常路径没有关闭连接、超时连接没有被清理、引用计数错误导致对象无法释放。
排查路径我一般这样走：先看/proc/<pid>/fd的数量变化趋势，确认是泄漏还是正常波动。然后用ss -s看TCP连接状态分布，如果CLOSE_WAIT很多，说明是被动关闭后没有主动close。接着在代码里搜索所有accept和connect的地方，检查是否每个分支都有对应的close。最后用RAII封装连接对象，让析构函数负责关闭，从机制上避免遗漏。
我印象最深的一次泄漏，是因为一个shared_ptr的循环引用，导致连接对象永远无法析构。用valgrind跑了一晚上才定位到。从那以后，我在设计连接对象时，尽量用weak_ptr打破循环，或者干脆用裸指针加明确的生命周期管理。
7. 架构选型的个人体会
写了这么多，其实核心就一句话：高并发网络架构没有银弹，所有的选择都是在特定约束下的权衡。单机epoll能解决的问题，不要上分布式；SO_REUSEPORT能解决的负载均衡，不要自己写调度器；内存池能带来的性能提升，要用代码规范来兜底。
我在实际项目里最看重的不是某个技术有多先进，而是整个系统的可观测性和可维护性。一个跑得快但出了问题查不到原因的系统，比一个跑得稍慢但处处有日志、有指标的系统危险得多。所以无论架构怎么演进，我都会确保每个关键路径有埋点、每个异常有日志、每个决策有文档。
最后分享一个小技巧：在设计阶段，拿一张纸画出消息从客户端到服务端再返回的完整路径，标出每一次拷贝、每一次加锁、每一次系统调用。你会发现很多优化点，也会发现很多不必要的复杂度。这个习惯帮我避免了好几次过度设计。
