WebSockets on 张欣耕的个人博客

ASGI到底是什么?从一头雾水到豁然开朗的理解之旅

Tue, 04 Nov 2025 00:00:00 GMT

scope的隐身术: 让人抓狂的神秘变量

故事要从我开发一个需要实时推送数据的小功能说起。没啥花头, 就是想服务器一有新消息, 客户端立马能收得到。于是我自然而然地用上了FastAPI, 结果一头扎进文档, 发现满篇都是scope。

没错, 就是这个scope。看文档到哪都能看到它的影子, 教程代码里有它, Stack Overflow的解答也是默契地假设你已经会用它了。但最让我抓狂的是: **我在自己的代码里根本没看到过它的踪影!**路由, WebSocket端点, 统统没露面。scope去哪了?难道是传说中的”空气变量”?

更离谱的是, receive和send也差不多, 大家都在谈, 一到自己写代码就消失了。AI助手讲解得头头是道, 但我死活没法把这些虚空中的参数和自己写的Litestar, Advanced Alchemy代码联系起来。

这时候我才幡然醒悟: 原来我一直在学各种框架, 却从没搞懂这些框架的地基是什么。只有”刨地三尺”, 搞懂Python异步Web服务器最底层的原理, 才能明白这些玄学参数到底干嘛用的——不是FastAPI的套路, 也不是Django Channels的玩法, 而是底层协议的真相。

于是, 这就是我的ASGI探险记。如果你也曾经对ASGI, WebSocket一头雾水, 觉得Python异步Web开发跟传统Flask/Django完全不是一个画风, 这篇文章就是为你写的。读完你就能明白ASGI到底是什么, 它为啥存在, 以及它如何优雅统一了HTTP, SSE, WebSocket等各种通信方式。

第一重顿悟: ASGI其实就是个”君子协定”

最让我拍案叫绝的发现是: ASGI不是框架, 也不是库, 而是一个规范——规定了Web服务器如何跟你的Python应用对话。

就像电源插座一样, 国家标准一出, 不管是小米还是海尔, 都能造出插得上的电器。ASGI也是一样, 定义了Web服务器和异步Python应用之间的”对接协议”。

整个协议简单到极致, 只有三个参数:

async def app(scope, receive, send):
    # 应用逻辑

就是这么朴实无华。无论你用FastAPI, Starlette, Django Channels, 还是自己手撸, 从本质上看, ASGI应用就是一个可调用对象, 接收这三个参数:

scope: 一个字典, 包含了连接的元信息。可以理解为”场景说明书”, 告诉你这是啥连接, 谁发起的, 要干啥。
receive: 一个异步函数, 你调用它能收到客户端发来的消息。就像查邮箱收信。
send: 另一个异步函数, 用它给客户端发消息。等于往邮箱里塞信寄出去。

更妙的是, 这套”三件套”通吃所有场景——普通HTTP, 流式Server-Sent Events, 双向WebSocket, 甚至连应用的启动和关闭都能用这一套。只要scope说明了”这次玩哪种花样”, 你就能对症下药。

不过刚开始让我迷糊的是——“会话”到底指啥?一次请求?一场对话?服务器的整个寿命?

答案其实很灵性: **得看scope的type。**接下来, 咱们一个个举例聊聊。

HTTP: 简单明了的一次性买卖

先从最熟悉的HTTP说起。你可能早就用惯了, 但不一定知道ASGI在背后默默打工。

当有客户端发起HTTP请求时, ASGI会生成一个scope, 大致长这样:

{
    "type": "http",
    "method": "GET",
    "path": "/api/users/123",
    "headers": [...],
    "query_string": b"format=json",
    "client": ("192.168.1.5", 54321),
    "server": ("10.0.0.1", 8000),
}

注意type: "http", 这就是告诉你, 这是一锤子买卖, 请求-响应搞定即走。

流程如下:

客户端发请求 → 服务器生成scope并调用你的app
你的应用用receive()收请求体 (可能是分段的)
用send()发响应头 (状态, 头信息)
再用send()发响应体 (具体内容)
scope消失, 连接结束

这就像自动贩卖机: 你投币, 选饮料, 拿饮料, 完事走人。贩卖机根本不记得你是谁。

重点: HTTP在ASGI里是无状态的。每次请求独立, scope活不了一秒, 处理完就销毁。

举个响应例子:

# 先发响应头
await send({
    "type": "http.response.start",
    "status": 200,
    "headers": [[b"content-type", b"application/json"]],
})

