《即时消息技术剖析与实战》学习笔记11——IM系统如何保证服务高可用：流量控制和熔断机制

IM 系统的不可用主要有以下两个原因：
一是无法预测突发流量，即使进行了服务拆分、自动扩容，但流量增长过快时，服务已经不可用了；
二是业务中依赖的这些接口、资源不可用或变慢时，比如发消息可能需要依赖“垃圾内容识别”的 API 来进行消息内容的过滤，下推图片消息可能需要依赖图片服务获取缩略图来进行推流，会导致业务整体失败或者被拖慢而造成超时，影响服务的整体可用性。

如何保证系统的高可用呢？

一、流量控制

在即时消息系统中，突发超高流量时，为了避免服务器整体被流量打死，我们可以通过流控来扔掉或者通过排队的方式来保护系统在能力范围内的运转。

流控算法主要有漏桶算法和令牌桶算法。

漏桶算法	令牌桶算法
漏桶算法比较形象，把请求比作是水，水来了都先放进桶里，并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。	令牌桶算法控制的是一个时间窗口内通过的数据量，以恒定的速率产生令牌，然后把令牌放到令牌桶中。来一个请求，就会从令牌桶中取出一个令牌，如果此时令牌桶中没有令牌，则拒绝该请求或等待新的令牌放入桶中。若令牌桶满了，则新令牌会被丢弃，不再放入桶中。
漏桶算法通过控制数据注入到网络的速率，平滑网络上的突发流量。	令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。

二、熔断机制

当下游服务因访问压力过大而响应变慢或失败，依赖于下游的上游服务也会受到影响，出现整体性能被拖累变慢的情况，最终可能导致系统整体性能的雪崩。这种当下游服务出问题时，为了保护系统整体的可用性而暂时切断对下游服务的调用的行为就是“熔断”。

自动熔断机制主要通过持续收集被依赖服务或者资源的访问数据和性能指标，当性能出现一定程度的恶化或者失败量达到某个阈值时，会自动触发熔断，让当前依赖快速失败（Fail-fast），并降级到其他备用依赖，或者暂存到其他地方便于后续重试恢复。在熔断过程中，再通过不停探测被依赖服务或者资源是否恢复，来判断是否自动关闭熔断，恢复业务。

关于“熔断”，可以看这篇博客文章，写得很形象：分布式系统关注点(8)——99%的人都能看懂的「熔断」以及最佳实践

三、总结

限流、熔断机制和缓存，是应对系统高并发、保证系统高可用的有效利器。

后记

这篇文章于我的意义更多的是拓宽我的知识层面，让我不至于那么孤陋寡闻