go-zero 数据库性能优化实践用缓存与读写分离把 P99 拉下来【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero上周值班一条详情接口的 P99 从 40ms 跳到 150ms 以上数据库连接池同步顶满。排查后发现问题不在 SQL而在回源太多。这篇以 go-zero 内置的数据库性能优化组件为主线讲清楚缓存与读写分离怎么用从诊断到验证每一步都能对着监控落地。 先判断慢在哪3个信号区分库问题和访问问题上来就加索引、升配往往白忙。动手前先盯三个信号慢查询日志与库 CPU慢日志多、CPU 高企是 SQL 本身或索引的问题先修语句回源占比接口 QPS 约等于数据库 QPS、缓存未命中回源查询占比接近 100%说明每个请求都在打库是访问方式的问题库空闲但 P99 高数据库 CPU 不高服务 P99 却上去了连接池打满——多半是冗余查询多、读写没分流不是机器的事。多数慢查询告警最后都会落在访问层。先归类再开方。⚡ 处方一用 go-zero 缓存组件接管热点查询一句话原理缓存组件的TakeCtx按先查缓存、未命中查库并回填执行未命中路径由 SingleFlight 兜底同一个 key 只放一个请求去回源其余请求等结果。最小示例配置一个缓存节点再用 goctl 生成带缓存的 modelCache: - Redis: Host: redis:6379 Weight: 10goctl model mysql datasource -urlroot:123tcp(mysql:3306)/user_db -tableuser -c -prefixcache#user#适用边界缓存依赖 Redis它是新增的强依赖——Redis 抖动时Take直接报错接口跟着降级只适合 key 集合有限、读多写少的热点数据全量扫描的大结果集不要缓存框架只负责读穿透写入数据后要自己调用DelCtx删掉对应缓存否则读到旧值。 处方二一行配置开读写分离一句话原理sqlx 的SqlConf里补上Replicas从库列表和Policyround-robin 或 random即可主库仍是DataSource路由逻辑见 读写分离策略源码。最小示例DataSource: roottcp(primary:3306)/user_db Replicas: - roottcp(replica1:3306)/user_db - roottcp(replica2:3306)/user_db Policy: round-robin配置生效后默认所有读写仍走主库需要显式声明意图读操作想分流就用sqlx.WithReadReplica(ctx)把请求指到从库写后立即读的场景用sqlx.WithReadPrimary(ctx)强制回主库。适用边界事务永远在主库执行Replicas对事务内语句不生效存在主从延迟时强一致读必须切WithReadPrimary接受从库就要接受秒级旧数据读流量有明显水位差才值得配从库QPS 只有个位数的服务别为了分离而分离。 验证效果P99、连接池与回源占比三个必看指标改完不要只看感觉变快了盯三个指标接口 P99 延迟、主库连接池峰值水位、缓存回源查询占比。go-zero 的 cache 内部自带 stat 统计见core/stores/cache/cachestat.go命中与未命中可以直接接到现有监控里。至少观察 3 个完整业务日对比前后指标优化前优化后接口 P99 延迟约 150ms约 25ms主库连接池峰值水位约 90%约 35%缓存回源查询占比100%未开缓存约 8%若 P99 没降但回源占比降了回库查慢日志若两者都没变先确认缓存和从库配置真的被加载了而不是改错文件。什么时候别用边界与代价高频写热数据某个 key 每秒都被更新时缓存反复失效、反复回源删除开销大于收益这类数据直读数据库更划算。低流量服务别硬上读流量本来就不高再引入一组从库加 Redis等于平添两个故障点读写分离的前提是读多写少且读流量有水位。一致性窗口是真实存在的先更新库再删缓存的顺序也有删除失败或并发插入的窗口期账务、库存扣减这类强一致链路不要放从库读也不要走缓存。缓存与读写分离的底层逻辑都是减少回源数据库的次数、把读流量从主库搬走。顺序固定先靠指标判断问题类型再改配置和路由最后用 P99 与连接池验证。想深入实现细节直接读源码最省力缓存组件与 sqlx 读写分离。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
go-zero 数据库性能优化实践用缓存与读写分离把 P99 拉下来【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero上周值班一条详情接口的 P99 从 40ms 跳到 150ms 以上数据库连接池同步顶满。排查后发现问题不在 SQL而在回源太多。这篇以 go-zero 内置的数据库性能优化组件为主线讲清楚缓存与读写分离怎么用从诊断到验证每一步都能对着监控落地。 先判断慢在哪3个信号区分库问题和访问问题上来就加索引、升配往往白忙。动手前先盯三个信号慢查询日志与库 CPU慢日志多、CPU 高企是 SQL 本身或索引的问题先修语句回源占比接口 QPS 约等于数据库 QPS、缓存未命中回源查询占比接近 100%说明每个请求都在打库是访问方式的问题库空闲但 P99 高数据库 CPU 不高服务 P99 却上去了连接池打满——多半是冗余查询多、读写没分流不是机器的事。多数慢查询告警最后都会落在访问层。先归类再开方。⚡ 处方一用 go-zero 缓存组件接管热点查询一句话原理缓存组件的TakeCtx按先查缓存、未命中查库并回填执行未命中路径由 SingleFlight 兜底同一个 key 只放一个请求去回源其余请求等结果。最小示例配置一个缓存节点再用 goctl 生成带缓存的 modelCache: - Redis: Host: redis:6379 Weight: 10goctl model mysql datasource -urlroot:123tcp(mysql:3306)/user_db -tableuser -c -prefixcache#user#适用边界缓存依赖 Redis它是新增的强依赖——Redis 抖动时Take直接报错接口跟着降级只适合 key 集合有限、读多写少的热点数据全量扫描的大结果集不要缓存框架只负责读穿透写入数据后要自己调用DelCtx删掉对应缓存否则读到旧值。 处方二一行配置开读写分离一句话原理sqlx 的SqlConf里补上Replicas从库列表和Policyround-robin 或 random即可主库仍是DataSource路由逻辑见 读写分离策略源码。最小示例DataSource: roottcp(primary:3306)/user_db Replicas: - roottcp(replica1:3306)/user_db - roottcp(replica2:3306)/user_db Policy: round-robin配置生效后默认所有读写仍走主库需要显式声明意图读操作想分流就用sqlx.WithReadReplica(ctx)把请求指到从库写后立即读的场景用sqlx.WithReadPrimary(ctx)强制回主库。适用边界事务永远在主库执行Replicas对事务内语句不生效存在主从延迟时强一致读必须切WithReadPrimary接受从库就要接受秒级旧数据读流量有明显水位差才值得配从库QPS 只有个位数的服务别为了分离而分离。 验证效果P99、连接池与回源占比三个必看指标改完不要只看感觉变快了盯三个指标接口 P99 延迟、主库连接池峰值水位、缓存回源查询占比。go-zero 的 cache 内部自带 stat 统计见core/stores/cache/cachestat.go命中与未命中可以直接接到现有监控里。至少观察 3 个完整业务日对比前后指标优化前优化后接口 P99 延迟约 150ms约 25ms主库连接池峰值水位约 90%约 35%缓存回源查询占比100%未开缓存约 8%若 P99 没降但回源占比降了回库查慢日志若两者都没变先确认缓存和从库配置真的被加载了而不是改错文件。什么时候别用边界与代价高频写热数据某个 key 每秒都被更新时缓存反复失效、反复回源删除开销大于收益这类数据直读数据库更划算。低流量服务别硬上读流量本来就不高再引入一组从库加 Redis等于平添两个故障点读写分离的前提是读多写少且读流量有水位。一致性窗口是真实存在的先更新库再删缓存的顺序也有删除失败或并发插入的窗口期账务、库存扣减这类强一致链路不要放从库读也不要走缓存。缓存与读写分离的底层逻辑都是减少回源数据库的次数、把读流量从主库搬走。顺序固定先靠指标判断问题类型再改配置和路由最后用 P99 与连接池验证。想深入实现细节直接读源码最省力缓存组件与 sqlx 读写分离。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
