案例分析论文

2021年冬天，案例我接手了一个案子。分析客户是论文家做社区团购的小公司，技术团队六个人，案例后端用PHP写的分析一套系统，日订单量最高冲到过八万。论文问题出在数据库上——MySQL单实例，案例没做读写分离，分析大促时CPU直接打满，论文订单丢了不少。案例他们试过加索引、分析优化SQL，论文撑了两周又不行了。案例

这个案例本身不复杂，分析但有意思的论文是团队对"技术升级"的理解偏差。CTO坚持上微服务，说这样才能"彻底解决扩展性问题"。我问他：你现在的瓶颈是数据库连接数不够，拆成十个服务，每个服务连同一个库，连接池翻十倍，问题只会更严重。

他沉默了。

后来我们没动架构。做了三件事：第一，把订单写入改成异步，用Redis队列缓冲；第二，对订单表做了垂直拆分，把支付信息和商品快照拆到独立表；第三，读操作全部走从库，主库只负责写。两周后大促，峰值到了十二万单，数据库负载反而降了四成。

说这个案例不是要否定微服务。我想说的是，很多技术决策的出发点不是问题本身，而是"别人都在用"。那个CTO后来跟我喝酒，承认他当时在准备跳槽，简历上需要一个微服务项目。这很真实，技术人的职业诉求和系统实际需要之间，经常存在这种错位。

类似的事我见过不少。2022年一家做SaaS的创业公司，非要用Kubernetes部署一个日活不到两千的应用。运维成本高得离谱，招个懂K8s的工程师月薪三万起，结果大部分时间在调网络插件。我问他们为什么不用Docker Compose，回答是"不够正式"。技术选型里的面子工程，比想象中普遍。

回到案例本身。订单异步化那一步，其实有风险。Redis挂了怎么办？我们当时做了降级方案：队列不可用时，直接写数据库，同时触发告警。这个逻辑不优雅，但保证了核心链路不断。很多方案在PPT上很漂亮，一遇到异常路径就露馅。工程和学术的区别就在这里——前者必须处理不完美。

垂直拆分那张订单表，字段从四十多个砍到十二个。原先的设计是"一张表搞定所有"，结果每次查询都要拖着一堆大字段。拆完之后，主表体积缩小了七成，缓存命中率上去了。这个改动没有任何技术含量，就是体力活，但效果立竿见影。有时候解决问题不需要新工具，需要的是把旧工具用对。

读从库那部分遇到了主从延迟。用户下单后立刻查订单列表，偶尔查不到。我们加了个判断：写入后五秒内的查询强制走主库。这个时间窗口是拍脑袋定的，但线上跑了半年，没出过问题。精确的理论计算当然更好，可工程实践中，"够用"往往比"最优"更实际。

这个项目结束后，我写了一份内部复盘。核心结论就一句话：先搞清楚瓶颈在哪，再决定用什么工具。听起来像废话，但大多数团队跳过了这一步。他们从"我想用什么"出发，而不是"问题需要什么"。

数据库后来还是换了，换成了TiDB。那是2023年的事，订单量到了日均五十万，MySQL分库分表维护成本太高。这次是问题推着技术走，不是反过来。CTO也换了人，新来的那位第一句话就问："咱们现在的写入瓶颈具体在哪个环节？"我心想，这回对了。