KodouWZF
|
c5d19f47a2
|
perf(传输): xs_file_record.md5_code 补索引
文件入库时用 MD5 做内容去重查询（FileServiceImpl 上传后 find(md5Code)），
该列此前没有索引，每个文件入库都是一次全表扫描。解包一个含 N 个文件的
传输包就是 N 次全表扫描，300 人规模下 xs_file_record 达数万行时，
单文件入库可省几十到几百毫秒，100 个文件的包可省数秒到数十秒。
按 init 与 upgrade 双写：MySQL 版 DDL 加 KEY，PG 版加 CREATE INDEX，
新建 upgrade-20261103-transfer-perf.sql 供已上线环境增量执行
（DM8 走第 1 节，PG 走第 2 节，并给出 CONCURRENTLY 备选）。
交付包 sql/01-init-table.sql 按 README 要求从仓库整份覆盖，不手改副本。
|
2026-11-03 22:03:33 +08:00 |
|
KodouWZF
|
06fb35b984
|
perf(传输): 摆渡目录监听周期 1 分钟改为 5 秒
端到端延迟里有一半是轮询空等：收发两侧各等一次，1 分钟周期下平均空等
60 秒、最坏 120 秒，这是「一页文件也要 2 分钟」的主因，而真正干活不到 2 秒。
改成 5 秒是安全的：空目录一轮只有两次 Files.list + 过滤，开销可忽略；
Spring 的 cron 任务要等上一轮跑完才排下一轮，同一实例内不会重叠。
副作用是损坏包被更频繁重试（失败包当前不删除也不改名，mtime 最老所以
每轮排第一），彻底解决靠方案 5.2 的 .error 改名让位。
部署说明第 10 条原来写「不要改成秒级」，与新默认值矛盾，一并纠正。
|
2026-11-03 22:01:25 +08:00 |
|
KodouWZF
|
4eb67e246e
|
feat(交付): 客户侧两台服务器离线部署包
内网机/外网机各起一套栈，两台之间不开任何端口，文件只经光闸在
gate/out 与对端 gate/in 之间单向摆渡。一份 compose + 一份 config +
一份 nginx 模板，全部差异收在 .env 里。
- docker-compose.yml：5 服务只发布前端端口；app 容器 IP 锁死并由
compose 注入 -Dcode.snowflake.workid.<IP>=<WORK_ID>，绕开兜底 99
超雪花 5 位上限导致启动即崩的问题
- .env.iw / .env.ow：出厂配置与随机口令已填好，仅 MESHSAFE_SECRET
故意留占位（以 MeshSafe 侧白名单为准）；按 maintainer 决定原样入库
- install.sh iw|ow：按角色建 .env -> 自检 -> sha256 校验 tar -> 架构
核对 -> docker load 后校验 tag -> 建目录/属主/SELinux 标签 -> 起栈
并逐个等健康。修掉 pipefail 下 `grep | head -1` 静默中断、架构字段
误读 manifest.json（实际在 Config blob）、die() 未定义先被调用
- export-images.sh：就地刷新 images/*.tar、sql、.env 的 tag 与
SHA256SUMS，再打 dist 交付盘；tar 与 SHA256SUMS 由 .gitignore 排除
- sql/01+02：从 backend/db 的 PG 全量与初始数据覆盖拷贝。三个
upgrade-*.sql 的 PG 段（x_upload_config、x_file_security）已在
init-table-postgres-full.sql 内，空库跑 01->02 即完整现状
- smoke_test.py：18 条断言的现场验收，凭证全部走环境变量
- 部署说明.md：拓扑、交付清单、出厂口令表、iw/ow 差异、验收清单、
13 条已知坑
镜像 tar 不进 git，装机包由 export-images.sh 出盘。
|
2026-11-02 20:40:16 +08:00 |
|