即时消息技术剖析与实战
袁武林
微博研发中心技术专家
立即订阅
6503 人已学习
课程目录
已完结 24 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
免费
基础篇 (8讲)
01 | 架构与特性:一个完整的IM系统是怎样的?
02 | 消息收发架构:为你的App,加上实时通信功能
03 | 轮询与长连接:如何解决消息的实时到达问题?
04 | ACK机制:如何保证消息的可靠投递?
05 | 消息序号生成器:如何保证你的消息不会乱序?
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
08 | 智能心跳机制:解决网络的不确定性
场景篇 (4讲)
09 | 分布式一致性:让你的消息支持多终端漫游
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
11 | 期中实战:动手写一个简易版的IM系统
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
进阶篇 (10讲)
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
16 | APNs:聊一聊第三方系统级消息通道的事
17 | Cache:多级缓存架构在消息系统中的应用
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
19 | 端到端Trace:消息收发链路的监控体系搭建
20 | 存储和并发:万人群聊系统设计中的几个难点
21 | 期末实战:为你的简约版IM系统,加上功能
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
结束语 (1讲)
结束语 | 真正的高贵,不是优于别人,而是优于过去的自己
即时消息技术剖析与实战
登录|注册

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

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

流量控制

针对超高流量带来的请求压力,业界比较常用的一种方式就是“流控”。
“流控”这个词你应该不陌生,当我们坐飞机航班延误或者被取消时,航空公司给出的原因经常就是“因为目的机场流量控制”。对于机场来说,当承载的航班量超过极限负荷时,就会限制后续出港和到港的航班来进行排队等候,从而保护整个机场的正常运转。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《即时消息技术剖析与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

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

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

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

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

    2019-09-23
    4
    2
  • 在全链路压测监控中,统计哪个模块最脆弱,得出该模块最大访问次数,实际应用中对该模块请求次数进行统计,超过最大访问次数则进行熔断
    2019-09-23
    1
  • _CountingStars
    老师,流控令牌的本地批量预取,是单线程负责维护的吗?如果多线程是不是要使用锁来控制并发修改数据问题?这样不会把请求的响应时间拉的很长吗?

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

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

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

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

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

    2019-09-23
    1
  • HelloTalk
    自动熔断机制中,如何来确认 Fail-fast 时的熔断阈值(比如:当单位时间内访问耗时超过 1s 的比例达到 50% 时,对该依赖进行熔断)?

    一方面做压力测试 另外一方面可以做半熔断机制 结合流控 只放行50%的流量。
    2019-10-06
  • Ray
    有时候一个交互需要多个接口组合。举个不恰当的例子,比如登录,要验证密码,还要验证验证码,甚至可能还要调用第三方接口做一些验证。这种场景下如果去对每个接口单独限流,必定导致整体登录失败率大大提高,请问这种场景怎么进行限流

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

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

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

    2019-09-27
  • Keep-Moving
    流控实现的两大算法:
    1. 漏桶算法
    2.令牌桶算法
    2019-09-23
收起评论
10
返回
顶部