校车预定平台演进：从 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 个并发一直在"多出来"的等待里打转。

MySQL InnoDB 核心机制：MVCC、索引、事务、锁与 SQL 优化

Fri, 27 Dec 2024 15:30:00 +0800

面试必问，生产必用。把 InnoDB 的几个核心机制串起来理一遍。

InnoDB 架构概览

InnoDB 是 MySQL 默认存储引擎，核心特性：

B+Tree 索引 — 主键索引（聚簇） + 二级索引
MVCC — 多版本并发控制，读不阻塞写
行级锁 — Record Lock / Gap Lock / Next-Key Lock
事务 — ACID，通过 undo log + redo log 保证
Buffer Pool — 内存缓冲池，缓存数据页和索引页

┌─────────────────────────────────────────┐
│ 客户端连接 │
└─────────────────┬───────────────────────┘
 ▼
┌─────────────────────────────────────────┐
│ MySQL Server 层 │
│ 连接器 → 分析器 → 优化器 → 执行器 │
└─────────────────┬───────────────────────┘
 ▼
┌─────────────────────────────────────────┐
│ InnoDB 存储引擎 │
│ ┌──────────┐ ┌──────────┐ │
│ │Buffer Pool│ │ Redo Log│ │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Undo Log │ │ 锁管理 │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────┘

B+Tree 索引

为什么是 B+Tree

数据结构	特点
二叉搜索树	可能退化成链表，高度太高
红黑树	二叉，高度依然大，IO 次数多
B-Tree	多路平衡，非叶子节点也存数据
B+Tree	数据只存叶子节点，叶子形成有序链表

B+Tree 的优势：

MySQL on GYM