服务容错的概念以及解决方案
服务雪崩
我们可能有人了解过缓存雪崩，例如redis的缓存雪崩，就是大量的缓存数据都是在同一个时间段内失效，这样就类似于雪崩一样的大量的请求都到了数据库，自然数据库就受不了了，这个解决方式就是把失效时间给分布开来即可，下面给与一些缓存故障：
1.缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
2.缓存击穿：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
3.缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
那么类似于缓存雪崩，服务也有服务雪崩这么一说，当微服务之间相互调用，其中如图假若C服务出现故障，那么调用C服务的接口就会Timeout，然后就引起了B服务的时常，然后再继续引起调用B服务的A服务的异常，这样就导致了大量服务的崩溃问题。
image.png
容器线程耗尽
如图，同样的如果C服务有故障，调用容易超时，那么直接或者间接调用C服务线程就迟迟得不到释放，然后请求不会减少，还是一如既往的过来，这个时候线程就越来越少，进而终于导致了容器的线程耗尽的问题。
image.png
生产故障的一个案例
服务雪崩或者说容器线程耗尽的情况往往是从延迟或者故障开始，然后导致服务的不可用，最终就会造成盈利或者资金的损失了。
image.png
如何降低故障影响
上面列举了很多问题，那么如果解决这些问题呢，我们从源头上分析，一个就是减压，当服务不可用的时候就直接快速的失败，不要再消耗资源了，释放掉线程；还有一个就是备选方案，保障最小可用性，因为类似于苟且偷生所以就就叫做降级，虽然性能不行，但好歹死不了，是个备选方案。
image.png
