从单发到 12 并发:sessions_send 高并发不稳定排障记录
本文最后更新于15 天前,其中的信息可能已经过时,如有错误请留言评论。

这次排障的价值,不在于某一条报错本身,而在于它暴露了一个很典型的问题:当一条协作链路在低并发下看起来正常时,并不代表它在更高并发下也同样稳定。

这次我们盯住的对象,是 sessions_send / A2A 并发链路在高并发下的不稳定表现。整个过程里,最重要的一点不是“写了哪些补丁”,而是始终把证据边界划清楚:哪些是已经验证的事实,哪些只是当前最合理的定位判断,哪些内容现在还不能写死。

1. 先从现象说起:高并发下开始出现不稳定

最初确认到的异常,都出现在高并发压力下的协作请求路径上。已经实测出现过的报错包括:

  • gateway closed (1000 normal closure)
  • handshake-timeout
  • closed before connect
  • gateway request timeout for agent

这些报错放在一起看,很容易让人第一反应先怀疑外网、带宽、链路质量或者远端响应能力。但这次后续排查的方向,逐渐把嫌疑收束到了另一侧。

2. 当前定位:主嫌疑不在外网,而在本机建连与等待链路

到目前为止,已经确认的定位结论是:本次高并发不稳定的主嫌疑,锁定在 GatewayClient / callGateway / sessions_send 这一段的并发重复建连与等待链路上。

更具体地说,这次问题更偏向:

  • 本机 gateway websocket 的握手过程
  • 连接管理方式
  • 高并发下的尾延迟放大

也就是说,当前证据更支持“问题主要出在本机连接管理与等待路径”,而不是“外网或带宽不行”。这两个判断的后续修复方向完全不同,所以这里必须写清楚。

3. 已经确认落地的修复方向

本次修复并不是只打了一处补丁,而是分层推进的。

已经确认落地的方向包括:

  1. 第一刀:在 /app/dist/call-Dmp3e_3D.js 增加同目标串行门闸,先压住同目标高并发下的重复打入问题,减少并发建连冲撞;
  2. 第二刀:在同一文件落下共享 GatewayClient / 空闲回收的连接复用骨架,不再每次都走重复建连路径,开始治理连接复用与连接回收问题;
  3. 后续:在 /app/dist/client-CZvPo_yZ.js 落下更深一层的 GatewayClient 重构补丁,并在 gateway 重载后进入运行进程。

这里需要强调的是:这篇记录只写“修复方向”和“已落地层次”,不去虚构未展示的实现细节、代码 diff、指标变化或内部结构图。因为这些在当前证据边界里,都还不该被写成既定事实。

4. 验证怎么做:不是一句“修好了”就算完

这次验证路径本身也很值得记录。因为并发链路问题如果只做一次单发验证,结论往往并不可靠。

这次已确认的验证结果是:

  • 单发:通过
  • 2 并发:通过
  • 4 并发:通过
  • 8 并发:通过

真正有意思的是 12 并发阶段。

第一次按原等待口径跑 12 并发时,出现了 gateway request timeout for agent。如果只看这一步,很容易直接下结论说“高并发修复失败”。但这次没有停在第一眼结论上,因为后续还拿到了迟到回执。

这个细节很关键:它说明当时的问题不一定是“请求彻底没到”,更可能是“等待阈值偏紧,把迟到成功误判成了失败”。

于是,后续做法是:拉长单次等待阈值后重跑 12 并发。调整后结果是:12 路全部拿到回执,整轮通过。

5. 这次能确认什么,不能确认什么

如果把边界划清楚,这次已经可以确认的内容有三类:

  1. 高并发下确实出现过不稳定,且错误类型已经被实测捕获;
  2. 当前主嫌疑更偏向本机 gateway websocket 握手、连接管理和等待链路,而不是外网带宽问题;
  3. 修复后,单发、2 并发、4 并发、8 并发通过,拉长等待阈值后 12 并发也通过,因此本次高并发修复主线已经完成并收口。

但同时,也有一些内容现在不能写死:

  • 不能写具体超时数值;
  • 不能写未展示过的代码 diff;
  • 不能写未确认的内部常量名;
  • 不能写未验证的性能指标;
  • 不能写“彻底根治所有未来并发问题”。

这不是保守,而是技术复盘最基本的纪律:结论要和证据匹配。

6. 收口结论:主线已完成,但复盘价值不止于“修好了”

从验收口径看,这次高并发修复主线已经可以收口。当前仍有个别 agent 回复格式偏差,但这不影响并发链路本身的验收结论。

真正值得记下来的经验,反而是这三点:

  • 高并发问题不要先默认甩锅给外网;
  • 要区分“真正失败”和“迟到成功”;
  • 并发链路的验证不能只做单发,要按单发、2、4、8、12 这种梯度逐级扩容。

一句话结论:这次 sessions_send 高并发不稳定,主嫌疑不在外网,而在本机 gateway websocket 握手、连接管理与等待链路;在串行门闸、连接复用骨架和更深层重构补丁落地后,经过单发到 12 并发的分级验证,本次修复主线已经完成并收口。

文末附加内容
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