即时消息技术剖析与实战
袁武林
微博研发中心技术专家
24187 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
即时消息技术剖析与实战
15
15
1.0x
00:00/00:00
登录|注册

12 | 服务高可用:保证核心链路稳定性的流控和熔断机制

本地批量预取方式降低资源压力
将流控粒度细化到毫秒级别
限制请求的平均速率
控制时间窗口内通过的数据量
平滑网络上的突发流量
控制数据注入到网络的速率
确认Fail-fast时的熔断阈值
自动熔断机制的实现框架
手动降级和自动熔断的应用
雪崩效应在多依赖服务中的影响
流控依赖资源瓶颈
细粒度控制
漏桶算法和令牌桶算法的复杂实现
中央式资源配合脚本实现全局计数器
令牌桶算法
漏桶算法
外部接口或资源依赖对业务整体可用性的影响
设计优化、服务拆分、自动扩容等优化方式的局限性
突发流量和高并发峰值业务形态下的关键技术点
自动熔断机制
全局流控
流控的常用算法
流量控制
流控和熔断机制
服务高可用

该思维导图由 AI 生成,仅供参考

你好,我是袁武林。
第 10 讲“自动智能扩缩容:直播互动场景中峰值流量的应对”中,我分析了直播互动场景中“突发流量”和“高并发峰值”业务形态下的几个关键技术点,并介绍了具体的应对方式。
但是,仅从设计优化、服务拆分、自动扩容等方面进行优化,有时候并不能完全解决问题。比如,有时流量增长过快,扩容流程还来不及完成,服务器可能就已经抗不住了。
不仅如此,在即时消息系统的很多实现中,业务上对于外部接口或者资源的依赖比较多。比如:发消息可能需要依赖“垃圾内容识别”的 API 来进行消息内容的过滤;下推图片消息时,推送服务需要依赖图片服务获取缩略图来进行推流;有的时候,当业务中依赖的这些接口、资源不可用或变慢时,会导致业务整体失败或者被拖慢而造成超时,影响服务的整体可用性。
对于上面这些问题,在实际线上业务中其实并不少见,甚至可以说是常态化。既然突发流量我们没法预测,业务上也不可能不依赖任何外部服务和资源,那么有什么办法能尽量避免,或者降低出现这些问题时对核心业务的影响呢?

流量控制

