「这是我参与2022首次更文挑战的第16天，活动详情查看：2022首次更文挑战」。
-
CAP理论
- C：一致性。通俗来讲就是对于分布式的系统，如果一个节点改了数据，其他节点要能看到改了以后的数据。官话：通过某个节点的写操作结果对后面通过其他节点的读操作可见。如果能保证就是强一致性，如果允许部分或者全部感知不到就是弱一致性。如果能保证最后能看见，那么就是最终一致性。
- A：可用性。任何一个没有发生故障的节点，必须在有限的时间内返回合理的结果。
- P：分区容忍性。指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。
-
BASE理论 我觉得说了和没说一样，其实就是CA每一个都做了点妥协
- 基本可用：允许失去一部分可用性，就比如出现了短暂性的故障，导致返回结果的时间延长了1-2s，比如高并发的购物请求，我们把客户的结果引导到一个降级页面。
- 弱状态：允许不同节点的数据副本之间存在同步延时。
- 最终一致性：也就是最终一致性，不要求强一致性。
-
限流
-
降级
降级是指自己的待遇下降了，从RPC调用环节来讲，就是去访问一个本地的伪装者而不是真实的服务。 当双11活动时，把无关交易的服务统统降级，如查看蚂蚁深林，查看历史订单，商品历史评论，只显示最后100条等等。
-
熔断
熔断机制是应对雪崩效应的一种微服务链路保护机制。在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
-
微服务的雪崩--通过熔断框架来解决
A调用B，B调用C，C调用D，但D发生故障的时候，C会进行重试，但是A还是会继续发请求给B，导致B占用内存CPU标高，最后大家一起坏掉。
-