# 再发响应体
await send({
    "type": "http.response.body",
    "body": b'{"user": "Shane", "id": 123}',
})

短平快, 简单明了。这是最基础的模式。

Server-Sent Events: 服务器单向直播

如果说HTTP是买瓶饮料就走, Server-Sent Events (SSE) 则像是你在贩卖机旁边蹲着, 机器一上新立马通知你。

SSE本质上还是HTTP, 但不再遵循一次性请求-响应的老路, 而是:

客户端发起HTTP请求
服务器回响应头 (记得加Content-Type: text/event-stream)
连接保持不断开
服务器随时发送数据
直到有一方主动断开

scope依旧是type: "http", 但玩法变了。你就像打电话点了”今日特价”, 电话那边不停播报新菜品上架。

例子:

await send({
    "type": "http.response.start",
    "status": 200,
    "headers": [[b"content-type", b"text/event-stream"]],
})

# 持续推送
await send({
    "type": "http.response.body",
    "body": b"data: {\"new_order\": 42}\n\n",
    "more_body": True,
})

await send({
    "type": "http.response.body",
    "body": b"data: {\"new_order\": 43}\n\n",
    "more_body": True,
})

注意more_body: True, 意思就是”别断, 还会有!”

SSE还是HTTP, 只是持久化了连接, 单向推送。客户端啥都不回, 只是一直听。

适合场景:

实时仪表盘
通知推送
股票行情
进度更新
只需单向推送, 不需要客户端反馈

比WebSocket简单, 功能比普通HTTP强。

WebSocket: 双向持久对话

轮到WebSocket出场, ASGI的奥义也就此揭晓。

WebSocket跟HTTP/SSE都不一样, 因为它是双向, 持久, 状态化的。不是你一句我一句的买卖, 而是持续的对话, 谁都可以主动说话。

如果HTTP像写信, SSE像广播, WebSocket就是打电话。

scope结构:

{
    "type": "websocket",
    "path": "/ws/chat/room-42",
    "headers": [...],
    "query_string": b"user=shane",
    "client": ("192.168.1.5", 54322),
    "server": ("10.0.0.1", 8000),
}

type: "websocket", 完全不同的玩法。

消息类型:

客户端到应用:

{"type": "websocket.connect"}       # 客户端请求建立连接
{"type": "websocket.receive", "text": "Hello!"}  # 客户端发消息
{"type": "websocket.disconnect"}    # 客户端断开

应用到客户端:

{"type": "websocket.accept"}        # 应用同意连接
{"type": "websocket.send", "text": "Welcome!"}   # 应用发消息
{"type": "websocket.close"}         # 应用断开

有木有发现, HTTP是你问我答, WebSocket是持续在线, 谁都能随时插话。

scope也能活很久, 可能几秒, 也可能几小时。你可以在一个scope里互发上百条消息, 状态一直保留着。

适合场景:

聊天应用
协同编辑 (比如在线文档)
在线游戏
实时推送
需要真·双向实时通信的场景

但这里还有个经典疑问……

WebSocket握手的迷思: 升级的秘密

初学时我被”WebSocket升级”整蒙了: WebSocket不是HTTP, 怎么开始的?

答案让人大跌眼镜: WebSocket一开始就是个HTTP请求。

啥?不信?往下看。

WebSocket的设计就是要兼容原有Web基础设施 (端口, 代理, SSL等), 所以不是重新发明协议, 而是走”先HTTP, 后升级”的套路。

流程:

1. 客户端发特殊HTTP请求:

GET /ws/chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: X3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13

就是普通GET, 只是加了些特殊头, 表示”我要升级成WebSocket”。

2. 服务器回101响应:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <computed response>

101 Switching Protocols就是同意升级, 从此用WebSocket协议交流。

3. 协议切换, TCP连接保持

底层TCP连接没断, 但HTTP已结束, 之后两边说的是WebSocket的”暗号”。

你可以这么理解: 打电话给餐厅 (HTTP), 请求转接到某个包间 (Upgrade), 服务员说”马上接通” (101响应), 之后你就跟包间的人直接聊天了 (WebSocket) 。线路没变, 协议变了。

ASGI在握手流程中扮演什么角色?

最让我一头雾水的是: ASGI是在哪一环介入的?

答案是: ASGI只在协议升级 (握手) 之后才介入。

分层解释:

服务器层 (Uvicorn/Hypercorn等, 自动完成) :

