首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >微服务稳定性|容错四大金刚:限流(二)Sentinel 中间件防护实战:MyBatis 数据库与 Redis 接入深度取舍

微服务稳定性|容错四大金刚:限流(二)Sentinel 中间件防护实战:MyBatis 数据库与 Redis 接入深度取舍

作者头像
锡东
发布2026-09-20 14:37:53
发布2026-09-20 14:37:53
860
举报
概述
对于 RPC 调用,我们可以做统一的限流防护。但数据库、Redis 这类中间件,不能直接照搬 RPC 的接入思路。 核心矛盾在于:防护粒度如何选择?是单条 SQL、单条 Redis 命令,还是逻辑数据源?接入之后会带来哪些误杀、性能风险?不同中间件的架构特性不同,答案完全不同。
文章被收录于专栏:稳定性建设稳定性建设

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、前言:出口流量防护不能一概而论
  • 二、MyBatis 数据库 Sentinel 限流落地方案
    • 2.1 业务痛点
    • 2.2 资源粒度选型:为什么选逻辑数据源
      • 为什么不用 Mapper 粒度
      • 为什么不用 dbHost 物理主机粒度
      • 和监控指标的维度差异
    • 2.3 技术实现:拦截器设计
      • 熔断与限流同时生效的机制
    • 2.4 规则配置与阈值实践
      • Nacos 配置示例
      • 限流阈值计算方法
      • 读写混合场景处理
      • 动态调优策略
    • 2.5 落地关键注意事项
      • 异常统计与规则联动
      • 与事务的协同
      • 压测 / 灰度数据源天然隔离
    • 2.6 数据库隔离:限流生效的根本前提
      • 混用的典型问题
      • 为什么混用导致限流失效
      • 隔离落地建议
  • 三、Redis 限流可行性与熔断定位
    • 3.1 结论先行
    • 3.2 为什么不推荐 Redis 做统一限流
      • 3.2.1 调用频次极高,性能开销不可忽视
      • 3.2.2 粒度两难,误杀率高
      • 3.2.3 单线程架构,限流效果有限
      • 3.2.4 已有基础兜底,限流边际收益低
    • 3.3 熔断的定位:轻量兜底
  • 四、全篇总结(限流上下篇合总)
    • 后续专题预告
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档