Skip to content

fix:高并发下503窗口关闭问题#145

Open
nekohy wants to merge 3 commits into
iBUHub:mainfrom
nekohy:main
Open

fix:高并发下503窗口关闭问题#145
nekohy wants to merge 3 commits into
iBUHub:mainfrom
nekohy:main

Conversation

@nekohy
Copy link
Copy Markdown

@nekohy nekohy commented Apr 30, 2026

No description provided.

@bbbugg bbbugg self-assigned this Apr 30, 2026
@bbbugg bbbugg added the 🐛 Bug Something isn't working label Apr 30, 2026
@bbbugg
Copy link
Copy Markdown
Member

bbbugg commented May 2, 2026

感谢大佬的pr。

完全等待队列结束才关闭旧账号,这样会导致活跃 context 超过 MAX_CONTEXTS 的情况,对于 VPS 或者云容器来说,短时间内存会过高有风险。

我倾向于把原则改成:允许旧请求尽量自然结束,但不能为了等旧请求而阻塞当前账号切换,也不能让活跃 context 数量突破 MAX_CONTEXTS

也就是说,pending close 可以存在,但它不应该变成“额外保留一个 context”。它应该只是一个后台等待关闭状态:如果这个 context 还有未完成队列,就先标记为 pending,等队列完成后自动关;但一旦新账号切换需要占用新加 context 名额,而当前活跃 context 已经达到 MAX_CONTEXTS,就必须强制关闭一个旧 context。

强制关闭的选择规则可以是:

从当前活跃 context 中选择最早创建的一个关闭
或者更准确地说:
按照自动切换顺序里,活跃 context 中最早被创建/最旧的那个关闭

这样保证两个目标:

1. 新账号切换永远优先
2. context 总数永远不超过 MAX_CONTEXTS

代价是:被强制关闭的 context 上如果还有未完成请求,这些请求会失败或中断。但这个代价是 MAX_CONTEXTS 语义本身带来的,尤其在 MAX_CONTEXTS 很小的时候无法完全避免。
比如 MAX_CONTEXTS =1,就是无论如何都会强行关闭旧的,对于 2、3 情况会好一些,但是仍有强行关闭的风险(比如有长时间请求、连续切换账号时间比较短),对于 MAX_CONTEXTS 再大的情况,就不会有什么影响了,除非短时间频繁切换账号。

@bbbugg
Copy link
Copy Markdown
Member

bbbugg commented May 5, 2026

我来改吧,超时那个感觉没必要,很多配置低的机器,登录一次要2分钟。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🐛 Bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants