校车预定平台演进：从 MySQL 裸写到 Redis + RabbitMQ 高并发架构

Sat, 15 Mar 2025 10:30:00 +0800

做这个项目的初衷不是"写一个能用的系统"，而是搞清楚一件事：中间件到底在解决什么问题？每一个组件引入之前，先把不引入的代价量化出来。所以才有了一版一版的刻意劣化测试。

项目背景

独立开发的西工大校车预定平台，技术栈 Go + Gin + Gorm + MySQL，后来逐步引入 Redis、RabbitMQ。核心业务是座位预约、库存扣减与订单管理。

面向的并发场景：热门班次开放预约的瞬间，几千人同时抢几十个座位。

我的思路是：先写一个"能跑但没做任何优化"的版本，压测，找到瓶颈，加一个组件，再压测，直到瓶颈消失。 每一步都带数据。

前置准备：基准环境与测试工具

硬件：Apple M4
MySQL：Docker 1核1G，单实例
Redis：Docker 单实例
JMeter：threads=2000, ramp-up=1s, loop=1
网络延迟模拟：tc qdisc add dev lo0 root netem delay 5ms

测试接口：POST /api/order，包含查库存、扣库存、插入订单三步操作。

为什么需要模拟网络延迟

第一个压测在本地回环上跑，MySQL 1核1G，2000 并发，结果 TPS 400+，0 错误。

但这是假象。生产环境中应用服务器到数据库服务器至少 2-5ms 的网络 RTT。 本地走 localhost 延迟为 0，意味着每个 SQL 操作节省了 5-10ms。一个请求有 3 次 SQL（查库存 + 更新 + 插入），本地比生产少了至少 15ms 的等待。2000 并发时，15ms × 2000 ÷ 1s ≈ 30 个并发一直在"多出来"的等待里打转。

RabbitMQ on GYM

校车预定平台演进：从 MySQL 裸写到 Redis + RabbitMQ 高并发架构

项目背景

前置准备：基准环境与测试工具

为什么需要模拟网络延迟