接收HTTP升级请求
校验WebSocket头
回复101响应
切换TCP连接协议

ASGI应用层 (你的代码) :

服务器创建WebSocket scope
发送websocket.connect消息给你的应用
你来决定: 同意还是拒绝连接 (比如做认证)

这样一分层, 豁然开朗:

协议层 (服务器): 判断是不是有效的WebSocket升级请求
业务层 (应用): 判断要不要让这个连接进来 (比如权限校验)

握手早就由服务器搞定了, 你收到websocket.connect时, 客户端已经连接上, 等你点头。你发websocket.accept只是”业务同意”, 不是协议握手。

代码示意:

# 收到握手后服务器转发的消息
message = await receive()
# message = {"type": "websocket.connect"}

# 业务判断, 比如认证
if user_is_authenticated:
    await send({"type": "websocket.accept"})
    # 开始双向消息循环
else:
    await send({"type": "websocket.close", "code": 1008})
    # 拒绝连接

理解了这点, FastAPI, Starlette各种WebSocket玩法就都清楚了——协议交给服务器, 业务你说了算。

你和客户端都能随时断开连接, 谁也不是大爷, 谁都能说”我不玩了”。

Lifespan: 横空出世的第四种scope

就在我以为ASGI只有HTTP/SSE/WebSocket三种模式时, 突然冒出来个lifespan, 彻底打乱了我的世界观。

原以为lifespan是”一次连接的生存期”, 比如WebSocket连着多久。事实证明, 我错得离谱。

lifespan根本跟一次连接没关系, 而是整个应用的生命周期——服务器进程从启动到关闭。

你可以这么总结:

HTTP scope: 活一次请求 (百毫秒)
SSE scope: 活一次流式会话 (几分钟到几小时)
WebSocket scope: 活一次双向会话 (几秒到几小时)
Lifespan scope: 活整个应用 (几天到几个月)

服务器启动时, 先创建lifespan scope, 给你发startup消息;关机时再发shutdown消息。

scope结构:

{
    "type": "lifespan",
}

消息类型:

{"type": "lifespan.startup"}
{"type": "lifespan.shutdown"}

啥用?适合那些只需要在应用启动或关闭时做一次的事:

数据库连接池初始化
机器学习模型加载到内存
启动后台任务调度器
缓存预热
监控/指标采集器初始化
优雅关闭各种资源

打个比方: HTTP/SSE/WebSocket是你招待每个顾客, lifespan是你每天开店 (准备食材, 开火) 和打烊 (关门, 清扫) 。

你肯定不想每次请求都加载2G模型吧?只需要在lifespan.startup一次性加载, 所有请求复用。同理, 关机时优雅关闭连接池。

FastAPI里的@app.on_event("startup")和@app.on_event("shutdown"), 其实就是在帮你处理这些lifespan消息。

lifespan和其他三种scope是正交的, 不是通信场景, 而是应用本身的生命周期管理。

ASGI的终极思维模型

经历了这些疑惑和顿悟, 我终于形成了这样一个清晰的思维框架:

ASGI是个统一的接口, 用来描述”通信会话”, 会话的类型有:

scope类型	存活时间	通信方向	典型场景
HTTP	毫秒级	请求→响应	API调用, 页面加载, 表单提交
SSE	分钟到小时	服务器→客户端	实时推送, 仪表盘, 通知
WebSocket	秒到小时	双向	聊天, 协作, 游戏, 实时控制
Lifespan	应用生命周期	N/A	启动/关闭, 资源管理

这四种都用同一个接口: async def app(scope, receive, send)。

scope字典告诉你遇上了啥会话, receive/send让你与之交互。合同不变, 玩法多变。

这样一来, 中间件也能通吃所有类型。比如认证中间件, 可以根据scope类型分别处理HTTP, WebSocket, SSE。日志中间件也是一样, 写一次通用所有。

这就是为啥你一旦理解ASGI, FastAPI用起来就很顺畅。所有路由, WebSocket端点, 启动事件, 本质上都是ASGI应用, 遵守同一个简单协议。

隐身的scope其实一直都在, 只是框架帮你藏起来了。等你需要深入理解WebSocket, 优雅管理资源, 写中间件的时候, 就会发现ASGI这层基础有多香。

从迷茫到通透

刚开始时, scope像个幽灵, 文档总假设你早就会。现在我终于明白: 它不过是个用来描述通信模式的字典。

