知识卡片

基于UDP自研可靠传输协议:应对TCP在超大规模连接数场景下的扩展性瓶颈

普通读书笔记卡

内容

HAWQ的高速互联网络负责在众多节点之间交换查询执行过程中产生的大量数据,团队在这一层做出了一个反直觉的选择——基于UDP而不是更常见、更成熟的TCP来自研这套传输协议。这个选择的动机来自一个具体的规模问题:假设集群有1000个节点,每个节点上运行1000个执行器进程,这些进程之间需要两两交互,会产生高达百万量级的连接数——TCP协议本身在这种超大规模连接数的场景下,没有办法高效地支撑,连接建立、维护本身的开销会随着连接数量的增长而变得难以承受。既然基础的TCP传输协议做不到这个规模要求,HAWQ团队选择转向UDP、但同时要自己在UDP之上重新实现TCP原本免费提供的那些可靠性保证:可靠性(保证丢包时能重传丢失的数据包)、有序性(保证数据包最终能按正确顺序传递给接收方)、流量控制(避免发送方速度过快、淹没接收方,进而导致整体网络性能急剧下降)、以及性能和可扩展性(这正是放弃TCP的初衷)。这个案例给出了一条技术选型的重要思路:面对一个成熟协议(TCP)在某个具体极端场景(海量连接数)下暴露出的根本性扩展瓶颈,如果这个瓶颈已经触及协议本身的设计极限(而不是可以通过调参数、加机器就能绕开的普通性能问题),有时候值得考虑退回到一个更底层、约束更少的协议(UDP),在这个更底层的基础上,只针对自己真正需要的那几项可靠性特性去重新实现,而不是继续在原有的成熟协议上打补丁——这个决策的代价是要自己承担起原本由TCP免费提供的复杂性(重传、有序、流控这些机制都要自己设计和维护),只有当原有协议的瓶颈确实无法绕开、且自己的团队有能力承担这份额外的实现复杂度时,这条路径才是值得走的。

参考来源

- 位置:《高可用架构(第1卷)》第6章《大数据与数据库》"6.5 解密Apache HAWQ——功能强大的SQL-on-Hadoop引擎"节,"6.5.2 Apache HAWQ系统架构"(源文件:_epub-src/OEBPS/Text/Chapter6_5_3.xhtml) - 结论依据:原文说明"假设每个节点上有1000个进程。有1000个节点,这些进程需要相互交互,每个节点上就会有上百万个连接。TCP是没办法高效地支持这么多的连接数的。所以我们开发了基于UDP的互联协议……我们的设计目标需要保持以下特性:可靠性……有序性……流量控制……性能和可扩展性",直接支撑本卡片结论。 - 原始内容:有1000个节点,这些进程需要相互交互,每个节点上就会有上百万个连接。TCP是没办法高效地支持这么多的连接数的。所以我们开发了基于UDP的互联协议。操作系统不能保证UDP传输的可靠性,并且不能保证它是有序传递的。我们的设计目标需要保持以下特性:可靠性……有序性……流量控制……性能和可扩展性。