《即时消息技术剖析与实战》学习笔记11——IM系统如何保证服务高可用

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

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

1、流量控制

在即时消息系统中，突发超高流量时，为了不服务器总体被流量打死，咱们能够经过流控来扔掉或者经过排队的方式来保护系统在能力范围内的运转。

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

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

2、熔断机制

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

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

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

3、总结

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

后记

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