美妙的是, 这种理解一通百通。读FastAPI的WebSocket例子, 能明白底层怎么回事;Starlette的启动事件, 其实就是lifespan消息的处理;排查连接断了, 也能思考是HTTP scope正常结束, 还是WebSocket意外关闭。

一旦下潜到”协议层”, 理解ASGI底层, 而非只会用框架, 迷雾就散了, 自信心up!

如果你正在开发实时功能, 异步API, 或者单纯想吃透现代Python Web后端, 希望这段旅程能帮你像我一样拨云见日。下次看到文档里的scope, 别慌, 你已经明白它的底细。

说不定哪天你也会撸出极简ASGI应用, 写出专属中间件, 或者终于搞懂框架背后的魔法。

ASGI的兔子洞随时欢迎你深入探索——但至少现在, 你已经站在了入口。

(文章原创, 部分内容用AI润色。)

实时协作技术大揭秘: 从REST到CRDT, 我们的白板是怎么变聪明的?

Tue, 16 Sep 2025 00:00:00 GMT

“为什么我非得刷新页面才能看到David的改动?”

Sarah Kim有点抓狂地合上了笔记本, 力道大得让同事都抬头。身为前谷歌产品经理的她, 对用户体验要求堪比修仙, 每一个卡顿都能让她如临大敌。现在, 她们自研的”MeetMind”协作白板, 堪称用户体验翻车现场。

“Maya!”她隔着开放工位大喊, 仿佛刚在黑魔法表演里失踪了二十分钟的会议记录。“我的Sprint规划笔记又没了!”

Maya Chen本想喝口咖啡, 听到喊声差点呛到。她是那种凌晨2点能修race condition, 早上9点还能精神开会的高级前端工程师。她淡定地说: “咱们的轮询机制快把服务器打爆了, 每5秒刷一次API, 还是慢得要命。”

后端老大Alex Rodriguez转身离开了他的终端界面, 他有着优化大型数据库的传奇履历, 光闻到内存泄漏的味道就能定位bug。“Sarah他们12个人, 每分钟光查更新就发144个请求, “他扶了下眼镜, 仿佛刚用htop打了个boss, “还不算我那AI分析模块上线之后的请求量。”

这就是我们三个程序员从基础REST API一路打怪升级, 最终做出一套支持离线, 语音AI分析, 可扩展到上百人协作的实时系统的血泪史。事实证明, 实时协作不只是”快”那么简单, 而是要彻底颠覆”人和机器之间数据怎么流动”的认知。

最开始的”小破轮询”, 最后竟然把我们带进了SSE, WebSocket, CRDT的黑科技世界。每解决一个问题, 都会冒出仨新bug——堪称技术版打地鼠。

第一章: 简单时代的烦恼

小白板, 大问题

来感受一下MeetMind 0.1版的”原始风味”——如果说2006年的Google Docs很简陋, 那我们的还不如人家。

Maya一开始用的标准RESTful CRUD, 写起来顺手, 逻辑清晰, 但遇到”实时协作”就秒变”龟速协作”。

// 最初级的API调用方式
class DocumentAPI {
  async getDocument(docId) {
    const response = await fetch(`/api/documents/${docId}`);
    return response.json();
  }
  async updateDocument(docId, changes) {
    const response = await fetch(`/api/documents/${docId}`, {
      method: "PUT",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(changes),
    });
    return response.json();
  }
}
// 经典轮询, 每5秒刷一次
setInterval(async () => {
  const latestDoc = await api.getDocument(currentDocId);
  if (latestDoc.updatedAt > lastKnownUpdate) {
    updateUI(latestDoc);
    lastKnownUpdate = latestDoc.updatedAt;
  }
}, 5000);

在Maya本地调试时, 一切都很美好。但Sarah一口气拉上12人团队集体”实战演练”之后, bug如潮水。

灾难现场速报:

David Thompson, 常年混迹波特兰咖啡馆的咨询师, 喝着第三杯美式, 刚敲完一段需求文档, 保存之后内容神秘消失——5秒后又原地复活, “幽灵操作”让他怀疑人生。

“这软件是灵异频道吗?”David在Slack上吐槽, “我刚写的内容一会儿有一会儿没, 根本不知道自己是不是在写’薛定谔的文档’。”

UX设计师Lisa Wang则遇到”按钮瞬移”魔咒: 她刚把按钮从头部拖到边栏, 5秒后Kevin在东京那边又把它挪回去了, 整个界面像在和她玩捉迷藏。

