这可能是讲分布式系统最到位的一篇文章( 七 ) _分布式系统

SOP 方案与演练：产线上随时都可能会发生问题，抱着出现问题时再想办法解决的态度是肯定不行的，时间根本来不及。

提前做好对应问题的 SOP 方案，能节省大量时间，尽快的恢复系统的正常。当然平常的演练也是不可少的，一旦产线故障可以做到从容不迫的去应对和处理。

除了上述方案外，还可以考虑服务策略的使用：

降级策略：业务高峰期，为了保证核心服务，需要停掉一些不太重要的业务。如双十一期间不允许发起退款、只允许查看 3 个月之内的历史订单等业务的降级，调用服务接口时，直接返回的空结果或异常等服务的降级，都属于分布式系统的降级策略。
服务降级是可逆操作，当系统压力恢复到一定值不需要降级服务时，需要去除降级，将服务状态恢复正常。

服务降级主要包括屏蔽降级和容错降级：

屏蔽降级：分布式服务框架直接屏蔽对远程接口的请求，不发起对远程服务的调用，直接返回空结果、抛出指定异常、执行本地模拟接口实现等方式。
容错降级：非核心服务不可调用时，可以对故障服务做业务放通，保证主流程不受影响。如请求超时、消息解码异常、系统拥塞保护异常，服务提供方系统异常等情况。

笔者之前就碰到过因双方没有做容错降级导致的系统故障的情况。午高峰时期，对方调用我们的一个非核心查询接口，我们系统因为 Bug 问题一直异常，导致对方调用这个接口的页面异常而无法跳转到主流程页面，影响了产线的生产。当时对方紧急发版才使系统恢复正常。

限流策略：说到限流，最先想到的就是秒杀活动了，一场秒杀活动的流量可能是正常流量的几百至几千倍，如此高的流量系统根本无法处理，只能通过限流来避免系统的崩溃。
服务的限流本质和秒杀活动的限流是一样的，都是限制请求的流入，防止服务提供方因大量的请求而崩溃。

限流算法：令牌桶、漏桶、计数器算法。上述算法适合单机的限流，但涉及到整个集群的限流时，得考虑使用缓存中间件了。

例如：某个服务 1 分钟内只允许请求 2 次，或者一天只允许使用 1000 次。

由于负载均衡存在，可能集群内每台机器都会收到请求，这种时候就需要缓存来记录调用方某段时间内的请求次数，再做限流处理。Redis 就很适合做此事。

熔断策略：熔断本质上是一种过载保护机制，这一概念来源于电子工程中的断路器，当电流过大时，保险丝会熔断，从而保护整个电路。
同样在分布式系统中，当被调用的远程服务无法使用时，如果没有过载保护，就会导致请求的资源阻塞在远程服务器上耗尽资源。

很多时候，刚开始可能只是出现了局部小规模的故障，然而由于种种原因，故障影响范围越来越大，最终导致全局性的后果。

当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护自己以及系统整体的可用性，可以暂时切断对下游服务的调用。

熔断器的设计思路：

Closed：初始状态，熔断器关闭，正常提供服务。
Open: 失败次数，失败百分比达到一定的阈值之后，熔断器打开，停止访问服务。
Half-Open：熔断一定时间之后，小流量尝试调用服务，如果成功则恢复，熔断器变为 Closed 状态。

数据一致性

一个系统设计开发出来，必须保证其运行的数据准确和一致性。拿支付系统来说：用户银行卡已经扣款成功，系统里却显示失败，没有给用户的虚拟帐户充值上，这会引起客诉。

说的再严重点，用户发起提现，资金已经转到其银行账户，系统却没扣除对应虚拟帐号的余额，直接导致资金损失了。如果这时候用户一直发起提现，那就酸爽了。

CAP 原则

说到数据一致性，就不得不说到 CAP 原则。CAP 原则中指出任何一个分布式系统中，Consistency（一致性 C）、 Availability（可用性 A）、Partition tolerance（分区容错性 P），三者不可兼得。

传统单机数据库基于 ACID 特性（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）），放弃了分区容错性，能做到可用性和一致性。

对于一个分布式系统而言，分区容错性是一个最基本的要求。既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，会出现节点与节点之间的网络通讯。