流量控制

引言 在前面的文章中，我们学习了TCP如何建立连接（三次握手）和断开连接（四次挥手）。今天我们来学习TCP如何在连接建立后高效可靠地传输数据：流量控制机制（Flow Control）。 为什么需要流量控制？ 发送方可能发送得很快，接收方可能处理得很慢 如果发送方不控制速度，接收方的缓冲区会溢出，数据丢失 流量控制让接收方告诉发送方：我能接收多少数据 今天我们来理解： ✅ 滑动窗口（Sliding Window）的工作原理 ✅ 接收窗口（rwnd）和发送窗口的关系 ✅ 零窗口问题与窗口探测 ✅ 如何调整TCP窗口大小以提升性能 第一性原理：为什么需要流量控制？ 问题：接收方处理不过来 场景：文件传输 发送方（高性能服务器） 接收方（低性能客户端） | | | 发送1GB数据，速度1Gbps | 接收速度只有100Mbps |----------------------------> | 接收缓冲区64KB | | | 继续疯狂发送... | 缓冲区满了！ |----------------------------> | ❌ 数据丢失 | | 不同场景的速度差异： 场景 发送方 接收方 问题 服务器 → 客户端 10Gbps网卡 100Mbps网卡 速度差100倍 内存 → 磁盘 内存写入50GB/s 磁盘写入500MB/s 速度差100倍 批量导入 10万条/秒 DB只能处理1万条/秒 处理能力差10倍 流量控制的目标：让发送方的速度匹配接收方的处理能力 滑动窗口：TCP流量控制的核心机制 核心思想 接收方告诉发送方：“我还有X字节的缓冲空间，你最多发送X字节” 接收方 发送方 | | | TCP头部：Window=8192 | |<-------------------------| | | 含义： "我的接收缓冲区还有8192字节空间， 你最多发送8192字节" 接收窗口（rwnd） 接收窗口（Receive Window）：接收方在TCP头部的Window字段通告给发送方的值 ...

引言：为什么需要流量控制？ 防止系统过载： Consumer处理速度：100条/秒 消息生产速度：1000条/秒 结果：消息堆积 → 内存溢出 → 系统崩溃 Producer端限流 // 设置发送超时 producer.setSendMsgTimeout(3000); // 异步发送队列大小限制 producer.setMaxMessageSize(4 * 1024 * 1024); // 4MB Consumer端限流 // 1. 限制拉取数量 consumer.setPullBatchSize(32); // 每次最多拉32条 // 2. 限制并发消费线程 consumer.setConsumeThreadMin(20); consumer.setConsumeThreadMax(20); // 3. 限制消费速率 consumer.setPullInterval(100); // 拉取间隔100ms Broker端流控 触发条件： 1. 内存使用超过85% 2. 消息堆积超过阈值 3. PageCache繁忙 流控动作： - 拒绝Producer发送 - 降低Consumer拉取频率 本文关键词：流量控制 限流 背压 系统保护

引言：一张春运火车票背后的技术博弈 每年春节前夕，亿万中国人都会参与一场没有硝烟的战争——春运抢票。 2024年春运首日，12306网站的访问量在开售瞬间达到每秒1400万次。这是什么概念？相当于全国1/100的人在同一秒钟点击同一个网站。如果没有任何保护机制，这样的流量洪峰足以在几秒钟内压垮任何系统。 但12306并没有崩溃。用户虽然排队等待，但系统始终稳定运行，每秒稳定处理数十万笔订单。这背后，就是流量控制的功劳。 今天，我们从这个真实场景出发，深入理解什么是流量控制，为什么需要流量控制，以及流量控制在现代微服务架构中的重要性。 一、现实世界的流量控制：无处不在的智慧 在深入技术细节之前，让我们先看看身边的流量控制案例。你会发现，流量控制是人类应对资源有限性的普遍智慧。 1.1 高速公路收费站：削峰填谷 春节自驾回家，你一定遇到过收费站前的长龙。为什么要设置收费站？除了收费，更重要的作用是流量控制。 入口匝道信号灯：红灯时车辆等待，绿灯时放行，确保主路不拥堵 ETC车道与人工车道：快速通道和慢速通道分离，提高整体通行效率 应急车道管制：拥堵时临时开放，增加通行能力 这些措施的本质是：在有限的道路资源下，控制车流速度，避免拥堵导致整体瘫痪。 1.2 景区限流：保护体验与安全 故宫每天限流8万人，黄山限流5万人。为什么要限流？ 安全因素：超过承载能力会导致踩踏事故 体验保护：人山人海时，游客体验极差 资源保护：过度使用会损坏文物和生态 这里的流量控制策略更加精细： 预约制：提前规划，错峰入园 分时限流：上午下午分别限制人数 动态调整：根据实时人数关闭入口 1.3 电梯承载限制：刚性约束 电梯标注"限乘13人或1000kg"。这是最简单粗暴的流量控制： 硬性限制：超载则无法运行 即时生效：没有等待队列，超载必须减员 安全优先：宁可降低效率，也要保证安全 1.4 共同规律：资源有限，需求无限 仔细观察，这些案例都有三个共同特征： 资源有限：道路宽度、景区容量、电梯承重 需求波动：高峰期需求远超平时 控制策略：通过限制、排队、拒绝等手段保护系统 这就是流量控制的本质：在资源有限的前提下，通过合理的策略，保证系统稳定运行，并尽可能提升整体效率。 二、软件系统为什么需要流量控制 2.1 12306的技术挑战 回到12306抢票场景，让我们分析一下技术挑战： 正常时期（非春运）： 日均访问量：1亿次 峰值QPS：约10万/秒 系统资源：1000台服务器 春运开抢瞬间： 瞬时访问量：每秒1400万次（140倍流量洪峰） 如果不限流：需要14万台服务器（不现实） 实际策略：限流 + 排队 + 分流 2.2 不做流量控制的后果 假设12306不做任何流量控制，会发生什么？ 第1秒：1400万请求涌入 网络带宽打满（假设1Gbps，每个请求1KB，需要11.2Gbps） 服务器CPU飙升到100% 数据库连接池耗尽（配置1000个连接，但有140万个并发请求） 第2秒：系统开始崩溃 大量请求超时，用户疯狂刷新 流量不降反升（重试风暴） 数据库响应时间从10ms变成10秒 第3秒：雪崩效应 数据库连接堆积，内存溢出 服务器宕机，用户看到502错误 整个系统彻底瘫痪 恢复时间：可能需要数小时 清理堆积的请求 重启所有服务 用户信任度严重受损 2.3 流量控制的三大目标 通过12306的案例，我们可以总结出流量控制的三大核心目标： ...