第4章 网络编程与Socket：epoll、Reactor模式、TCP粘包、低延迟通信
本章是交易系统研发面试的核心硬核章节，覆盖高性能网络编程四大高频考点：epoll事件驱动、Reactor多线程模型、TCP粘包拆包策略以及低延迟通信优化技巧。面试官会从原理→实现→实际业务落地三层递进提问，考察候选人是否具备构建低延迟、高吞吐交易通道的能力。
知识点速查表：epoll vs Reactor vs 粘包处理
| 维度 | epoll | Reactor模式 | TCP粘包处理 |
|---|---|---|---|
| 核心思想 | 事件驱动，O(1)复杂度 | 事件分发 + 多线程处理 | 消息定界：长度/分隔符/定长 |
| 常见问题 | ET模式下必须非阻塞读 | 主从Reactor如何分工 | 半包/粘包同时出现 |
| 交易场景应用 | 行情网关 + 订单网关 | 撮合引擎事件循环 | FIX/SBE协议长度域 |
| 面试加分点 | 区别select/poll，红黑树细节 | 对比Proactor，避免惊群 | Netty ByteBuf 实现 |
面试问答卡片
Q1: 请详细解释epoll的两种触发模式（LT和ET），你在项目中如何选择？
- 考察点：对epoll底层机制的理解、工程经验、非阻塞编程意识。
- 回答框架：① 定义LT/ET → ② 区别（通知次数、数据读取完整性） → ③ 工程选择依据（使用ET需配合非阻塞+循环读，否则可能漏事件；LT简单但可能有重复唤醒） → ④ 交易场景举例。
- 示例回答：“LT是水平触发，未读完会持续通知，适合简单场景；ET是边缘触发，只在状态变化时通知一次，性能更高但需用非阻塞IO循环读完。在交易网关中我选择ET+非阻塞读+固定接收buffer，减少无用系统调用，同时用epoll_wait超时兜底防止漏数据。”
- 可能追问：“如果ET模式下读不完整会发生什么？” “请实现一个ET驱动的回调逻辑”。
- ⚠ 避坑：不要只说LT比ET好或差，要给出取舍理由；忘记提非阻塞IO是ET致命错误。
Q2: 简述Reactor模式在交易系统中的应用，主从Reactor如何避免惊群效应？
- 考察点：多线程Reactor设计能力、惊群问题认识、实际工程优化。
- 回答框架：① Reactor核心：事件循环+Handler → ② 主Reactor负责accept，从Reactor负责IO读写 → ③ 惊群原因：多个线程同时监听相同fd → ④ 解决方案：独占套接字、SO_REUSEPORT、epoll mutex或使用locks。
- 示例回答：“交易系统常用主从Reactor：主Reactor只负责accept新连接，分发给从Reactor；每个从Reactor拥有独立epoll fd。避免惊群采用两个措施：主Reactor单线程accept；从Reactor使用SO_REUSEPORT让内核负载均衡，或加互斥锁保证同一时刻只有一个线程通知。”
- 可能追问：“如果去掉主Reactor，只用多线程epoll怎么改造？” “Reactor和Proactor模式对比”。
- ⚠ 避坑：不要混淆惊群与死锁；避免只背概念，要结合交易高并发场景说明。
Q3: TCP粘包如何产生？在低延迟交易协议中你常用哪种方式解决？
- 考察点：TCP流式本质理解、协议设计能力、低延迟场景下的取舍。
- 回答框架：① 粘包原因：Nagle算法、发送方合并、接收方读缓冲区滞留 → ② 解决方式：固定长度、分隔符、长度域（TLV） → ③ 低延迟交易推荐使用固定长度+长度域混合，避免分隔符解析开销 → ④ 处理半包：积累到足够数据再解析。
- 示例回答：“交易系统使用自定义协议：前4字节为消息总长（小端），后跟固定格式消息体。接收端预读4字节获取长度，再读完整payload。这种方式开销极低，无需分隔符逐字节匹配，同时支持变长。为防粘包，缓冲区不足时暂存，等待下一个事件触发后再拼接。”
- 可能追问：“如果收到的长度字段被截断怎么办？” “Netty中如何解决粘包（LengthFieldBasedFrameDecoder）”。
- ⚠ 避坑：不要只说“加分隔符即可”，要考虑性能；避免忽略半包场景。
项目案例模板
| 项目名称 | 低延迟证券行情网关（Level-2 快照 + 逐笔成交） |
| 业务背景 | 交易所推送全市场行情，要求网关在10微秒内完成解码、过滤、分发给内部策略系统。 |
| 规模指标 | 并发连接200+，每日处理消息量5000万+，P99延迟≤15μs，吞吐量800Mbps。 |
| 技术栈 | C++17 · epoll (ET) · 主从Reactor · 无锁环形队列 · 共享内存 · SBE/简单二进制编码 |
| 核心难点 | ① 粘包拆包：交易所协议不保证消息边界，且偶发多消息合并；② 惊群：多线程Reactor下连接分发竞争；③ 零拷贝：避免内存复制，使用mmap + 指针直接解析。 |
| 面试高频追问 | “你们如何保证半包时不丢数据？”（答案：每个连接维护接收buffer + 偏移指针） “为什么没用select/poll？”（性能差距：O(n) vs O(1)） “若行情爆发导致缓冲区满如何处理？”（水位控制+丢弃策略+告警） |
| 可迁移回答话术 | “在低延迟场景中，每一微秒都影响策略盈亏。我们选用epoll ET模式 + 专用接收线程，避免锁竞争；协议层采用4字节长度前缀，利用memcpy一次拷贝进结构体；内存预分配环形池，无回收停顿。” |
大厂模拟面试
面试官提问
“假设我们需要设计一个高频交易撮合引擎的底层网络层，要求支持万级订单每秒，延迟低于50微秒。你会选择哪种IO模型？如何解决粘包问题？请给一个完整的技术方案。”
候选人回答（普通答案）
“我会用epoll，边缘触发模式。粘包就采用长度字段，前面4字节写长度，然后读固定字节。多线程就用Reactor模式，一个线程accept，其他线程负责读写。这样应该能满足需求。”
优秀答案
“选用epoll ET+非阻塞IO，每个CPU绑定一个Reactor线程，使用SO_REUSEPORT多队列分发避免锁。协议层采用固定头部+变长payload：前8字节包含消息类型和长度，接收端用预分配内存池直接解析。粘包通过积累到预期长度再回调业务逻辑处理。再通过无锁队列异步化输出订单结果，将请求路径上的上下文切换降至最低。”
专家答案
“我选择纯用户态协议栈+DPDK，但面试若限制内核方案则选epoll ET + 独立接收线程池 + 共享内存。具体：每个线程绑定独立CPU，接收线程使用mmap缓冲区，直接轮询epoll fd；粘包用前置长度+固定元数据，解析后通过自旋锁或无锁队列发给处理线程；同时开启TCP_NODELAY关闭Nagle，使小报文及时发送。为消除对象构造开销，使用对象池+预分配，配合SO_RCVBUF调大内核缓冲避免丢包。全链路延迟可控制在20μs以内。”
面试官追问
“如果某个连接的接收线程因为解包异常导致阻塞，如何处理？”（考察：隔离和监护机制）
“你提到无锁队列，具体用哪种实现？ABA问题怎么解决？”（考察：无锁数据结构细节）
📘 复习要点
▸ epoll ET时必须搭配非阻塞IO循环读取，否则丢失数据。
▸ Reactor多线程中SO_REUSEPORT及epoll mutex是避免惊群的关键。
▸ 长度域+固定头部是低延迟交易协议首选粘包方案，慎用分隔符。
▸ 说出“零拷贝”、“内存池”、“无锁队列”等关键词时，必须能阐述具体实现逻辑，否则会被当作背概念。