modify: 分布式方案
This commit is contained in:
@@ -288,6 +288,25 @@ worker/<type>/<worker_id>/__admin__
|
||||
|
||||
- **进程插件（external）不受该开关影响**：网关只对 **inline** 插件用 cache 解析启动副本数（见「启动流程」第 5 步 `load_workers`）；external 插件由外部编排按其自身配置 `config/workers/<type>/config.toml` 的 `count` 启动，不经网关、也不读 cache。运行时 `scale` 对 external 仍走「向存活副本下发 rescale」路径，同样与该开关无关。
|
||||
|
||||
### inline worker 宿主级领导选举（gunicorn 多 worker 兼容）
|
||||
|
||||
inline worker 的生命周期交给**基于分布式锁的宿主级领导选举**（取代“每 gunicorn worker 各自拉起”），key `inline_owner:<gateway_id>` 按网关隔离：
|
||||
|
||||
- **多 worker（同网关）**：同一时刻只有一个网关进程托管 inline worker（副本数精确等于 `count`，不再是 `worker 数 × count`）；其余进程只做 HTTP，经 Zenoh liveliness 发现并调用 inline worker。HTTP 层仍由所有 gunicorn worker 分担吞吐。
|
||||
- **多实例（不同网关）**：各网关按自己的 `gateway_id` 各自选举，互不抢占。
|
||||
- **持有者崩溃自愈**：非持有者进程经 `refresh_workers` 周期性巡检（`_maybe_heal_inline`）——若发现某 inline 类型既无线活副本又无本地副本，就经分布式锁抢得领导权并拉起这些 worker（防 gunicorn 复活死 slot 却因租约未过期而跳过的问题）。接管同样 `set_nx` 唯一胜出，无双持有。
|
||||
- 前提：同一共享 `[cache]`（见「全局副本数协调」）；单实例本机 `diskcache` 即可，多实例需共享后端。
|
||||
|
||||
### 多 worker 的边界（转发 vs 处理）
|
||||
|
||||
在 gunicorn 多 worker 模式下，结论是：**多 worker 提升的是网关"HTTP 接入/转发"能力，不提升"worker 处理"能力**——网关角色是代理，真正的 RPC 处理在 worker 端。
|
||||
|
||||
| 瓶颈所在 | 多 gunicorn worker 是否有效 | 正确扩法 |
|
||||
| -------- | --------------------------- | -------- |
|
||||
| HTTP 接入/转发（高 QPS 转发、并发慢客户端、鉴权/路由） | ✅ 有效（上限≈核数） | 加 gunicorn `-w` |
|
||||
| inline 插件实际计算 | ⚠️ 有限（多 worker 只是更快把请求塞给同一个 inline worker，inline 仍单点） | 加 worker 副本数 `count` / 改跑 external 进程 |
|
||||
| external 进程插件处理 | ✅ 有效（多 worker 可并行转发给独立进程） | 加 gunicorn `-w` + 对等扩 external |
|
||||
|
||||
### 前端管理页
|
||||
|
||||
`Worker 管理`（`/workers`，深色主题）：
|
||||
@@ -524,7 +543,7 @@ start.sh 容器入口：uv sync + chongming-worker --type
|
||||
|
||||
### Broker 来源（内嵌 vs 外部）
|
||||
|
||||
网关默认启动内嵌 amqtt Broker（子进程 + 文件锁单例），`[<env>.mqtt].use_embedded_broker` 控制 Broker 来源：
|
||||
网关默认启动内嵌 amqtt Broker（子进程 + **宿主级分布式排他锁**单例），`[<env>.mqtt].use_embedded_broker` 控制 Broker 来源：
|
||||
|
||||
```toml
|
||||
[development.mqtt]
|
||||
@@ -537,6 +556,12 @@ use_embedded_broker = true # true（默认）网关启动 amqtt Broker；false
|
||||
- `use_embedded_broker = true`（默认）：网关启动内嵌 amqtt Broker 子进程，MQTT Bridge 作为客户端连回自身。
|
||||
- `use_embedded_broker = false`：网关**不启动** Broker，MQTT Bridge 直接连接 `host:port` 指向的外部 MQTT Broker（如独立部署的 EMQX/Mosquitto）。`host` 需改为外部 Broker 地址，`enabled = false` 时整个 MQTT 通道关闭。
|
||||
|
||||
**单例与生命周期控制**（取代旧文件锁）：
|
||||
|
||||
- 内嵌 Broker 用 `chongming-cache` 的 `DistributedLock`（key `mqtt_broker:<hostname>`，**按宿主隔离**——内嵌 Broker 绑定本机端口），多 worker/多实例下同一宿主机只启动一个 Broker；`cache` 未配置时跳过并告警。
|
||||
- 持锁的网关在缓存登记其 Broker 子进程 PID（`mqtt_broker_owner:<hostname>`）。前任持有者崩溃/被强杀而留下**孤儿 Broker 子进程**时，接管的网关据此 PID 识别并终止之，再启动**由自己托管**的新子进程（可停、可接管）；否则端口被不可托管进程占用时仅复用、不托管。
|
||||
- 关停时仅真正托管子进程的网关终止进程、清理登记并释放锁，绝不误伤他人。
|
||||
|
||||
### Broker 认证（用户名/密码）
|
||||
|
||||
`[<env>.mqtt].username` / `password` 配置 Broker 认证（可选，默认匿名）：
|
||||
@@ -579,6 +604,7 @@ MQTT Bridge 是**网关进程内**的 MQTT 客户端组件，负责订阅主题
|
||||
- **抢锁机制**：启动时 `set_nx`（SET NX + TTL 租约）原子抢锁，key 为 `mqtt_bridge`；抢到锁的网关才启动 Bridge，其余网关跳过。
|
||||
- **租约续约**：持锁网关后台定期 `touch` 续约；若持锁网关宕机/失联，租约到期后锁自动释放，其他网关可重新抢到（重启后生效）。
|
||||
- **受保护释放**：关闭时仅当 token 仍匹配（仍是自己持有）才删除，绝不误删其他网关抢到的锁。
|
||||
- **持有者崩溃自愈接管**：仅靠 gunicorn 复活死掉 slot 无法 failover（新进程可能在旧锁租约未过期时抢锁失败而照样跳过）。各网关进程内有**周期性巡检**（`mqtt_bridge_supervisor`，周期经 `[<env>.mqtt].bridge_supervise_interval` 配置，默认 15s）：非持有者进程若发现锁已空闲（原持有者租约过期=已死/失联），即经 `set_nx` 抢得唯一持有权并**自动重建 Bridge**；接管时同步按需拉起/接管内嵌 Broker。分布式锁保证任意时刻只有一方胜出，无分裂。
|
||||
|
||||
```toml
|
||||
[cache]
|
||||
@@ -589,6 +615,17 @@ backend = "redis" # 跨主机收敛必须用 redis（或共享卷 dis
|
||||
- **`use_embedded_broker = true`（各机内嵌独立 Broker）**：各机 Broker 互不相连、本身不产生重复响应；此时全局单 Bridge 只会连到持锁网关那台机器的 Broker。
|
||||
- **`use_embedded_broker = false`（共享外部 Broker）**：原先 N 台网关的 N 个 Bridge 会共同订阅同一批主题，导致一条请求被各消费一次、各回一份响应；改用分布式锁后全局只有一个 Bridge 消费，彻底规避重复响应。
|
||||
|
||||
**部署结论**（内嵌 Broker 单例同样成立，`mqtt_broker:<hostname>` 按宿主隔离）：
|
||||
|
||||
| 部署形态 | MQTT Broker | `[cache]` 后端 | 状态 |
|
||||
| -------- | ----------- | ------------- | ---- |
|
||||
| 单机（含多 worker） | 内嵌 amqtt | 本地 `diskcache` | ✅ 完全够用 |
|
||||
| 多实例分布式 | **外部 Broker**（必须，内嵌各机不聚合、接管会断设备） | **redis**（或共享卷 `diskcache`） | ✅ 推荐 |
|
||||
|
||||
> 关键：多实例是否收敛，**MQTT 只是其中一环**，真正的收敛前提是**所有网关共享同一 `[cache]` 后端**。Bridge 全局锁、inline 领导选举锁、在线网关清单/quota 全部工作在同一共享 cache 上；若各实例用各自本机 cache，`mqtt_bridge` 锁跨不了主机，每台都能抢到 Bridge，又会退化成 N 个 Bridge 各连各的 Broker → 单请求多响应，问题回归。
|
||||
>
|
||||
> 即：**单机 = 内嵌 Broker + 本地 diskcache；多实例 = 外部 Broker（必须）+ redis/共享卷 diskcache（选一）**。
|
||||
|
||||
### 请求负载格式（信封协议）
|
||||
|
||||
MQTT 请求负载为信封结构，控制字段与业务数据分离：
|
||||
|
||||
Reference in New Issue
Block a user