Maya一边摸着被烫的笔记本电脑, 一边盘点损失:

用户体验: 5秒钟的延迟, 协作直接断档
服务器压力: 12人×12次请求/分钟=144次, 服务器快要过劳死
无效请求: 90%的轮询都是”啥都没变”
电池消耗: 手机端用户电量狂掉
冲突频发: 5秒间隙里, 一堆人可能互相覆盖对方的操作

然后, Alex的AI分析一上线, 轮询简直喜提”灾难二连”。

AI分析的慢动作崩盘

Alex自豪地推出AI会议分析: 能实时识别激烈讨论, 自动抓取行动项, 推荐相关资料。AI很聪明, 但遇到我们的架构就变成了”拖延症患者”。

AI分析处理一次要2-15秒, Alex一开始还傻傻地让文档保存必须等AI跑完才能返回结果:

# 阻塞式AI分析, 用户等到头秃
@app.route('/api/documents/<doc_id>', methods=['PUT'])
def update_document(doc_id):
    doc = update_document_in_db(doc_id, request.json)
    ai_insights = analyze_document_with_llm(doc.content)  # 2-15秒卡死
    doc.ai_insights = ai_insights
    save_document(doc)
    return jsonify(doc.to_dict())

结果, 所有人一保存, 页面直接”假死”, 十几秒后所有操作齐刷刷地爆发——内容乱序, 冲突不断, 谁都不知道自己的更改去哪儿了。

Maya打开Chrome DevTools, 看到请求像堵车一样排队, 超时, 重试, 失败。她引以为傲的API, 秒变”数字连环车祸”。

异步救赎

Alex看着服务器日志, 一脸经历过大风大浪的疲惫, 忽然灵感一现:

“要不……保存和AI分析分开?先让用户保存, AI分析后台慢慢搞。”

这招一看简单, 其实堪称”技术治愈系”:

# 异步分析, 用户不必苦等
ai_processing_queue = Queue()
@app.route('/api/documents/<doc_id>', methods=['PUT'])
def update_document(doc_id):
    doc = update_document_in_db(doc_id, request.json)
    ai_processing_queue.put({'doc_id': doc_id, 'content': doc.content, 'version': doc.version})
    return jsonify(doc.to_dict())  # 秒返回

# 后台worker慢慢分析
def ai_worker():
    while True:
        task = ai_processing_queue.get()
        try:
            insights = analyze_document_with_llm(task['content'])
            update_ai_insights_in_db(task['doc_id'], insights, task['version'])
        except Exception as e:
            log_error(f"AI processing failed: {e}")

用户保存只需200毫秒, AI分析慢慢做, 体验直接质变。

但很快, 新的小烦恼又来了: 用户根本不知道AI分析什么时候完成, 还得10秒轮询一次——Maya的代码里多了一个轮询套娃, 笔记本风扇快变小型无人机。

真·实时顿悟

某个深夜, Maya盯着浏览器网络面板, 灵光乍现: 服务器啥时候分析完, 自己第一时间知道, 用户却还在傻等轮询。

“服务器明明知道一切, 为什么要让用户猜谜?”她自言自语。

Alex抬头: “要不我们直接通知用户?”

于是, 她研究了Server-Sent Events (SSE): 服务器有新消息, 直接推给客户端, 轮询彻底下岗!

// SSE实时推送
const eventSource = new EventSource(`/api/documents/${docId}/stream`);
eventSource.onmessage = function (event) {
  const update = JSON.parse(event.data);
  switch (update.type) {
    case "document_changed":
      updateDocument(update.document);
      break;
    case "ai_analysis_complete":
      displayInsights(update.insights);
      break;
    case "user_joined":
      showUserPresence(update.user);
      break;
  }
};

体验立竿见影: 改动几乎瞬间同步, AI分析结果秒级推送, 轮询不见了, 电池续航都提升了。

Lisa边用边感慨: “感觉软件突然有了生命。“

性能大跃进

对比一下前后差距:

REST + 轮询:

平均延迟: 2.5秒
最高延迟: 5秒
服务器每分钟144次请求
AI结果延迟5-15秒
手机发热, 电量狂掉

REST + SSE:

平均延迟: 200-400毫秒
最高延迟: 800毫秒
服务器每分钟仅24次请求
AI结果秒速推送
电池安静, 风扇罢工

两周后, 用户反馈爆棚, 大家都以为Maya修炼成仙。

