86 lines
4.5 KiB
Markdown
86 lines
4.5 KiB
Markdown
# 172 Admin：任务主键改为采集 cj 与采购 cg 独立自增编号
|
||
|
||
- 类型：需求
|
||
- 父级大工单：#14
|
||
- 所属 MVP / 版本：#15 / MySQL schema v13
|
||
- 状态：已完成
|
||
- 日期：2026-08-12
|
||
- Gitea 工单：<http://ilaer.eicp.net:8418/chengma/cmautobuy/issues/172>
|
||
|
||
## 背景与目标
|
||
|
||
原采集和采购任务使用随机长编号，不符合客户按业务类型快速报号和
|
||
查询的需求。本任务直接修改 `tasks.task_id` 真实主键：采集任务使用
|
||
`cj1`、`cj2` ……，采购任务使用 `cg1`、`cg2` ……，两套序号独立递增。
|
||
|
||
## 最终方案
|
||
|
||
- MySQL schema v13 新增 `task_sequences`，`collect` 和 `purchase` 各占一行。
|
||
- 在创建任务的同一事务内递增序列并插入任务，依靠 InnoDB 行锁防止
|
||
并发重号；事务回滚不消耗序号。
|
||
- 存量任务按 `task_type` 、`created_at` 、旧 `task_id` 稳定排序改号，同步
|
||
迁移 `task_claims` 和 `task_syb_sources`，并清理无对应任务的孤儿领取历史。
|
||
- 两张关联表对任务主键使用 `ON DELETE CASCADE ON UPDATE CASCADE`。
|
||
- Client 把任务编号当作不透明字符串原样保存和回传；任务类型仍以
|
||
`task.type` 为准，不从前缀推导。
|
||
- 页面直接显示真实编号，保留明确的“类型”文字列和编号搜索。
|
||
|
||
与建单方案的差异：序列值列最初拟名 `last_value`，真实 MySQL 8.4 验证发现
|
||
它与窗口函数关键字冲突，在进入生产前改为 `current_value` 并重新通过全部
|
||
迁移测试。
|
||
|
||
生产部署前发现 schema v13 已于 2026-08-12 09:16（中国时间）被另一个连接
|
||
生产库的当前源码进程触发。部署前逐项核对表结构、5 条任务、序列、关联
|
||
外键和采购结果，确认它正是本工单迁移且数据完整后，再部署匹配 v13 的新
|
||
二进制。
|
||
|
||
## 改了哪些
|
||
|
||
- `admin/repository/mysql_db.go`：新增 v13 迁移、存量改号、外键和 schema 自检。
|
||
- `admin/repository/task.go`：新增事务内的采集/采购独立发号器。
|
||
- `admin/service/pdd.go`、`admin/service/purchase_workflow.go`：所有采集和采购
|
||
创建入口改用新发号器。
|
||
- `admin/repository/mysql_db_integration_test.go` 及 service 测试：覆盖升级、重放、
|
||
并发、回滚和两类任务首号。
|
||
- `docs/admin/`、`docs/client/`：同步数据模型、需求、界面和 Client 契约。
|
||
- `client/test/`：使用 `cj1/cg1` 验证 Client 原样接收新任务编号。
|
||
|
||
## 验收结果
|
||
|
||
| 验收标准 | 结果 |
|
||
|---|---|
|
||
| 采集任务从 `cj1` 独立递增，采购任务从 `cg1` 独立递增 | 通过 |
|
||
| 并发创建无重号，创建回滚不消耗序号 | 通过 |
|
||
| v12 存量主键、领取历史和顺运宝来源一致迁移，重放不二次改号 | 通过 |
|
||
| 已成功采购的订单号、下单时间和结果 JSON 不变 | 通过 |
|
||
| Client 原样接收并回传新编号，Admin/Client 契约一致 | 通过 |
|
||
| 生产 schema v13 、5 条存量任务和所有关联数据完整，新 Admin 公网可用 | 通过 |
|
||
|
||
## 测试
|
||
|
||
- 执行的命令：
|
||
- `GOTOOLCHAIN=go1.23.0 go vet ./...`
|
||
- `GOTOOLCHAIN=go1.23.0 go build ./...`
|
||
- `GOTOOLCHAIN=go1.23.0 go test ./... -count=1`
|
||
- 在独立的 `autobuy_task172_test` MySQL 8.4 基础库执行 v12→v13、重放、
|
||
16 并发发号、回滚发号和采集/采购创建测试。
|
||
- `python -m unittest discover -s test -p 'test_http_admin_gateway.py'`
|
||
- `python -m unittest discover -s test -p 'test_admin_gateway_contract.py'`
|
||
- 生产核对 schema、序列、编号正则、采购结果、孤儿关联、systemd 状态、
|
||
本机及 `https://buy.833729.com/login` HTTP 状态。
|
||
- 结果：Go 静态检查、构建和测试通过；真实 MySQL 8.4 全部目标用例通过；
|
||
Client 26 项契约测试通过；生产为 schema 13，序列为采集 3/采购 2，
|
||
5/5 任务编号合规，2/2 成功采购结果完整，无活动采购任务，公网 HTTP 200。
|
||
- **没验证到的部分**：没有为验收而在生产新建真实采购任务，避免产生不必要的真实下单风险；新建路径已在独立 MySQL 8.4 库验证。
|
||
|
||
## 遗留问题
|
||
|
||
生产 v13 由另一个连接生产库的当前源码进程在计划停服备份前触发，因此
|
||
本次只能生成迁移后备份 `autobuy-after-v13-before-9ad0675-20260812T012426Z.sql.gz`。
|
||
已确认数据完整并成功部署匹配二进制；以后生产迁移前应确保本地 `run_admin.bat`
|
||
等进程没有连接生产库。
|
||
|
||
## 相关提交
|
||
|
||
- `9ad0675` `feat: 任务改用采集采购独立序号 (#172)`
|