Sharding数据源熔断方案

一、缘起

系统使用sharding分库分表共8个分库,其中一个分库因为某种特殊情况响应极慢,导致每个请求都要等待请求超时,针对这个分库的请求夯住、导致Dubbo线程池被占满,最终整个应用不可用。

二、需求分析

一次sharding操作会被路由到不同分库上执行。理论上一个分库挂掉,也只是1/8的请求不可用。

这种库还活着但是响应异常缓慢的特殊状况,会导致整个应用的不可用,对这种情况我们需要及时发现,进行适时的熔断,保护整个应用。

期望
1、单个分库异常快速发现、并失败。
2、单个分库异常不影响其他分库请求处理。

可能导致请求夯住的点:
1、获取数据库连接超时导致请求夯住
2、分库操作响应极其缓慢,所有请求要等待超时才能返回,导致请求夯住

三、方案设计

1、熔断方案

使用阿里 sentinel 针对sharding 操作以分库为单位,在获取链接、sql执行两个点对特定异常(可能导致请求夯住的异常)监控统计,到达某个临界点时进行熔断。
code 示例:

  Entry entry =
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值