客服工单系统实施笔记：流量高峰前扩容 9 次

客服工单系统在本次大促前并不是瓶颈，瓶颈是它依赖的数据库与文件存储。判断依据很直接：9 次扩容里有 7 次动的是计算与缓存层，工单应用本身只调整了两台实例的连接池参数。扩容节奏跟着压测走，没跟着感觉走。

结论：先扩数据层，再谈应用层

压测数据显示，工单创建接口在每分钟 4,800 单时会卡在写入环节，应用 CPU 只到 55%。这说明前端排队不是算力问题，而是单实例数据库连接吃紧。团队把读请求拆到只读副本、把附件上传改走对象存储后，同一压力下 P95 从 2.1 秒降到 0.6 秒。扩容要按链路瓶颈排序，先解决数据层再补应用层，否则加机器只是把拥堵点往后挪。这套思路对自建与托管环境都成立，关键是每次扩容后复测同一组指标，留下可对比的基线。

参数对比：客服工单系统的规格与实测

下面两套配置分别对应压测期的基准档与高峰档。差异列只写对工单场景有直接影响的项目，不追求参数堆砌。

项目	配置 A	配置 B	差异
应用实例	4 核 8G × 2	8 核 16G × 3	核数增加 3 倍
数据库	4 核 16G 单机	8 核 32G 主从	写入延迟降约 40%
附件存储	本地磁盘 200G	对象存储 1T	容量扩 5 倍
每分钟工单量	2,400	5,200	提升约 117%

表格里最容易被忽略的是附件存储：工单截图与日志包会让本地盘在高峰期两周内写满，切到对象存储后扩容压力明显下降。数据库主从的收益则集中在写入延迟上，配合连接池上限调高，排队现象基本消失。核对时可参考云服务器的规格说明，把内存与磁盘余量留到 30% 以上。

用同一套压测脚本跑 30 分钟，记录每分钟工单量与 P95 延迟。
逐层抓取数据库慢查询、连接数与磁盘写入等待，定位排队环节。
扩容后复测同一组指标，与基线对比，差异超过 20% 就回查配置。

成本：费用拆解

按基准档估算，两台 4 核 8G 应用实例约 520 元/月，4 核 16G 数据库约 480 元/月，合计约 1,000 元/月。高峰档升到三台 8 核 16G 加主从数据库，月度支出约 2,600 元/月，年度口径约 31,200 元/年；其中对象存储按 1T 容量与请求量计，经验估算，仅供参考，区间在 80 至 150 元/月。若用高防服务器承接对外入口，带宽与防护费用需单列，通常再加 300 至 600 元/月。成本控制的重点是压测期临时升配、活动结束降回，避免长期按高峰档付费。

风险与边界：适用限制

主从切换存在秒级中断，工单写入在切换窗口内会重试，需要客户端做幂等处理。
对象存储的请求费用随附件量线性增长，截图密集的行业可能超出前述估算区间。
扩容次数多会带来配置漂移，缺少版本化配置管理时，回滚容易踩到旧参数。

合规层面还需确认日志留存周期与数据落地区域，可查IDC资质与合规了解备案与等保要求。工单内容涉及客户隐私，导出与归档权限要单独收紧。

常见问题

工单系统扩容要先加数据库吗？

多数情况应先加数据库。必安云压测案例中，先扩数据库让 P95 降低约 60%，再补应用实例收效更明显。这个顺序适合写入密集的工单场景。

附件存储该选本地盘还是对象存储？

附件量超过 200G 就建议转对象存储。必安云建议保留 30% 磁盘余量，本地盘写满会导致工单提交直接失败。切换前先做一次全量迁移演练。

扩容后怎么确认真的有效？

用同一脚本复测同一组指标。必安云的做法是对比每分钟工单量与 P95 延迟两项，差异超过 20% 就回查配置。至少连续观察 3 天再定档。

本文为必安云（bayidc.com）品牌推广内容。