直到Sarah又来提需求: “现在改动秒同步很棒, 可是我和David昨天同时写一个段落, 最后发现互相覆盖了对方的内容……”

Maya这才意识到: SSE虽然能”广播”, 但只能单向推送, 用户之间的”存在感”完全丢失。

第二章: WebSocket双向进化

”你在不在?”的协作尴尬

SSE解决了”服务器通知用户”的问题, 却搞不定”用户通知服务器”——比如实时光标, 正在输入, 选中内容等存在感信息。如果每次光标动都发HTTP请求, 简直是在侮辱互联网。

“我们需要双向通信!”Maya在白板上画出消息流图, “SSE只解决了一半, 剩下的必须靠更高级的工具。“

WebSocket救世主

WebSocket就是为此而生: 一条持久连接, 客户端和服务器可以像微信一样随时说话, 消息轻如鸿毛, 延迟低到让人怀疑人生。

Maya撸了一个基础WebSocket协作层, 实现了实时光标, 选区, 正在输入, 用户头像等”社交感”功能:

class CollaborationSocket {
  constructor(docId, userId) {
    this.docId = docId;
    this.userId = userId;
    this.socket = null;
    this.handlers = new Map();
    this.connect();
  }
  connect() {
    const wsUrl = `wss://${window.location.host}/collab/${this.docId}?userId=${this.userId}`;
    this.socket = new WebSocket(wsUrl);
    this.socket.onopen = () => {
      this.emit("presence", { type: "join", cursor: null, selection: null });
    };
    this.socket.onmessage = (event) => {
      const data = JSON.parse(event.data);
      const handler = this.handlers.get(data.type);
      if (handler) handler(data);
    };
    this.socket.onclose = () => {
      setTimeout(() => this.connect(), 1000);
    };
  }
  emit(type, payload) {
    if (this.socket && this.socket.readyState === WebSocket.OPEN) {
      this.socket.send(JSON.stringify({ type, payload, timestamp: Date.now() }));
    }
  }
  on(type, handler) {
    this.handlers.set(type, handler);
  }
}

Sarah和David第一次用上新功能, 两地实时看到彼此光标, 操作, 选区, 简直像魔法。

“我能看到你在想啥!""你选这段我就避开, 协作终于不是’互相踩雷’了!”团队一致叫好。

性能与体验双赢

WebSocket方案带来:

延迟<200ms, 体验流畅
只有一条持久连接, 再也不用疯狂请求
光标, 选区, 输入状态等”社交信号”自然流转
冲突大大减少, 大家协作不再互相踩脚

Sarah在全员演示时激动: “现在我一看到David的光标靠近某段, 立刻就知道别插手, 简直是’远程双人写作’。“

新的复杂度来袭

但人多了, 问题又来了:

并发冲突: 两人同时改同一段, 编辑顺序不固定, 偶尔还会”消失的改动”
离线编辑灾难: 有人断网写一小时, 回来一看, 和服务器上的内容南辕北辙
扩展性危机: 用户数上百, 每个动作都要广播给所有人, O(n²)的消息量让服务器”社恐”爆发

Maya每天晚上都在和”冲突合并”死磕, 白板上画满了消息流和失败案例。

“我们这是在和分布式系统的本质较劲, “Alex总结, “多源事实, 冲突是数学必然。”

“Google Docs, Figma, Notion都没这些烦恼, 他们到底做了啥?”Maya陷入哲学沉思。

这一问, 把我们带进了CRDT的神秘世界。

Maya此时以为WebSocket就能称王称霸, 没想到这只是”实时协作”路上的小菜一碟。真正的难题, 是让所有人的消息合成一个不出错, 不丢内容, 哪怕离线一小时也能自动合并的最终状态。

下一集: 实时协作必经的”复杂性墙”, 为什么看似简单的用户体验背后需要超复杂的分布式算法支撑。

第三章: 复杂性大山

技术考古之旅

Maya一周没出现在工位, 研究了十几篇论文和大厂架构博客, 终于搞明白了OT (Operational Transformation) 和CRDT (Conflict-free Replicated Data Type) 两大流派。

OT (操作转化): 核心思想是只传操作, 不传最终状态, 冲突时做数学转化, 保证无论顺序如何, 最终结果一致。但高度依赖中心服务器。
CRDT (无冲突副本数据结构): 数据结构本身能自动合并, 哪怕多台离线设备各自乱改, 回来也能合成一致的文档状态, 无需中央裁判。

