去年秋天我在庐山脚下待了整整三周，不是去避暑，是去给一家做智慧景区票务系统的团队做技术顾问。这家公司藏在牯岭镇往东一条岔路尽头的老别墅里，二十来号人，服务器托管在九江，前端用Vue，后端是Spring Boot混着PHP——典型的中小规模互联网企业技术栈，不新不旧，够用就行。跟他们泡了几天代码库和部署脚本之后，我攒下一些在别处不太容易听到的实战经验，跟庐山云雾一样，得凑近了才看得清。
先说一个他们票务系统里真实踩过的坑。景区闸机扫码核销的高峰期集中在早上八点到十点，那会儿并发量能冲到每秒三四百次请求。他们的做法是每个核销请求都去查一次MySQL里的订单状态，再更新核销标记。数据库连接池配了50个，结果每天早高峰连接池打满，后面排队的请求超时率飙到12%。我让他们把核销逻辑改成Redis预扣减加异步落库：闸机扫码先走Redis的DECR操作判断票券余量，成功后再扔进RabbitMQ队列慢慢写MySQL。改完第二天早高峰超时率掉到0.3%。这个思路不新鲜，但很多中小团队就是卡在“知道却不动手”的坎上。庐山那家公司之前也听过Redis缓存，但觉得“订单数据不能丢”就一直没敢用。实际上核销标记这种允许最终一致性的场景，缓存加队列就是最省事的解法。
另一个事挺有意思。他们有个后台管理页面，运营人员要批量导出某天所有核销记录做对账。最初用POI直接生成XLSX，五千条数据导出要等四十多秒，浏览器经常崩。我看了下代码，发现每写一行就往Workbook里塞一个CellStyle对象——POI的CellStyle是重量级对象，五千行乘十几个列就是几万个样式实例，内存直接爆。改成先创建好固定数量的样式模板复用，导出时间降到三秒出头。这毛病我在至少五个不同城市的项目里见过，写代码的人往往觉得“样式反正要设”，没意识到对象复用这层。庐山那哥们儿改完之后拍了下桌子说“原来不是服务器慢”。
还有个部署上的小技巧值得说。他们测试环境在庐山本地一台二手Dell服务器上跑，生产环境在九江机房，两边配置不一致导致过两次“本地好好的上线就挂”。我让他们用Docker Compose把中间件版本锁死——MySQL 5.7.34、Redis 6.2.6、RabbitMQ 3.9.11，连JDK都指定到具体小版本。镜像推到私有Harbor仓库，测试和生产拉同一个tag。这招不高级，但省掉了“你本地是8.0生产是5.7”这种低级扯皮。顺便提一句，庐山那台服务器硬盘是机械盘，Docker镜像层多了之后拉取慢得离谱，我让他们把Harbor缓存在本地SSD上，构建时间从七分钟压到两分半。小团队没预算上K8s，Compose加个私有仓库就是性价比最高的环境一致性方案。
前端那边有个细节我印象很深。他们景区导览小程序里有个地图组件，加载庐山全山景点标记点，最初一次性渲染两百多个marker，低端安卓机滑动直接卡成幻灯片。我建议改成聚合方案：缩放级别小于12时只显示聚合数字，放大后再逐级展开。用高德地图的MarkerClusterer插件半天就接完了，帧率从18帧回到55帧。写这个插件的人估计没在庐山试过——山上信号时好时坏，聚合还能减少请求次数，一举两得。
最后说个运维习惯。他们之前排查线上问题全靠翻日志文件，grep来grep去。我让他们在Spring Boot里加了个轻量级的请求追踪：每个HTTP请求生成一个traceId塞进MDC，日志格式里带上这个ID，再用grep traceId就能串起一次请求经过的所有服务和SQL。没上SkyWalking那么重，但排查“这个订单为什么核销失败”这种问题从半小时缩到两分钟。庐山那帮小伙子一开始嫌改日志格式麻烦，用了三天之后主动跑来问能不能把异步线程的MDC传递也补上——你看，工具好不好用，身体最诚实。
这些技巧没一个是教科书上的标准答案，全是蹲在具体项目里被现实抽出来的。庐山那家公司后来把票务系统撑过了国庆七天乐，峰值核销一万两千人次，没崩。技术这东西，有时候就是一层窗户纸，捅破了发现对面也没那么玄乎。
