分布式CAP和BASE理论！

吞吐量

指系统在单位时间能够处理多少个请求

QPS

每秒查询次数，通常是对读操作的压测指标

TPS

每秒处理的事务数目，通常是对写操作的压测指标

RT

响应时间间隔，是指用户发起请求，到接收到请求的时间间隔

熔断

熔断机制，是指在分布式系统中，当某个下游服务出现超时、错误率过高或资源不足等过载现象时。

上游服务会迅速切断对该下游服务的请求，以避免出现故障扩散的情况。

熔断机制可以保证整个系统的可用性，避免因一个服务的局部小规模故障，导致整个系统全局瘫痪的后果。

降级

服务降级，是指当系统出现高负载或异常时，通过牺牲部分非核心功能的方式，保证系统核心功能的可用性。

背压

背压思想，被请求方不会直接将请求端的流量直接丢掉，而是不断的反馈自己的处理能力。

请求端根据这些反馈，实时的调整自己的发送频率，比如：TCP/IP中使用滑动窗口来进行流量控制。

CAP原则

Consistency（一致性）

所有节点返回的数据是一致的。

Availability（可用性）

就是某个节点坏了，不能影响其他的节点业务。

如主MySQL节点挂了，但从MySQL没有挂，从MySQL照样提供服务。

Partition Tolerance（分区容错性）

当系统中有节点因网络原因无法通信时，系统依然可以继续运行。

如主MySQL和从MySQL之间没法通信时，系统可用。

分布式系统只能满足三种情况：CA、AP、CP。

分布式系统肯定要实现P，那CA是理论上面的，其实不存在。

大型互联网公司，因为机器数量庞大，网络故障是常态，一般选择AP原则，牺牲掉数据一致性。

  • 一些金融产品对数据一致性要求很高的，就会选择CP。

Redis：AP

RocketMQ：AP

2PC：CP

Eureka：AP

BASE理论

BASE 理论是对 CAP 中一致性和可用性权衡的结果。

其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了对系统的要求。

核心思想： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据的不可用或者不一致时，仍需要保持系统整体主要可用。

基本可用（Basically Available）：

基本可用是指分布式系统在出现不可预知故障的时，允许损失部分可用性。

响应时间上的损失：

  • 正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒；

系统功能上的损失：

  • 正常情况下，在一个电商网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单。
  • 但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态（Soft State）：

软状态是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。

即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性（Eventually Consistent）：

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。