她又发现Figma, Notion等大厂其实走的是”中心裁判派” (server-ordered operation), 而像Yjs这种库, 则是真·CRDT路线。

扩展性与离线需求的二选一

Sarah突然带来大单, 客户要办50人同时在线编辑的战略研讨会, 还要求离线编辑, 回头自动合并。Maya和Alex一合计: “中心裁判”架构扛不住, 必须上CRDT。

彻底转型: 拥抱CRDT

Maya用Yjs做了个Demo, 多人断网, 合并, 同步一气呵成, 冲突自动解决, 体验堪比Google Docs。

中心裁判派 (OT/Server Ordered): 好调试, 容易加权限, 但不能离线, 服务器压力大。
CRDT派 (Yjs): 本地直接合并, 离线无忧, 扩展性爆棚, 但业务逻辑复杂时有坑, 且脑洞要大。

“客户要离线和大规模并发, 这题目直接把我们选到CRDT队。“Maya一锤定音。

实现路线

文档状态全换成Yjs的CRDT结构
WebSocket只负责同步, 存在感等”短消息”, 不再传业务数据
离线用IndexedDB持久化
服务端只存快照, 不做冲突裁判
权限校验, 业务逻辑在CRDT层之上加

她做了一个”偷偷摸摸”迁移: 用户第一次打开文档时后台自动转为CRDT格式, 无感知升级。

测试效果炸裂: 断网, 多人同时乱改, 无脑合并, 全都完美。

真正的转折点

两周后, 客户50人同时在线, 期间还有一堆人断网, 重连, 文档无一丢失, 体验逆天。客户直接签了20万美金大单, 团队士气飙升。

最珍贵的是: 用户发现”自信心”回来了, 敢于大胆协作, 不怕丢改动, 也不怕被别人覆盖。

意外收获

服务器压力骤降, 成本反而下降
离线能力让我们拿下了更多”荒野团队”市场
用户留存, 使用时长, 满意度全面提升

最后, Sarah又抛来新挑战: “客户想要会中实时洞察, 比如谁在主导话题, 讨论是否跑偏, 哪些议题被忽略……”

Maya和Alex相视一笑: “既然CRDT我们都玩明白了, AI语音分析也不是梦!”

MeetMind终于实现了”协作工具不再添乱, 只做用户的隐形助手”。而下一个目标, 是让AI帮助人类读懂协作本身。

技术大揭秘: AI应用的实时通信选型

看完我们的踩坑史, 是时候聊聊”哪种实时技术最适合AI应用”了。下面这份”程序员选型秘籍”送给每一位想做AI协作, 实时音视频, 智能写作的开发者。

实时技术全家福

REST+轮询: 老少咸宜, 简单稳妥

适合场景: 低频状态刷新, 原型快速验证
AI应用: 批量任务, 模型训练进度, 定时报表
优点: 简单易调试
缺点: 延迟高, 服务器压力大, 用户体验拉胯
建议用法: 更新不频繁 (30秒以上) 时可用, 或MVP阶段

Server-Sent Events (SSE) : 一条龙推送

适合场景: 数据流推送, AI输出流, 实时通知
AI应用: 大模型Token流式输出, 实时字幕, 推理进度
优点: HTTP协议天然支持, 断线自动重连
缺点: 只能单向推送, 浏览器连接数有限
建议用法: AI结果流式推送, 用户无需反馈时

const eventSource = new EventSource("/api/chat/stream");
eventSource.onmessage = (event) => {
  const token = JSON.parse(event.data);
  displayToken(token); // 实时展示AI输出
};

WebSocket: 双向沟通小能手

适合场景: 交互式AI, 协作文档, 实时音视频
AI应用: 语音对话AI, 多用户实时编辑, 实时语音分析
优点: 延迟极低, 双向实时, 支持二进制数据
缺点: 实现比SSE复杂, 重连需要自定义逻辑
建议用法: 需要互动, 低延迟的AI场景

const socket = new WebSocket("/api/voice-chat");
socket.onmessage = (event) => {
  const { type, data } = JSON.parse(event.data);
  if (type === "transcription") showTranscription(data);
  if (type === "ai_response") playAudioResponse(data);
};
socket.send(audioBuffer); // 实时发送语音片段

CRDT (Yjs) : 离线优先, 冲突免疫

适合场景: 离线编辑, 多用户内容创作, 分布式AI
AI应用: 协作写作, 分布式模型训练, 知识库共建
优点: 自动冲突解决, 离线无忧, 扩展性强
缺点: 模型较复杂, 部分业务场景有局限
建议用法: 需要多人协作且支持离线, 同步合并的AI产品

