go-zero 数据库优化实操指南：缓存 + 读写分离一页纸清单

go-zero 数据库优化实操指南缓存 读写分离一页纸清单【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero这篇笔记整理 go-zero 数据库优化的两条主线用缓存挡住重复查询用读写分离把读流量摊到从库。它不追求一次到位而是先测量、再动手每一步都能单独落地。适合刚上手 go-zero、又被慢查询和连接池报警烦到的同学。先测量再优化别急着加缓存。先把慢拆成具体的东西否则你会在一个不痛的地方使劲。三步诊断先分清是查询、连接还是慢 SQL看连接池。go-zero 默认会暴露连接数指标先确认是不是连接被占满排队、等待超时。如果是问题在并发不在单条 SQL。看慢查询。开数据库慢日志按耗时排序找出真正拖后腿的几条。往往前 3 条就占了大头。看命中重复。对同一张热点表统计有多少查询其实是相同参数的重复打比如按id反复拉同一条记录。这部分最适合用缓存吃掉。拿到这三组数字你才知道该优先上缓存、还是该上从库、或者两者都要。没有这一步后面就是猜。核心手段一让缓存挡掉重复查询go-zero 的缓存在core/stores/cache/cache.go核心是一个Take/TakeCtx调用先查缓存命中就返回没命中才执行你给的查询函数然后把结果写回缓存。取数这段逻辑框架替你写死了你不用手写查缓存→没命中查库→回填那一串。go-zero 缓存一个 Take 调用搞定取数// core/stores/cache/cache.go 的 Cache 接口 err : cache.TakeCtx(ctx, resp, cacheKey, func(v any) error { // 只有缓存未命中时才会执行到这里 return conn.QueryRowCtx(ctx, v, SELECT * FROM rooms WHERE id ?, id) })这里query函数是未命中时的回源。goctl 生成模型时可以自动把缓存接进去MySQL/Postgres 走core/stores/sqlc/Mongo 走core/stores/monc/比如生成的FindOne内部就是mm.cache.TakeCtx(ctx, v, key, ...)。你业务代码里不用自己记 key、自己 Set。go-zero 缓存穿透与击穿空值 单飞穿透查不存在的 id给查不到的结果也缓存一个短过期时间别让它反复打到库上。击穿热点 key 刚过期一波请求同时回源Take内部挂了core/syncx/singleflight.go的单飞屏障同一 key 同时只有一个请求去查库其余的等它。这块是框架内置的不是你手写的。雪崩大量 key 同一时刻过期基础过期时间上再加一点随机偏移把失效点打散。缓存键建议带上稳定前缀比如room#id#123便于排查和按前缀清理。核心手段二把读流量分摊到从库读多写少的系统把所有读都压在一条主库连接上是最浪费的一种姿势。go-zero 在core/stores/sqlx/里支持主从分离配置就在core/stores/sqlx/config.goDataSource是主库Replicas是若干从库Policy控制从库之间的挑选方式。从库分流配置DataSource: root:passtcp(mysql:3306)/im # 主库承接所有写 Replicas: # 从库可选、可多个 - root:passtcp(replica1:3306)/im - root:passtcp(replica2:3306)/im Policy: round-robin # round-robin轮询或 random随机三种读法怎么选路由逻辑在core/stores/sqlx/rwstrategy.go。注意一个容易踩的点默认读走的是主库只有你显式声明这条读走从库它才会去从库。三个入口// 写操作天然落主库 ctx : sqlx.WithWrite(ctx) // 普通读、能容忍一点点延迟最终一致即可走从库 ctx : sqlx.WithReadReplica(ctx) // 写完之后立刻要读到最新值强制读主库避开主从延迟 ctx : sqlx.WithReadPrimary(ctx)所以不是配了从库就自动分流而是每条读你自己选走哪边。把列表、详情这类看个大概就行的读放到WithReadReplica把刚改完马上回显的读钉在WithReadPrimary。两招合起来看一个 IM 聊天室改造拿即时通讯的聊天室来说。痛点很典型一个房间的资料房名、成员数、置顶公告会被房里所有人反复拉取读远多于写但偶尔又要求我刚改完房名自己这边立刻得看到新名字。改造分三步给房间资料加缓存。FindOne走TakeCtx热点房间的同一份资料一个进程内只回源一次单飞挡掉击穿。把列表类读摊到从库。拉房间列表、拉历史置顶这种批量读ctx sqlx.WithReadReplica(ctx)让主库专心处理进房/退房/改房名这些写。写后立即读钉主库。改完房名的那次回显用WithReadPrimary避免从库还没同步好读到旧名字。// 拉取房间资料缓存兜底 从库分流 func RoomProfile(ctx context.Context, roomID string) (*Room, error) { ctx sqlx.WithReadReplica(ctx) // 批量读走从库 return roomModel.FindOne(ctx, roomID) // 内部 TakeCtx 自动带缓存 } // 改名后立刻回显强制读主库绕开主从延迟 func RefreshOwnRoom(ctx context.Context, roomID string) (*Room, error) { ctx sqlx.WithReadPrimary(ctx) return roomModel.FindOneNoCache(ctx, roomID) // 这条不走缓存保证最新 }改造前后的量级差异示意值按你实际压测填观测项改造前改造后房间资料接口 P99 延迟~380ms~20ms打到主库的读流量占比~95%~30%热点房间资料缓存命中率0~92%改名后读旧值的偶发投诉有基本消失数字别直接抄拿你自己那条链路压一遍。方向是对的读被缓存吃掉一部分、剩下的读摊到从库、写和强一致读留在主库。一页纸调优清单把上面收拢成能照着勾选的动作从上往下过一遍即可测量确认慢在连接池、慢 SQL 还是重复查询而不是感觉慢。缓存键统一前缀 类型 id如room#id#123别用会变的字段拼 key。穿透给查无结果也缓存一个短过期挡住恶意/无效 id。击穿确认走的是框架Take内含core/syncx/singleflight.go单飞不是手写的裸回源。雪崩基础过期时间上叠随机偏移别整批同秒失效。过期时长业务资料短一点分钟级配置类长一点别一刀切。从库分流DataSourceReplicasPolicy配好确认读确实打到了从库。读法显式声明默认读走主库该走从库的读记得WithReadReplica。写后立即读用WithReadPrimary钉主库别赌主从同步速度。一致性更新走先改库、再删缓存别让旧值赖在缓存里。监控盯缓存命中率和主从延迟两个数设告警阈值别等用户先发现。生成代码模型用 goctl 生成让它把缓存和读法按最佳实践接好少手写。按这个顺序走每一步都能独立见效、独立回滚。先让数字说话再决定加哪一招。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考