针对超高流量带来的请求压力,业界比较常用的一种方式就是“流控”。
“流控”这个词你应该不陌生,当我们坐飞机航班延误或者被取消时,航空公司给出的原因经常就是“因为目的机场流量控制”。对于机场来说,当承载的航班量超过极限负荷时,就会限制后续出港和到港的航班来进行排队等候,从而保护整个机场的正常运转。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在面对高并发场景下,保证核心链路稳定性至关重要。本文深入介绍了流控和熔断机制在高可用服务中的重要性和实现方式。首先分析了突发流量和高并发峰值对业务的影响,指出单纯的设计优化和服务拆分并不能完全解决问题。随后,详细介绍了流量控制的重要性,并深入解析了流控算法中的漏桶算法和令牌桶算法。全局流控在分布式服务场景下起到关键作用,通过中央式资源和脚本实现全局计数器的方案。另外,文章提到了在实现全局流控时需要解决的细粒度控制和流控依赖资源存在瓶颈的问题。针对突发流量,介绍了自动熔断机制,通过持续收集被依赖服务或者资源的访问数据和性能指标,实现自动触发熔断,保障系统整体稳定性和可用性。总的来说,本文通过深入浅出的方式介绍了流控和熔断机制在高可用服务中的重要性和实现方式,对于需要应对高并发场景的技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《即时消息技术剖析与实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(15)

  • 最新
  • 精选
  • 老师,前阵子志玲结婚消息引起微博瘫痪,能分析下当时具体情况吗,是哪个扩容,限流,熔断中哪个环节引起的,后面又是如何改进的

    作者回复: 抱歉,尽量不在这里讨论公司相关的话题。

    2019-09-24
    2
    13
  • 东东🎈
    老师,问个设计问题,发群消息的时候,怎么查询这个群的在线用户列表?

    作者回复: 个人觉得不需要针对群来维护在线状态,直接把所有群消息都pub给网关机,网关机根据本机维护的“当前这条消息的群的用户哪些在我本机上”这个映射来下推就可以了。

    2019-09-23
    5
    5
  • 饭团
    老师。请问做限流有好的开源代码推介吗?虽说原理很简单,但是对于没做过的人还是看看具体的实现比较好! 至于老师的问题!我感觉在服务上线前肯定会做压力测试!我们是不是可以记录下当时的各项服务的指标,当我们线上服务单位时间内服务的10%或者一个合适的比例,超过相应指标的时候就得做熔断了!

    作者回复: 单机限流推荐guava的RateLimiter,全局限流直接基于Redis+Lua写一个很简单。 对,限流阈值需要模拟压测,避免由于阈值设置太宽松导致服务仍然可能被拖死或者阈值太敏感导致一点抖动也会整体熔断。

    2019-09-23
    2
    4
  • mgxian
    老师,流控令牌的本地批量预取,是单线程负责维护的吗?如果多线程是不是要使用锁来控制并发修改数据问题?这样不会把请求的响应时间拉的很长吗?

    作者回复: 可以使用原子性的、线程安全的数据结构来存储令牌,比如AotomicLong等,这种数据结构支持一次decr多个而且能保证线程安全和高性能的。

    2019-09-23
    2
    3
  • Geek_e986e3
    感觉应该用最近请求x次 失败y次做阈值?还有老师 想问问 降级的时候一般都是怎么处理的 是直接对外反馈服务不可用吗? 或者返回之前缓存或者默认值之类的吗?

    作者回复: 失败需要熔断,超时同样也需要熔断,要不然也会把服务拖死。降级的话看情况吧,如果是旁路非核心,对用户影响不大的可以直接“轻微有损返回”,对于核心的链路的熔断,可以直接返回失败让用户重试(熔断的价值在于避免服务整体不可用),或者通过重试队列把当时失败的请求先buffer起来后续恢复后再继续处理。

    2019-09-23
    3
  • 东东🎈
    老师,对于netty的单机服务端收消息流控方案,高低水位好还是guava好?

    作者回复: netty的水位应该只是和tcp buffer相关的,如果需要消息条数维度的控制还是guava。

    2019-09-27
    1
  • kamida
    老师 如果我们要针对用户分别限流 是不是本地预取就不能用了

    作者回复: 本地预取和是否针对用户分别限流本身没有必然的依赖关系,只不过用户未读的预取如果用户太多,就意义不大了,同样可能单uid的并发小了,也没必要预取来优化了。

    2020-03-12
  • Ray
    有时候一个交互需要多个接口组合。举个不恰当的例子,比如登录,要验证密码,还要验证验证码,甚至可能还要调用第三方接口做一些验证。这种场景下如果去对每个接口单独限流,必定导致整体登录失败率大大提高,请问这种场景怎么进行限流

    作者回复: 不知道我理解对没,如果是要限制这个交互的频次,可以在这个交互的入口接口进行限流就可以呀。

    2019-09-28
    2
  • 鲁大喵
    关于分布式限流,可以关注我写过的一个基于redis的分布式限流组件,欢迎指教。基本思路就是把guava的ratelimiter用lua脚本实现,相比incr+expire这种方式,更加平滑,可以实现比较精准的控速。项目地址https://github.com/diracccc/redis-rate-limiter
    2020-10-01
    3
  • 在全链路压测监控中,统计哪个模块最脆弱,得出该模块最大访问次数,实际应用中对该模块请求次数进行统计,超过最大访问次数则进行熔断
    2019-09-23
    3
收起评论
显示
设置
留言
15
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部