分布式基础

分布式系统，即是将一个项目中的各个服务分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向服务的架构（SOA）。分布式系统可以看做是若干个独立计算机的集合，这些服务在不同的计算机上部署，但还是属于同一个项目。

1.说说 CAP 定理、 BASE 理论

        CAP 

• 一致性（Consistency） : 所有节点访问同一份最新的数据副本
• 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
• 分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

        Nacos 不仅支持 CP 也支持 AP。

为啥不可能选择 CA 架构呢？

举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。

        BASE 理论

AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。

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

软状态：允许系统中的数据存在中间状态（CAP 理论中的数据不一致）

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

2.分布式事务（目的是为了保证分布式系统中的数据一致性）

        分布式常见的实现方案：

分布式常见的实现方案有 2PC、TCC、本地消息表、MQ消息事务、最大努力通知、SAGA事务 等等

        2PC

• 准备阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交
• 提交阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

        TCC

TCC也是补偿型事务模式，支持两阶段的商业模型。

• Try：尝试待执行的业务。订单系统将当前订单状态设置为支付中，库存系统校验当前剩余库存数量是否大于1，然后将可用库存数量设置为库存剩余数量-1，。
• Confirm：确认执行业务，如果Try阶段执行成功，接着执行Confirm 阶段，将订单状态修改为支付成功，库存剩余数量修改为可用库存数量。
• Cancel：取消待执行的业务，如果Try阶段执行失败，执行Cancel 阶段，将订单状态修改为支付失败，可用库存数量修改为库存剩余数量。

3.分布式限流方法

• 计数器

        比如我们要限制1s能够通过的请求数，实现的思路就是从第一个请求进来开始计时，在接下来的1s内，每个请求进来请求数就+1，超过最大请求数的请求会被拒绝，等到1s结束后计数清零，重新开始计数。

• 漏桶算法

        就是桶底出水的速度恒定，进水的速度可能快慢不一，但是当进水量大于出水量的时候，水会被装在桶里，不会直接被丢弃

        但是桶也是有容量限制的，当桶装满水后溢出的部分还是会被丢弃的。

• 令牌桶算法

        令牌桶算法以一个设定的速率产生令牌并放入令牌桶，每次用户请求都得申请令牌，如果令牌不足，则拒绝请求。