简介这是一套面向计算机专业学生与后端开发者的电子商城实战项目源码采用 Gin 框架搭配 GORM、Redis 与 MySQL 读写分离架构适合用作毕业设计、课程设计或 Go 语言进阶练手。项目集成 JWT 鉴权、CORS 跨域、AES 对称加密并引入 ELK 日志体系、Jaeger 链路追踪与 SkyWalking 监控覆盖从接口安全到可观测性的完整后端链路。压缩包共 131 个文件以 97 个 Go 源码为主体辅以 14 个 SQL 建表与初始化脚本、7 张 png 与 2 张 jpg 架构图、2 个 yaml 及 dockerfile、makefile 等部署配置整体约 666KB结构紧凑便于快速导入运行。目前已有 387 人学习下载。读者可据此掌握读写分离落地方式、鉴权与加密实现、日志与链路追踪接入思路并参考 SQL 脚本与容器化配置完成本地部署与二次开发。1. 从一张订单表说起gingormredismysql 读写分离到底在解决什么一个电子商城最典型的压力点不是首页而是「下单」和「查订单」这两件事同时发生的时候。用户点下结算写请求打到 MySQL 主库与此同时后台运营在拉订单列表、用户在刷新「我的订单」这些读请求如果也压到同一台主库上主库的 CPU 和连接数会被读请求吃掉一大半写操作开始排队下单接口的 P99 延迟肉眼可见地往上飙。这就是读写分离要解决的核心矛盾把读流量从主库剥离出去让主库专心处理写入。这套方案的技术栈是 gin 做 HTTP 层、gorm 做 ORM、redis 做缓存和分布式锁、mysql 主从做读写分离。gin 负责路由和中间件gorm 负责把 Go 结构体映射成 SQL 并路由到正确的库redis 挡在 mysql 前面承接热点读和并发写控制mysql 主从负责数据最终一致。适合谁适合已经用 Go 写过单体商城、日订单量在几万到几十万级别、发现主库读压力明显但还没到必须上分库分表的团队。这不是银弹但在「单库还能扛住写、读已经扛不住」这个阶段它是性价比最高的一刀。2. gin 层怎么把读写请求分开中间件与连接池的配合2.1 为什么路由层就要区分读写而不是等到 gorm很多人第一反应是在 gorm 的 callback 里判断 SQL 类型读走从库、写走主库。这个思路能跑但有两个问题一是 gorm 的 callback 拿到的 SQL 已经经过一轮拼装判断SELECT前缀在复杂语句比如INSERT ... SELECT上会翻车二是业务语义上「查订单列表」和「查订单详情用于下单校验」对一致性的要求完全不同前者可以容忍毫秒级延迟后者必须读主库。这种区分只有业务层知道ORM 层猜不出来。我一般会在 gin 的中间件里根据 HTTP 方法和路由打标记把「这次请求是读还是写」显式传给后续的 handler。GET 类请求默认走从库POST/PUT/DELETE 走主库但允许 handler 内部覆盖。这样 gorm 只需要根据上下文里的标记选连接不需要做 SQL 解析。// middleware/db_router.go package middleware import ( github.com/gin-gonic/gin gorm.io/gorm ) // 用 context key 传递读写标记避免全局变量 const ( CtxDBKey db_route RouteMaster master RouteSlave slave ) func DBRouter(master, slave *gorm.DB) gin.HandlerFunc { return func(c *gin.Context) { // 默认写请求走主库读请求走从库 route : RouteSlave switch c.Request.Method { case POST, PUT, DELETE, PATCH: route RouteMaster } // 允许通过 header 强制走主库用于下单后立即查订单这种场景 if c.GetHeader(X-Force-Master) 1 { route RouteMaster } var db *gorm.DB if route RouteMaster { db master } else { db slave } c.Set(CtxDBKey, db) c.Next() } }这段中间件的逻辑说明DBRouter接收主从两个*gorm.DB实例根据请求方法决定路由。X-Force-Master这个 header 是关键设计它让业务层在「刚写完立刻要读」的场景下能强制走主库避免主从延迟导致查不到刚下的单。参数上master和slave是两个独立的 gorm 连接各自有自己的连接池配置这一点下一节展开。2.2 主从连接池参数怎么设才不翻车gorm 底层用的是database/sql的连接池主库和从库的池子要分开配因为它们的负载特征完全不同。主库连接数要克制从库可以放宽。下面是我在商城项目里常用的配置// config/db.go package config import ( time gorm.io/driver/mysql gorm.io/gorm gorm.io/gorm/logger ) func newDB(dsn string, maxOpen, maxIdle int) *gorm.DB { db, err : gorm.Open(mysql.Open(dsn), gorm.Config{ Logger: logger.Default.LogMode(logger.Warn), // 关闭默认事务读请求不需要事务开销 SkipDefaultTransaction: true, }) if err ! nil { panic(open db failed: err.Error()) } sqlDB, _ : db.DB() sqlDB.SetMaxOpenConns(maxOpen) // 最大打开连接数 sqlDB.SetMaxIdleConns(maxIdle) // 最大空闲连接数 sqlDB.SetConnMaxLifetime(time.Hour) // 连接最长存活时间避免被 mysql 主动断开 sqlDB.SetConnMaxIdleTime(10 * time.Minute) return db } func InitDB() (master, slave *gorm.DB) { // 主库连接数克制因为写操作本身耗时短但要求稳定 master newDB(user:passtcp(10.0.0.1:3306)/mall?charsetutf8mb4parseTimeTruelocLocal, 50, 20) // 从库读请求多连接数放宽 slave newDB(user:passtcp(10.0.0.2:3306)/mall?charsetutf8mb4parseTimeTruelocLocal, 200, 50) return }参数说明SetMaxOpenConns主库设 50、从库设 200是因为主库的瓶颈通常在磁盘写入和锁竞争连接开太多反而加剧上下文切换从库是读可以多开。SetConnMaxLifetime设一小时是因为 MySQL 默认wait_timeout是 8 小时但中间如果有负载均衡或防火墙空闲连接可能被静默断开设短一点让连接主动轮换避免拿到死连接报invalid connection。SkipDefaultTransaction关掉默认事务读请求不需要BEGIN/COMMIT包裹能省一次往返。提示从库连接串里建议加上readTimeout3s读请求超时快速失败不要让慢查询把从库连接池占满。3. gorm 读写分离的落地从 Session 到主从切换的完整链路3.1 用 gorm 的 Session 机制实现按请求选库gorm 本身不内置读写分离但它的Session和WithContext机制足够让我们自己接。核心思路是handler 从 gin context 里取出中间件放好的*gorm.DB用它开一个 Session 执行本次请求的所有查询。这样同一个请求内的多次查询走同一个库不会出现「第一次查从库、第二次查主库」的错乱。// repository/order.go package repository import ( context github.com/gin-gonic/gin gorm.io/gorm mall/middleware ) type OrderRepo struct { db *gorm.DB // 这里存的是从 gin context 取出的那个 } func NewOrderRepo(c *gin.Context) *OrderRepo { dbVal, _ : c.Get(middleware.CtxDBKey) return OrderRepo{db: dbVal.(*gorm.DB)} } func (r *OrderRepo) GetByUserID(ctx context.Context, userID int64) ([]Order, error) { var orders []Order // 用 WithContext 把 ctx 传进去支持超时和取消 err : r.db.WithContext(ctx). Where(user_id ?, userID). Order(created_at DESC). Limit(20). Find(orders).Error return orders, err } func (r *OrderRepo) Create(ctx context.Context, order *Order) error { // 写操作中间件已经保证这里拿到的是主库 return r.db.WithContext(ctx).Create(order).Error }逻辑说明NewOrderRepo从 gin context 取 db这个 db 是中间件根据请求方法选好的。GetByUserID走从库Create走主库。WithContext把请求的 context 传进去这样客户端断开或超时能及时取消查询释放连接。参数上Limit(20)是分页保护避免一次拉太多数据把从库带宽打满。3.2 主从延迟下「写完立刻读」怎么处理主从复制是异步的正常情况下延迟在毫秒级但网络抖动或从库压力大时可能到几百毫秒甚至秒级。用户下单成功后跳转到订单详情页如果这个详情页读从库可能查不到刚下的单用户会以为下单失败。这是读写分离最经典的坑。处理方式有三种我一般组合用第一种写操作返回主键后详情页用主键查并且强制走主库。因为按主键查很快走主库压力可控。第二种在 redis 里记录「用户最近一次写操作的时间戳」读之前检查这个时间戳如果距离现在小于主从延迟阈值比如 500ms就走主库。第三种对时效性要求不高的列表页接受延迟走从库。// service/order.go func (s *OrderService) CreateAndGet(ctx context.Context, req CreateOrderReq) (*Order, error) { order : buildOrder(req) if err : s.repo.Create(ctx, order); err ! nil { return nil, err } // 写完后把用户标记为「刚写过」5 秒内该用户的读请求走主库 s.redis.Set(ctx, fmt.Sprintf(user:write:%d, req.UserID), 1, 5*time.Second) return order, nil } // 读之前检查标记 func (s *OrderService) GetOrder(ctx context.Context, userID, orderID int64) (*Order, error) { forceMaster : s.redis.Exists(ctx, fmt.Sprintf(user:write:%d, userID)).Val() 0 if forceMaster { // 走主库查 return s.repo.GetFromMaster(ctx, orderID) } return s.repo.GetByUserID(ctx, userID) }参数说明redis 的过期时间设 5 秒是经验值覆盖绝大多数主从延迟场景。设太长会让主库读压力回升设太短覆盖不住延迟。这个标记的 key 用user:write:{userID}粒度到用户避免全局标记导致所有读都走主库。注意这个方案依赖 redis 可用。如果 redis 挂了Exists返回错误要降级为走主库宁可压力大也不能查不到数据。4. redis 在读写分离架构里的两个角色缓存与分布式锁4.1 缓存穿透、击穿、雪崩在商城场景的具体表现redis 在这套架构里不只是「加速读」它还是保护从库的缓冲层。商城里最典型的三个问题缓存穿透是有人用不存在的商品 ID 疯狂请求每次都打到从库缓存击穿是某个爆款商品的缓存刚好过期瞬间大量请求同时打到从库缓存雪崩是大批商品缓存同一时间过期从库瞬间被打满。处理方式我一般这样配穿透用布隆过滤器或者对空结果也缓存一个短过期时间的占位值击穿用单飞singleflight或者互斥锁只让一个请求去查库其他等结果雪崩给过期时间加随机偏移。// cache/product.go func (c *ProductCache) Get(ctx context.Context, productID int64) (*Product, error) { key : fmt.Sprintf(product:%d, productID) // 先查缓存 val, err : c.redis.Get(ctx, key).Result() if err nil { var p Product json.Unmarshal([]byte(val), p) return p, nil } if err ! redis.Nil { // redis 出错降级查库但要限流 return c.repo.GetByID(ctx, productID) } // 缓存未命中用 singleflight 防止击穿 v, err, _ : c.sf.Do(key, func() (interface{}, error) { p, err : c.repo.GetByID(ctx, productID) if err ! nil { return nil, err } if p nil { // 空结果也缓存过期时间短防穿透 c.redis.Set(ctx, key, , 60*time.Second) return nil, nil } data, _ : json.Marshal(p) // 过期时间加随机偏移防雪崩 ttl : 10*time.Minute time.Duration(rand.Intn(120))*time.Second c.redis.Set(ctx, key, data, ttl) return p, nil }) if err ! nil || v nil { return nil, err } return v.(*Product), nil }逻辑说明singleflight保证同一个 key 只有一个请求去查库其他请求等这个结果避免击穿。空结果缓存 60 秒防止用不存在的 ID 反复穿透。过期时间加 0 到 120 秒随机偏移让缓存不会同时失效。参数上商品缓存 10 分钟是经验值商城商品信息变更不频繁可以设长一点空结果 60 秒要短因为商品可能刚上架。4.2 分布式锁保护库存扣减避免超卖读写分离解决的是读压力但秒杀场景下写压力同样致命。库存扣减如果直接UPDATE stock stock - 1 WHERE id ? AND stock 0在 MySQL 层面是原子的但高并发下大量请求排队等行锁响应时间会很难看。我一般用 redis 分布式锁把并发收敛到数据库能承受的量级。// lock/stock.go func (s *StockService) Deduct(ctx context.Context, productID int64, num int) error { lockKey : fmt.Sprintf(lock:stock:%d, productID) // 用 SET NX EX 实现锁value 用唯一标识防止误删 token : uuid.New().String() ok, err : s.redis.SetNX(ctx, lockKey, token, 10*time.Second).Result() if err ! nil { return err } if !ok { return errors.New(系统繁忙请重试) } defer func() { // 用 lua 脚本保证「判断 token 再删除」的原子性 script : if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end s.redis.Eval(ctx, script, []string{lockKey}, token) }() // 拿到锁后走主库扣减 return s.repo.DeductStock(ctx, productID, num) }参数说明锁过期时间 10 秒要大于扣减操作的最长耗时否则锁提前释放会导致并发问题但也不能太长否则 redis 挂了锁要等很久才释放。token用 UUID释放锁时用 lua 脚本比对 token防止释放了别人的锁。这个方案在单 redis 实例下有效如果 redis 是集群模式要考虑 Redlock 或者接受极端情况下的锁失效。提示分布式锁是最后一道防线不是唯一防线。数据库层的stock 0条件必须保留锁失效时数据库兜底。5. 避坑与排查读写分离上线后最容易翻车的五个点5.1 从库延迟导致数据不一致现象用户下单后跳转订单列表列表里没有刚下的单刷新几次才出现。原因主从复制异步写主库后立刻读从库从库还没同步到。解决用第 3.2 节的 redis 写标记写完 5 秒内该用户读走主库或者对时效性要求高的查询强制走主库。5.2 连接池配置不当导致连接耗尽现象服务运行一段时间后报too many connections或connection refused。原因主从连接池的MaxOpenConns加起来超过了 MySQL 的max_connections或者连接泄漏查询后没释放。解决算好总连接数主库 50 从库 200 250MySQL 的max_connections要设到 500 以上留余量检查代码里有没有手动db.DB()拿连接后忘记Close。5.3 gorm 的 Preload 在从库上触发 N1现象订单列表接口响应慢日志里看到大量单条查询。原因用了Preload加载关联数据但没注意关联查询也走了从库且没有索引。解决给关联字段加索引或者对复杂关联查询强制走主库因为主库通常有更完整的索引和缓存。5.4 redis 缓存与数据库不一致现象商品改了价格缓存里还是旧价格用户看到错误价格下单。原因更新数据库后没有删缓存或者删缓存失败。解决更新数据库后立即删缓存不是更新缓存删失败要重试对一致性要求高的场景用「先更新数据库再删缓存」 延迟双删。5.5 分布式锁超时导致并发扣减现象秒杀时库存扣成负数。原因锁过期时间设太短扣减操作还没完成锁就释放了另一个请求拿到锁继续扣。解决锁过期时间要大于操作最长耗时扣减操作本身要快不要在锁内做网络调用数据库层保留stock 0条件兜底。6. 验证读写分离是否真的生效三个可落地的检查手段上线读写分离后怎么确认读真的走了从库、写真的走了主库我一般用三个手段交叉验证。第一个在 MySQL 主从库上分别开 general log观察 SQL 落在哪个实例。主库的 log 里应该只有写操作和少量强制走主库的读从库的 log 里应该是大量 SELECT。这个手段最直接但 general log 性能开销大只在验证阶段短时间开。第二个在 gorm 的 logger 里打标记。gorm 的 logger 可以自定义在Trace方法里根据当前 db 实例打上[master]或[slave]前缀这样应用日志里就能看到每条 SQL 走了哪个库。// logger/custom.go type CustomLogger struct { logger.Interface role string // master 或 slave } func (l *CustomLogger) Trace(ctx context.Context, begin time.Time, fc func() (string, int64), err error) { sql, rows : fc() // 在 SQL 前打上角色标记方便 grep fmt.Printf([%s] %s | rows%d | err%v\n, l.role, sql, rows, err) }第三个用压测工具对比读写分离前后的主库 QPS。用wrk或hey对订单列表接口压测观察主库的Com_select指标SHOW GLOBAL STATUS LIKE Com_select是否下降。如果主库的读 QPS 明显下降、从库的读 QPS 上升说明读写分离生效了。我自己的习惯是每次改完数据库路由逻辑先在测试环境用 general log 确认一遍再上压测对比 QPS最后才上生产。读写分离这东西配置错了不会报错只会让主库悄悄扛下所有读等你发现的时候已经晚了。希望帮到你。本文还有配套的精品资源点击获取