const doc = new Y.Doc();
const sharedText = doc.getText("content");
const aiSuggestions = doc.getMap("ai_suggestions");
aiSuggestions.set(`suggestion_${timestamp}`, {
  type: "grammar_fix",
  range: [start, end],
  suggestion: aiGeneratedText,
});

框架对比总览

框架	延迟	离线支持	扩展性	技术复杂度	适用AI场景
REST+轮询	高 (2-5s)	❌	差	低	批量AI处理
SSE	低 (100-500ms)	❌	好	中	流式文本推送
WebSocket	极低 (<100ms)	❌	中	中	互动式AI, 语音
CRDT (Yjs)	低 (200-400ms)	✅	极好	高	协作AI, 离线编辑

WebRTC: 音视频AI的”快车道”

WebRTC是做实时音视频AI的必备神器:

适合场景: 实时语音AI, 视频滤镜, 边缘AI推理
AI应用: 语音克隆, 实时美颜, 分布式推理
优点: 超低延迟, P2P省服务器, 直接处理多媒体
缺点: NAT穿透复杂, 需要信令服务器

const peerConnection = new RTCPeerConnection();
const localAudio = await navigator.mediaDevices.getUserMedia({ audio: true });
const audioProcessor = new AudioWorklet("ai-voice-enhancer");
localAudio.addTrack(audioProcessor.outputTrack);
peerConnection.addTrack(audioProcessor.outputTrack);

Socket.IO: 实用主义选手

Socket.IO适合追求”开箱即用, 兼容性强”的AI产品:

适合场景: 快速原型, 混合传输, 跨平台AI协作
AI应用: 多模态AI, 协作工作流, 模型监控
优点: 自动降级, 房间管理, 好调试
缺点: 体积大, 存在锁定风险

const socket = io("/ai-workspace");
socket.emit("start_voice_session", { userId, language: "en" });
socket.on("transcription_partial", (text) => updateTranscript(text));
socket.on("ai_response", (response) => displayResponse(response));
socket.on("collaboration_update", (changes) => applyChanges(changes));

选型决策建议

文本类AI:

聊天/对话: WebSocket 或 Socket.IO
流式生成: SSE
多人协作: CRDT (Yjs) + WebSocket
文档分析: REST + SSE

语音类AI:

实时转写: WebSocket
语音对语音AI: WebRTC
会议分析: WebSocket音频流 + 服务器AI
离线语音笔记: CRDT + 本地AI

视觉类AI:

生成类 (如Midjourney) : REST主流程, SSE推送进度
实时滤镜: WebRTC + Canvas
多人设计: CRDT同步状态, WebSocket传存在感
视频分析: WebSocket传元数据, CDN分发视频

混合架构才是真王道

很多AI应用都是多技术融合——该用啥用啥:

class AIApplication {
  constructor() {
    this.httpClient = axios.create(); // REST重活
    this.eventSource = null; // SSE流结果
    this.socket = io(); // WebSocket互动
    this.collaborativeDoc = new Y.Doc(); // CRDT状态
  }
  async processDocument(doc) {
    const jobId = await this.httpClient.post("/api/ai/analyze", doc);
    this.eventSource = new EventSource(`/api/ai/stream/${jobId}`);
    this.eventSource.onmessage = (event) => {
      this.updateProgress(JSON.parse(event.data));
    };
  }
  startRealTimeChat() {
    this.socket.on("ai_message", (message) => this.displayMessage(message));
    this.socket.emit("user_message", userInput);
  }
  enableCollaboration() {
    this.collaborativeDoc.getText().observe(() => this.syncChanges());
  }
}

生产环境注意事项

认证安全: JWT可以通杀所有通道, WebSocket需做授权校验, CRDT要文档粒度控制
扩展性能: SSE用Redis做发布订阅, WebSocket水平扩展靠粘性会话/Redis, CRDT定期快照, 日志压缩
异常处理: 所有通道都要支持断线重连和降级, 用户端需清晰反馈

总结: 实时协作的核心不是比谁更快, 而是谁用对了技术, 用巧了组合。每种技术都有用武之地, 关键是选对场景, 敢于混搭。

无论你要做AI写作, 语音助手, 还是分布式协作工具, 理解这些技术的优劣, 才能让你的产品真正”智能且好用”。

(本文由人类原创, 部分内容借助AI润色。)