openxiangda 2.30.0 → 2.31.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/browser/ManagedCommand.d.ts +36 -0
- package/dist/browser/ManagedCommand.d.ts.map +1 -0
- package/dist/browser/ManagedCommand.js +41 -0
- package/dist/browser/ManagedCommand.js.map +1 -0
- package/dist/browser/components/resource/useResourceFormDrafts.d.ts.map +1 -1
- package/dist/browser/managed-command.d.ts +72 -0
- package/dist/browser/managed-command.d.ts.map +1 -0
- package/dist/browser/managed-command.js +282 -0
- package/dist/browser/managed-command.js.map +1 -0
- package/dist/browser/platform-client.d.ts +3 -0
- package/dist/browser/platform-client.d.ts.map +1 -1
- package/dist/browser/platform-client.js +32 -0
- package/dist/browser/platform-client.js.map +1 -1
- package/dist/config.d.ts +1 -0
- package/dist/config.d.ts.map +1 -1
- package/dist/core.d.ts +3 -0
- package/dist/core.d.ts.map +1 -1
- package/dist/core.js +2 -0
- package/dist/core.js.map +1 -1
- package/dist/mobile.d.ts +3 -0
- package/dist/mobile.d.ts.map +1 -1
- package/dist/mobile.js +3 -0
- package/dist/mobile.js.map +1 -1
- package/dist/react.d.ts +4 -0
- package/dist/react.d.ts.map +1 -1
- package/dist/react.js +3 -0
- package/dist/react.js.map +1 -1
- package/documentation/getting-started.md +7 -7
- package/documentation/managed-concurrency.md +98 -0
- package/documentation/manifest.json +8 -2
- package/package.json +27 -22
- package/releases/2.31.0.json +39 -0
- package/skills/manifest.json +1 -1
- package/skills/openxiangda-v2/SKILL.md +5 -4
- package/skills/openxiangda-v2/references/getting-started.md +7 -7
- package/skills/openxiangda-v2/references/managed-concurrency.md +98 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "openxiangda",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.31.0",
|
|
4
4
|
"description": "OpenXiangda 2.0 的统一命令、应用 SDK、MCP 与中文 AI 技能资料。",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./dist/index.js",
|
|
@@ -60,13 +60,13 @@
|
|
|
60
60
|
"antd-mobile": "5.42.3",
|
|
61
61
|
"dayjs": "1.11.18",
|
|
62
62
|
"docx-preview": "0.3.7",
|
|
63
|
-
"openxiangda-cli": "2.6.
|
|
64
|
-
"openxiangda-contracts": "2.
|
|
65
|
-
"openxiangda-devkit-core": "2.
|
|
63
|
+
"openxiangda-cli": "2.6.2",
|
|
64
|
+
"openxiangda-contracts": "2.28.0",
|
|
65
|
+
"openxiangda-devkit-core": "2.31.0",
|
|
66
66
|
"openxiangda-legacy": "npm:openxiangda@1.0.269",
|
|
67
|
-
"openxiangda-mcp": "2.0.
|
|
68
|
-
"openxiangda-nest": "2.7.
|
|
69
|
-
"openxiangda-skill-kit": "2.3.
|
|
67
|
+
"openxiangda-mcp": "2.0.52",
|
|
68
|
+
"openxiangda-nest": "2.7.5",
|
|
69
|
+
"openxiangda-skill-kit": "2.3.26",
|
|
70
70
|
"xlsx": "https://github.com/1377385356/openxiangda/releases/download/vendor-mirror/xlsx-0.20.3.tgz"
|
|
71
71
|
},
|
|
72
72
|
"peerDependencies": {
|
|
@@ -132,37 +132,42 @@
|
|
|
132
132
|
},
|
|
133
133
|
"openxiangdaRelease": {
|
|
134
134
|
"schemaVersion": "openxiangda.release-notes/v1",
|
|
135
|
-
"version": "2.
|
|
135
|
+
"version": "2.31.0",
|
|
136
136
|
"status": "reviewed",
|
|
137
|
-
"title": "OpenXiangda 2.
|
|
138
|
-
"summary": "
|
|
137
|
+
"title": "OpenXiangda 2.31.0:缓存、排队与原子配额",
|
|
138
|
+
"summary": "应用可声明热点内容缓存、全局准入、可恢复的 Native 命令和整数配额。平台承担回源保护、受理幂等与事务内分配,React 和移动端 SDK 提供等待、提交及原结果恢复。",
|
|
139
139
|
"newFeatures": [
|
|
140
|
-
"
|
|
141
|
-
"
|
|
140
|
+
"data.concurrency 由两端共享编译器验证,缓存读取声明包含权限范围、有限参数、失效依赖和回源预算。",
|
|
141
|
+
"等待准入按可信主体合并重复请求,持久命令返回原操作回执,响应丢失和页面刷新后可继续核对结果。",
|
|
142
|
+
"整数配额支持立即分配、预占、确认、释放与到期;配额、业务记录、事件和结果在同一 Native 事务提交,受管模型阻止普通 CRUD 绕过。",
|
|
143
|
+
"openxiangda/react 和 openxiangda/mobile 提供 createManagedConcurrencyClient、useManagedCommand、ManagedCommandStatus 与 ManagedCommandGate。"
|
|
142
144
|
],
|
|
143
145
|
"fixes": [],
|
|
144
146
|
"affectedUsers": [
|
|
145
|
-
"
|
|
147
|
+
"需要缓存、排队、限量申领、预约或抢票的 OpenXiangda 2.0 应用开发者。"
|
|
146
148
|
],
|
|
147
149
|
"upgradeSteps": [
|
|
148
|
-
"
|
|
149
|
-
"
|
|
150
|
-
"
|
|
150
|
+
"升级到 openxiangda@2.31.0 并更新锁文件,按 docs/managed-concurrency.md 及完整声明示例配置资源和权限。",
|
|
151
|
+
"先确认目标平台已部署 data.managed-concurrency@1.0.0 及对应 SQL migration,再激活测试版本。未启用此声明的应用沿用原路径。",
|
|
152
|
+
"上线前按目标硬件、真实权限和业务规模验证完成速率、P95/P99、回源 SQL、锁等待及恢复时间;部署和容量验收独立于 npm 发行。",
|
|
153
|
+
"停用或切换不兼容版本前停止新受理并排空非终态命令,保留历史命令、分配及回执。"
|
|
151
154
|
],
|
|
152
155
|
"knownLimitations": [
|
|
153
|
-
"
|
|
154
|
-
"
|
|
155
|
-
"
|
|
156
|
+
"首版执行编译后的 Native 原子动作,不把任意 JS、SQL 或第三方调用纳入原子事务。",
|
|
157
|
+
"Redis 故障时暂停新准入和缓存回源;临时等待位置不承诺持久,已持久受理命令可恢复。",
|
|
158
|
+
"缓存减少内容 SQL,当前身份和权限链路仍有数据库访问;不提供公共 CDN 发布或自动全量预热。",
|
|
159
|
+
"同一配额池和主体永久去重,释放后不会自动重新报名;新一轮业务使用新的权威资源或配额池。",
|
|
160
|
+
"资源保护上限不代表生产吞吐保证;公开包升级不会自动升级客户平台。"
|
|
156
161
|
],
|
|
157
162
|
"issues": [],
|
|
158
163
|
"compatibility": {
|
|
159
164
|
"node": ">=24",
|
|
160
165
|
"workspaceGenerations": "v2",
|
|
161
|
-
"platform": "
|
|
166
|
+
"platform": "声明并发能力时要求 data.managed-concurrency@1.0.0;同时声明业务唯一键时还要求 data.unique-keys@1.0.0。",
|
|
162
167
|
"v1": "独立 V1 引擎和工作区不受影响。"
|
|
163
168
|
},
|
|
164
|
-
"sha256": "
|
|
165
|
-
"url": "https://github.com/1377385356/openxiangda/releases/tag/v2.
|
|
169
|
+
"sha256": "6258bae64bad0db43a319ecb6886a037952e0c77410edd6a790d18b8cd470645",
|
|
170
|
+
"url": "https://github.com/1377385356/openxiangda/releases/tag/v2.31.0"
|
|
166
171
|
},
|
|
167
172
|
"scripts": {
|
|
168
173
|
"build": "node ../../scripts/prune-package-dist.mjs && tsc -p tsconfig.json && node scripts/copy-assets.mjs",
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": "openxiangda.release-notes/v1",
|
|
3
|
+
"version": "2.31.0",
|
|
4
|
+
"status": "reviewed",
|
|
5
|
+
"title": "OpenXiangda 2.31.0:缓存、排队与原子配额",
|
|
6
|
+
"summary": "应用可声明热点内容缓存、全局准入、可恢复的 Native 命令和整数配额。平台承担回源保护、受理幂等与事务内分配,React 和移动端 SDK 提供等待、提交及原结果恢复。",
|
|
7
|
+
"newFeatures": [
|
|
8
|
+
"data.concurrency 由两端共享编译器验证,缓存读取声明包含权限范围、有限参数、失效依赖和回源预算。",
|
|
9
|
+
"等待准入按可信主体合并重复请求,持久命令返回原操作回执,响应丢失和页面刷新后可继续核对结果。",
|
|
10
|
+
"整数配额支持立即分配、预占、确认、释放与到期;配额、业务记录、事件和结果在同一 Native 事务提交,受管模型阻止普通 CRUD 绕过。",
|
|
11
|
+
"openxiangda/react 和 openxiangda/mobile 提供 createManagedConcurrencyClient、useManagedCommand、ManagedCommandStatus 与 ManagedCommandGate。"
|
|
12
|
+
],
|
|
13
|
+
"fixes": [],
|
|
14
|
+
"affectedUsers": [
|
|
15
|
+
"需要缓存、排队、限量申领、预约或抢票的 OpenXiangda 2.0 应用开发者。"
|
|
16
|
+
],
|
|
17
|
+
"upgradeSteps": [
|
|
18
|
+
"升级到 openxiangda@2.31.0 并更新锁文件,按 docs/managed-concurrency.md 及完整声明示例配置资源和权限。",
|
|
19
|
+
"先确认目标平台已部署 data.managed-concurrency@1.0.0 及对应 SQL migration,再激活测试版本。未启用此声明的应用沿用原路径。",
|
|
20
|
+
"上线前按目标硬件、真实权限和业务规模验证完成速率、P95/P99、回源 SQL、锁等待及恢复时间;部署和容量验收独立于 npm 发行。",
|
|
21
|
+
"停用或切换不兼容版本前停止新受理并排空非终态命令,保留历史命令、分配及回执。"
|
|
22
|
+
],
|
|
23
|
+
"knownLimitations": [
|
|
24
|
+
"首版执行编译后的 Native 原子动作,不把任意 JS、SQL 或第三方调用纳入原子事务。",
|
|
25
|
+
"Redis 故障时暂停新准入和缓存回源;临时等待位置不承诺持久,已持久受理命令可恢复。",
|
|
26
|
+
"缓存减少内容 SQL,当前身份和权限链路仍有数据库访问;不提供公共 CDN 发布或自动全量预热。",
|
|
27
|
+
"同一配额池和主体永久去重,释放后不会自动重新报名;新一轮业务使用新的权威资源或配额池。",
|
|
28
|
+
"资源保护上限不代表生产吞吐保证;公开包升级不会自动升级客户平台。"
|
|
29
|
+
],
|
|
30
|
+
"issues": [],
|
|
31
|
+
"compatibility": {
|
|
32
|
+
"node": ">=24",
|
|
33
|
+
"workspaceGenerations": "v2",
|
|
34
|
+
"platform": "声明并发能力时要求 data.managed-concurrency@1.0.0;同时声明业务唯一键时还要求 data.unique-keys@1.0.0。",
|
|
35
|
+
"v1": "独立 V1 引擎和工作区不受影响。"
|
|
36
|
+
},
|
|
37
|
+
"sha256": "6258bae64bad0db43a319ecb6886a037952e0c77410edd6a790d18b8cd470645",
|
|
38
|
+
"url": "https://github.com/1377385356/openxiangda/releases/tag/v2.31.0"
|
|
39
|
+
}
|
package/skills/manifest.json
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
{
|
|
5
5
|
"name": "openxiangda-v2",
|
|
6
6
|
"description": "使用 OpenXiangda 2.0 从模糊业务想法、已有资料或具体变更出发,通过对话发现模块、完成详细产品设计,由当前 AI Agent 按需用 Image 2.5 等图片能力形成视觉参考,直接实现真实页面并在浏览器修正,再检查和交付应用;维护 1.x 应用时使用对应的 1.x 技能。",
|
|
7
|
-
"sha256": "
|
|
7
|
+
"sha256": "21818bd1f22b3be7ce899c8d4b2088d64e0ad4cd056506afbbc705ea4a0c9b72"
|
|
8
8
|
}
|
|
9
9
|
]
|
|
10
10
|
}
|
|
@@ -40,10 +40,10 @@ AI 接到新应用、页面或改版任务时,在同一个 OpenXiangda 工作
|
|
|
40
40
|
未创建工作区时使用本 Skill 随根包发布的精确版本:
|
|
41
41
|
|
|
42
42
|
```bash
|
|
43
|
-
pnpm dlx openxiangda@2.
|
|
44
|
-
pnpm dlx openxiangda@2.
|
|
45
|
-
pnpm dlx openxiangda@2.
|
|
46
|
-
pnpm dlx openxiangda@2.
|
|
43
|
+
pnpm dlx openxiangda@2.31.0 auth status --cwd <应用目录> --base-url <平台地址> --json
|
|
44
|
+
pnpm dlx openxiangda@2.31.0 login --cwd <应用目录> --base-url <平台地址>
|
|
45
|
+
pnpm dlx openxiangda@2.31.0 create <应用目录> --base-url <同一平台地址>
|
|
46
|
+
pnpm dlx openxiangda@2.31.0 skill install --force
|
|
47
47
|
```
|
|
48
48
|
|
|
49
49
|
创建前把产品要求的目标平台明确带入命令,不从旧登录态推断站点。已有工作区从原绑定恢复,平台不一致时先解决登录与目标,不改 link 文件跨站创建。
|
|
@@ -72,6 +72,7 @@ pnpm dlx openxiangda@2.30.0 skill install --force
|
|
|
72
72
|
| 审批、待办、消息或事件 | [工作流与通知](references/workflow-events.md) |
|
|
73
73
|
| 自定义事务、校验或外部集成 | [按需后端](references/backend.md) |
|
|
74
74
|
| 主子额度、审批占用释放、撤回修订重提 | [精确金额占用](references/decimal-reservations.md) |
|
|
75
|
+
| 热点读取、抢票、排队、名额预占与原结果恢复 | [缓存、排队与配额](references/managed-concurrency.md) |
|
|
75
76
|
| 管理成员或查看有效流程参数 | [应用管理](references/administration.md) |
|
|
76
77
|
| 检查、部署、生产发布与故障恢复 | [验收](references/testing.md)、[交付](references/delivery.md) |
|
|
77
78
|
| 需求记录与版本升级 | [全流程记录](references/appspec.md)、[升级](references/upgrading.md) |
|
|
@@ -68,10 +68,10 @@ MCP 服务随项目根包一起安装,AI 客户端的 stdio 连接仍需配置
|
|
|
68
68
|
以下命令的版本占位符由随包资料替换为该根包的精确版本。网站源码阅读者应先确认要使用的发行版本。
|
|
69
69
|
|
|
70
70
|
```bash
|
|
71
|
-
pnpm dlx openxiangda@2.
|
|
72
|
-
pnpm dlx openxiangda@2.
|
|
73
|
-
pnpm dlx openxiangda@2.
|
|
74
|
-
pnpm dlx openxiangda@2.
|
|
71
|
+
pnpm dlx openxiangda@2.31.0 skill install --force
|
|
72
|
+
pnpm dlx openxiangda@2.31.0 auth status --base-url <平台地址> --json
|
|
73
|
+
pnpm dlx openxiangda@2.31.0 login --cwd my-app --base-url https://platform.example.com
|
|
74
|
+
pnpm dlx openxiangda@2.31.0 create my-app --base-url https://platform.example.com
|
|
75
75
|
cd my-app
|
|
76
76
|
pnpm openxiangda context --json
|
|
77
77
|
pnpm openxiangda dev
|
|
@@ -174,9 +174,9 @@ MCP 的 `docs_read` 可以读取本说明,当前没有独立的源码操作 MC
|
|
|
174
174
|
无需本地工作区,使用本 Skill 随包精确版本或已安装的对应 CLI:
|
|
175
175
|
|
|
176
176
|
```bash
|
|
177
|
-
pnpm dlx openxiangda@2.
|
|
178
|
-
pnpm dlx openxiangda@2.
|
|
179
|
-
pnpm dlx openxiangda@2.
|
|
177
|
+
pnpm dlx openxiangda@2.31.0 auth status --base-url <平台> --json
|
|
178
|
+
pnpm dlx openxiangda@2.31.0 source resolve <仓库URL> --base-url <平台> --json
|
|
179
|
+
pnpm dlx openxiangda@2.31.0 source clone <仓库URL> <新目录> --base-url <平台> --json
|
|
180
180
|
```
|
|
181
181
|
|
|
182
182
|
登录缺失或站点不匹配时,先按该平台执行 login。resolve 根据平台已经登记的绑定返回
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# 缓存、排队与整数配额
|
|
2
|
+
|
|
3
|
+
`data.concurrency` 是可选的平台声明,用于限量申领、抢票和预约。平台负责缓存回源、等待资格、持久受理、受控 Native 事务及整数配额;应用通过 `openxiangda/react` 或 `openxiangda/mobile` 调用。平台必须声明能力 `data.managed-concurrency@1.0.0`。旧平台会在编译/发布能力检查阶段拒绝此声明。
|
|
4
|
+
|
|
5
|
+
## 声明与权限
|
|
6
|
+
|
|
7
|
+
完整且由双编译器测试验证的示例位于源码 `examples/managed-concurrency/declaration.ts`。调用 `defineOpenXiangdaApp(concurrencyExample())` 即可编译。把示例中的 `data.concurrency` 合入应用配置,并按实际业务配置模型和参与权限。
|
|
8
|
+
|
|
9
|
+
| 声明 | 作用 |
|
|
10
|
+
| --- | --- |
|
|
11
|
+
| `reads` | 命名读取、有限参数、字段、条件、权限范围、新鲜期、旧值期限、失效字段和回源预算 |
|
|
12
|
+
| `admission` | 本应用/环境所有命令共享的每秒速率、突发额度、在途上限 |
|
|
13
|
+
| `commands` | 当前用户的能力、按资源分队列、最长等待、处理截止、Native 守卫和原子写入 |
|
|
14
|
+
| `quotas` | 容量来源、业务记录上的分配 ID、可选的预占到期时间 |
|
|
15
|
+
|
|
16
|
+
参数限于 UUID、有限字符串枚举和有限整数范围;绑定只接受 `input`、可信 `actor`、字面量和平台生成的 `allocation`。每个命令最多 8 个操作、8 个记录守卫。首版不执行应用任意 JS/SQL,也不在锁内调用外部系统。通知和外部副作用接已有事务后事件。
|
|
17
|
+
|
|
18
|
+
配额来源模型的容量字段必须是整数;分配记录模型的引用字段必须是必填 UUID,模型设置 `mutationOwner: 'queued-command'`。角色仍须具备来源读取、分配模型创建和命令能力。普通 CRUD、导入、应用凭据均不能绕过命令所有权。用户身份由 `actor` 绑定,不能使用用户填写的人员编号决定名额归属。
|
|
19
|
+
|
|
20
|
+
`database-now` 条件使用数据库时间,并按“字段 操作符 当前时间”解释。例如截止前允许报名:`{ kind: 'database-now', field: 'closesAt', operator: 'gt' }`。资格和业务截止在执行时重验,因此等待或已受理不等于一定成功。
|
|
21
|
+
|
|
22
|
+
## 展示读取
|
|
23
|
+
|
|
24
|
+
```ts
|
|
25
|
+
const client = createManagedConcurrencyClient();
|
|
26
|
+
const snapshot = await client.read('offer', { id: selectedOfferId });
|
|
27
|
+
// snapshot.items、generatedAt、freshUntil、staleUntil、version、freshness
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
在平台身份初始化完成后创建并保持 `client` 实例稳定。它绑定应用、环境和当前用户;切换身份后旧客户端拒绝继续操作。组织内共享内容也要求登录与当前权限。`scope: 'application'` 不允许行策略或 actor 条件;个人/有行策略的数据使用 `scope: 'subject'`。
|
|
31
|
+
|
|
32
|
+
每次访问仍通过平台现有身份、版本与字段权限链路。缓存减少内容查询;不能据此宣称整个请求零 SQL。活动内容和余量使用不同读取声明与依赖,避免每次报名使详情失效。`dependencies` 必须覆盖返回和过滤字段。Native 提交在同一事务写失效事实,恢复任务负责可靠推进;变更传播有延迟,要求即时资格或即时关闭的判断必须放在命令守卫中。
|
|
33
|
+
|
|
34
|
+
冷缓存使用进程请求合并与跨副本刷新租约,短暂争用返回可重试响应。负缓存最长 5 秒,TTL 带随机抖动。可在应用版本激活后,用正常授权的 `read` 调用预热有限的热点 ID。首版提供认证后的 Redis/进程缓存,不提供公共 CDN 发布或自动扫描全量数据预热。
|
|
35
|
+
|
|
36
|
+
## 提交与原结果恢复
|
|
37
|
+
|
|
38
|
+
```tsx
|
|
39
|
+
import { useMemo } from 'react';
|
|
40
|
+
import { createManagedConcurrencyClient, useManagedCommand,
|
|
41
|
+
ManagedCommandStatus } from 'openxiangda/react';
|
|
42
|
+
|
|
43
|
+
export function Claim({ offerId }: { offerId: string }) {
|
|
44
|
+
// 父级在平台身份就绪后挂载;身份变化时重新挂载此子树。
|
|
45
|
+
const client = useMemo(() => createManagedConcurrencyClient(), []);
|
|
46
|
+
const command = useManagedCommand({ client, command: 'claim',
|
|
47
|
+
input: { id: offerId }, storageKey: offerId });
|
|
48
|
+
return <>
|
|
49
|
+
<button disabled={command.state !== 'idle'}
|
|
50
|
+
onClick={() => void command.start().catch(() => {})}>申请</button>
|
|
51
|
+
<ManagedCommandStatus snapshot={command} />
|
|
52
|
+
{command.state === 'error' && <button
|
|
53
|
+
onClick={() => void command.resume().catch(() => {})}>恢复原操作</button>}
|
|
54
|
+
</>;
|
|
55
|
+
}
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
挂载只恢复已有请求,用户调用 `start()` 才创建新意图。默认以 `sessionStorage` 保存原请求键及恢复资料,刷新后继续查原结果;浏览器禁止存储时明确失败,不自动改用易丢失的内存状态。可传入同接口的可靠存储。不要另写循环换请求键重试。
|
|
59
|
+
|
|
60
|
+
等待阶段只轮询签名票据,不重复查业务数据。SDK 遵守建议间隔并加抖动,故障时逐步退避至约 30 秒。组件卸载或 `stop()` 只停止观察,不取消已受理命令。取消使用 `cancel()`,会核对原命令并处理与受理竞争的情况。只有已知终态才能 `clear()` 开始新意图。
|
|
61
|
+
|
|
62
|
+
需要先排队再加载重型页面时,设置 `autoAccept: false`,用 `ManagedCommandGate` 的 `children={() => <HeavyContent />}` 延迟构建子树;用户确认后调用 `submit()`。命令输入在排队时固定。它不替代整站认证、应用启动元数据或未使用此能力的接口预算,也不能保护提前在父组件发起的请求。
|
|
63
|
+
|
|
64
|
+
| 状态 | 含义 |
|
|
65
|
+
| --- | --- |
|
|
66
|
+
| `waiting` / `admitted` | 等待/获准受理,尚未占名额 |
|
|
67
|
+
| `accepted` / `executing` / `retry_wait` | 已持久受理,平台继续处理 |
|
|
68
|
+
| `succeeded` | 权威事务已提交,原结果可恢复 |
|
|
69
|
+
| `rejected` / `expired` / `cancelled` | 明确终态 |
|
|
70
|
+
| `recovering` / `error` | 正在核对/暂时无法确认,保留原请求键 |
|
|
71
|
+
|
|
72
|
+
## 配额和发布边界
|
|
73
|
+
|
|
74
|
+
立即分配用 `quota.action: 'allocate', mode: 'committed'`;需要预占时声明 `reservationSeconds` 并用 `mode: 'reserved'`。另声明 `confirm`、`release` 命令,绑定原 `allocation`,该命令的 `operations` 为空。只有原主体可确认/释放;到期与确认竞争使用数据库时间及固定锁顺序。
|
|
75
|
+
|
|
76
|
+
原命令回执不可变。预占之后到期或释放,应调用 `client.allocation(allocationId)` 获取当前分配状态,不能用旧成功回执证明仍持有名额。首版同一池/主体保留永久去重事实,释放后不会自动重新报名;应用若需要新一轮,应使用新的权威资源/配额池,不能删除历史分配。
|
|
77
|
+
|
|
78
|
+
容量减少不能低于已预占加已确认数量。存在配额历史时,禁止删除来源、改写分配引用或发布移除配额映射的版本。应用激活先排空所有非终态命令;不会让旧任务在新 Head 上执行。连接开发消费已激活测试版本的并发声明,未激活的本地模型覆盖层不能作为持久命令契约。
|
|
79
|
+
|
|
80
|
+
## 资源上限与故障处理
|
|
81
|
+
|
|
82
|
+
| 边界 | 首版硬上限 |
|
|
83
|
+
| --- | --- |
|
|
84
|
+
| 每应用/环境等待 | 128 个资源队列、合计 10000 人,同时受声明的更小上限约束 |
|
|
85
|
+
| 缓存 | 单值 256 KiB;应用/环境累计 32 MiB、2048 个有效键;进程 L1 最多 256 个条目 |
|
|
86
|
+
| 回源 | 每进程 2 个、每应用跨副本 2 个;应用合计 20 次/秒并受声明预算限制 |
|
|
87
|
+
| HTTP | 并发能力普通入口每进程 8 个,查原结果独立 4 个 |
|
|
88
|
+
| worker | 每进程最多 2 个,同一资源通过数据库事务锁协调 |
|
|
89
|
+
|
|
90
|
+
Redis 不可用会停止新准入和缓存回源,绝不把所有请求直接放到数据库。已持久受理命令依赖 PostgreSQL 和现有 RabbitMQ 恢复;原结果在 Redis 故障时每进程最多 4 次/秒、4 个并发可回查。Redis 丢失会重建在途事实并换票据世代,临时等待位置可能变化。
|
|
91
|
+
|
|
92
|
+
RabbitMQ 的消息只是唤醒提示;队列丢失或发布失败由数据库恢复,重复消息读取同一命令。锁等待或慢执行触发有界重试与应用短暂暂停放行。系统并不承诺跨队列严格公平,也不承诺一旦排队就必定获票。
|
|
93
|
+
|
|
94
|
+
管理员可使用同源 POST `/openxiangda-api/v2/applications/:appCode/native/concurrency/status`,请求带 `environmentKey`,查看非终态数量/最早时间、最多 100 个配额池及当前进程缓存指标。`control` 接收 `{ environmentKey, paused: true }` 停止新受理;只允许应用超级管理员。停用或回滚前停止受理、排空命令、保留配额与原结果;不得通过删锁、删队列数据补偿业务。
|
|
95
|
+
|
|
96
|
+
暂停/恢复按同一个环境锁串行传播;Redis 不可用时控制接口明确报错。控制值是绝对值,可以使用相同 `paused` 重试并核对状态。数据库提交确认丢失时不猜测控制结果;受理始终复查数据库的暂停状态。
|
|
97
|
+
|
|
98
|
+
验证应包括内容 SQL 与授权 SQL 占比、每秒完成数、P95/P99、最老等待、连接数、锁等待和恢复时间。仓库故障测试证明协议边界,不代表任何客户环境的生产吞吐。部署者仍需使用目标硬件、真实权限和活动规模做容量验收。
|