WebSocket流和事件
TL;DR
工作流=可靠通道（WSS）+总结的offset+偶数事件+严格的限制和背景。做到：JWT认证，拓扑授权，heartbeats，seq/offset+resume-token，at-least-once+dedup。对于规模-通过用户/tenant，粘性路由和队列（Kafka/NATS/Redis Streams）进行混合，作为真理的来源。
1） iGaming商业桉例（实际流）
资产负债表/限额：即时变更资产负债表、RG限额、锁定。
投注/回合/结果：确认，状态，获胜计算。
比赛/排行榜：位置，计时器，获奖活动。
付款：付款状态/退款，KYC/AML标志-作为通知（批评仍保留在REST+webhooks中）。
服务事件：聊天消息，推横幅，会话状态，维护。
2）协议和连接
仅WSS（TLS 1。2+/1.3).默认情况下,每个设备/会话最多有1个活动连接。
Ping/Pong：每20-30秒shlet "ping"客户端,响应计时10秒。服务器在连续3个计时时时重置连接。
压缩："permessage-deflate"（帧大小限制）（例如≤ 64 KB）。
有效载荷格式：用于外部的JSON，用于内部/移动的Protobuf/MsgPack。
3）认证和授权
带有JWT的Handshake在query/header（"Sec-WebSocket-Protocol"/"授权"）中，TTL令牌短（≤ 15分钟），脱口秀（REST）。
Tenant-scoped claims: `sub`, `tenant`, `scopes`, `risk_flags`.
ACL到拓扑/通道：仅订阅允许的"拓扑"（例如："user： {id}","tournament： {id}",'game： {table}"）。
令牌到期时重新构建连接："软窗口"60秒。
4）订阅模型
连接后客户端发送命令：json
{ "op":"subscribe", "topics":["user:123", "tournament:456"], "resume_from":"1748852201:987654" }
{ "op":"unsubscribe", "topics":["tournament:456"] }"resume_from"-如果客户端恢复连接,则为offset（参见§5）。
服务器在"nack"和"reason"中响应ack/nack，未请求的ACL。
5）交货保证和总结
目的：在客户中，在通道+相容性上保持一致。
每个事件在"分期付款"（通常是用户/room）中具有单调的"seq"和用于重复数据消除的全局"event_id"。
在重新连接下，客户会发送"resume_from"=最后确认的"seq"（或"offset"经纪人）。服务器将赶上从"真相源"（Kafka/NATS/Redis Streams）跳过的事件。
如果时差超过了retention（例如,24小时）,服务器会发送"snapshot"状态和新的"seq"。
- 将"last_seq"/"event_id"存储在durable存储中（IndexedDB/Keychain）。
- 通过"event_id"，通过"seq ≤ last_seq'跳过事件，检测漏洞（gap）→自动"resync" snapshot请求。
6）消息模式（envelope）
json
{
"ts": "2025-11-03T12:34:56. 789Z",
"topic": "user:123",
"seq": "1748852201:987654", // partition:offset
"event_id": "01HF..", // UUID/KSUID
"type": "balance. updated",
"data": { "currency":"EUR", "delta"--5. 00, "balance":125. 37 },
"trace_id": "4e3f.., "//for correlation
"signature": "base64 (hmac (...)) "//optional for partners
}"类型"是域分类法（请参阅事件字典）。
PII/PCI-在网关级别排除/掩蔽。
7）Backpressure，配额和"昂贵"客户保护
Server → Client：带有"滑动窗口"的per-connection send-queue。溢出-重置带有"1013"/"policy_violation"代码的"嘈杂"拓扑或disconnect的订阅。
Client → Server："subscribe/unsubscribe"的限制（例如，≤ 10/秒），拓扑列表限制（≤ 50），最小重新订阅间隔。
IP/tenant/密钥的限额。异常→临时锁定。
优先：重要事件（平衡,RG限制）-优先排队。
8）保护和安全
Handshake端点上的WAF/机器人配置文件，允许的起源列表。
边缘网关和流节点之间的mTLS。
DoS保护：L4上的SYN cookie，开放的WS数量/保持间隔的限制。
反重播：可选有效载荷签名（适用于合作伙伴）中的"timestamp"，带有允许的5分钟窗口。
租户隔离：物理/逻辑硬化，按键或按键令牌。
9）运输架构
网关（edge）： TLS终端、authN/Z、配额、分批路由。
流节点：通过'hash （user_id）% N'进行僵硬漫游的无状态锻炼者。
事件经纪人：Kafka/NATS/Redis Streams是真相和缓冲的来源。
国家服务：存储狙击手（balance，比赛位置）。
多区域：资产资产；最近地区的GSLB；居所区域在登录时固定；failover是来自另一个地区的"冷"灌木丛。
10）顺序，一致性，相等性
有序性在批次（用户/room）内得到保证，而不是全局保证。
一致性：事件可能早于REST响应；UX必须能够生活在中间状态（optimistic UI+reconciliation）。
等效性：重新处理"event_id"不会改变客户的状态。
11）错误，重新发现和"风暴"
关闭代码为：'1000 '（normal）, '1008' （policy）, '1011' （internal）, '1013 '（server overload）。
客户指数backoff+jitter： 1s, 2s, 4s……max 30 s。
在质量重构（"thundering herd"）期间，服务器会发出"retry_after"和"灰色"响应，并提示使用SSE后退进行只读。
12）Cash和snapshots
每个订阅都可以从当前状态的快照开始，然后是diff事件的流。
"data_version"模式的验证和互操作性（字段扩展不会破坏客户）。
13）可观察性和SLO
度量标准：- 连接：主动，设置/秒，按租户/地区分配。
- 交付：p50/p95延迟从经纪人到客户,下降率,恢复率。
- 可靠性：成功的零碰碰碰碰撞的比例,gap检测器.
- 错误：handshake上的4xx/5xx，关闭代码，限量版。
- 负载：命令"subscribe"的RPS，队列大小，CPU/NET。
- 建立WS p95 ≤ 500毫秒（在区域内）。
- p95 ≤ 300毫秒事件的端到端后端（用户分区）。
- Resume success ≥ 99%, message loss = 0 (по at-least-once).
- Uptime stream endpoint ≥ 99。95%.
14）图形和版本管理
具有所有者，示例和语义的事件词典。
"软"演变：仅添加可选字段；删除-在'@deprecated'期之后。
针对客户端SDK的合同测试，JSON Schema/Protobuf 上的linter。
15）事件花花公子（嵌入您的共享花花公子）
后期增长：将批次切换到备用节点，增加经纪人的击球大小，并优先考虑重要事件。
重构风暴：激活"retry_after"，暂时提高手势限制，启用SSE后卫。
令牌泄漏：JWKS轮换，受影响的令牌召回，从re-auth强制回收。
经纪人分期付款损失：转为狙击模式，恢复后倒带。
16）微型API规范（简化）
Handshake (HTTP GET → WS):
GET /ws? tenant=acme&client=web
Headers:
Authorization: Bearer <JWT>
X-Trace-Id: <uuid>json
{ "op":"subscribe", "topics":["user:123"], "resume_from":"1748852201:42" }
{ "op":"unsubscribe", "topics":["user:123"] }
{ "op":"ping", "ts":"2025-11-03T12:34:56Z" }json
{ "op":"ack", "id":"subscribe:user:123" }
{ "op":"event", "topic":"user:123", "seq":"1748852201:43", "type":"balance. updated", "data":{...} }
{ "op":"snapshot", "topic":"user:123", "seq":"1748852201:42", "state":{...} }
{ "op":"error", "code":"acl_denied", "reason":"no access to topic tournament:456" }
{ "op":"pong", "ts":"..." }17） UAT支票单
- 客户在1/10/60分钟后从离场时段开始。
- Dedup：重新交付相同的"event_id"不会改变状态。
- Gap检测器→自动"快照"和对齐。
- 配额和反向压力：装载的客户端接收策略解密。
- Multirregion：离岸保护区。
- Security：已过期的JWT令牌摇滚,在ACL外尝试订阅。
- RG/事件平衡在 REST之前/之后-UI正确地"缝合"。
18）常见错误
没有"seq/offset"和恢复-我们失去事件和信任。
在WS突变中混合关键支付命令-使用REST。
缺少backpressure/配额-"悬挂"连接和内存雪崩。
全球有序性-昂贵且不需要；党内有足够的秩序。
在事件中编写PII-违反隐私和PCI/GDPR。
没有事件词典和转会-客户崩溃。
总结
如果将响应式UX和操作信号构造为可总结，受保护和受限的通道，则WebSocket流会产生响应UX和操作信号：WSS+mTLS/JWT，拓扑上的ACL，seq/offset+resume，带有重复数据消除的at-least-once，backpressure/配额，作为真理源的经纪人，可观察性和SLO。因此，流对用户来说仍然是快速的，对平台来说是可以管理的--在安全和金钱方面没有妥协。