积分存盘域扩容流程梳理
bug 详细内容见文档：2025-07-17-bug：积分存盘域扩容导致7321个用户读写存档失败.md
背景
班车赛存盘积分域为 22 位，2025 年 6 月要上线 “挥镐掘金” 业务，在该业务场景下，22 位的存盘积分域不能满足需求，需要对班车赛存盘域进行扩容。
经讨论，汇总了 687 个存盘积分域 id（班车赛的），需从 22 位扩容至 50 位（50 是为了一步到位，避免以后重复操作）。
在扩容过程中，因为历史原因，出现了一些报错，现将存档积分扩容的流程和注意事项总结在此，方便以后操作时参阅。
涉及服务
-
EVT：手动操作 MySQL 配置，对目标积分域的配置进行修改（扩容）。
-
CMT：增加积分域的映射，包括两部分：对已有积分域扩充映射；对后续新的积分修改存档映射模板。
-
pc 客户端：需确认是否存在存档位数校验的逻辑（理论上 2025.6.29 更新后就不存在校验的逻辑了）。
-
比赛：测试使用逻辑。
全部门扩容流程（更新至 2025.7）
-
EVT 通过内网测试、人工确认两种方式确保配置能够上线成功。
-
EVT 对外网配置做好备份。
-
EVT 与 CMT 沟通，挑选部分典型存档积分域进行扩容测试。（测试流程与正式相同，见下）
-
EVT 与 CMT 沟通，明确更新时间点。通知客户端、运维、比赛的同事协助监控异常。
-
CMT 做好扩容准备。
-
EVT 手动更新外网的积分域配置，并监控 EVT 日志是否有报错，若有报错及时同步、修复、回退。
-
CMT 根据日志检查没有问题，手动提工单增加给定名单内积分域的存档映射。
-
观察半天有无报错；若没问题，CMT修改存档映射模板，后续从MIS新提交的存档映射使用新的配置。
-
扩容完成。
EVT 扩容流程
- 使用脚本《HsbPyBatchAdd.py》指向本地 MySQL 数据库进行操作；
- 先预操作，检查日志是否有错误；
- 更新内网数据，并检查内网数据是否符合预期；
- 将外网数据导出为 csv；
- 将该 csv 文件导入到本地 MySQL；
- 脚本指向外网导入到本地的表中，执行完毕；
- 检查数据没有问题后，将本地数据导出为 csv；
- 扩容外网：将该 csv 文件导入到外网 MySQL 表，注意导入时选择 “REPLACE INTO”，保证整体覆盖。
- 外网先扩容 58608（来自史冉军），等比赛开发完以后，用这个存盘积分域进行测试。
- 没有问题，且体验结束前，将外网所有目标存盘域进行扩容即可。
- 所有目标存盘域见文件《存档查询.csv》（来自叶强）。
相关内容
1）扩容存盘域积分对延迟的影响评估
评估结论：
将 700 个存盘积分域中的积分从 22 个扩容至 50 个，不会产生明显的读写延迟下降等异常现象。
jgbc 集群现状：
redis 集群现状：（matchsave-001-redis）（2025年6月6日）
redis 集群表现：（24h内）
EVT-HEB 时延表现：（24h内）
EVT-HEB 查询量统计：（24h内）
2）回退流程
背景：
在 EVT 和 CMT 都完成扩容后，若其它部门反馈有问题，需及时进行回退。
此时 EVT 和 CMT 的回退步骤和时间间隔需注意。
若不遵守此流程会导致 CMT 在写入时存在报错。
回退流程：
-
CMT 先提工单对配置进行回退，并回退存档映射模板。
-
观察半小时，确保已进入比赛的用户能拿到新的存档映射配置。
-
EVT 进行回退。
3）存盘积分域位数
背景：
本次扩容时发现存在 4 位存盘域与 5 位存盘域中积分id冲突的问题。
解决方式：
下线所有冲突的 4 位积分域，截止 2025.6.25，已下线成功。
4）优化补发流程
存档和清档操作由比赛服务发起，异步发给 CMT，比赛服务无法定位错误消息，所以名单现在只能 CMT 提取。CMT 失败日志信息不足，给补发增加了难度，主要体现在：
-
无法区分存档和清档操作
-
日志没有 MPID，补单数据需要二次加工
-
存档协议没有比赛阶段参数，没法精确定位补发金额
现组委会内部先优化前 2 点，第 3 点待后续跟比赛沟通实施方案后再推进。