一、CAP & BASE理论详解

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）

常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos...。

ZooKeeper 保证的是 CP
Eureka 保证的则是 AP。
Nacos 不仅支持 CP 也支持 AP，默认AP模式。

在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区”如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。总结：如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。

二、Gateway

响应式编程

三、Hystrix

他是让我们在服务间调用时，加入了一些调用延迟或者依赖故障的容错机制

设计原则：

对依赖服务调用出现的调用延迟和调用失败进行控制和容错保护
对复杂的分布式系统中，组织故障的进一步蔓延
提供fail-fast快速失败机制
提供fallback优雅降级机制
支持近实时的监控，报警，以及运维只是

隔离策略：

线程池隔离（默认）：就是调用下次服务使用的时hystrix自己的线程池，这样避免过多的线程请求打到下级服务（控制访问的线程数量），满了后就降级

信号量隔离：是上级线程调用下级依赖服务，只是设置了一道关卡，当信号量满的时候就降级

request Cache：需要command开启请求缓存

如果多个command，参数一样，调用接口一样，而结果可以认为一样，这个时候我们可以让第一个command执行缓存，下一次从内存获取

四、Ribbon

客户端轮询算法

原理就是将拦截带有@loadBloan注解的restTempte请求，然后从主从中心获取服务的实例，根据轮询算法进行请求，达到负载均很

五、OpenFeign

六、分布式事务

1.0 seata: 支持 AT(自动事务Auto Transaction) TCC SAGA XA

TM: Transaction Manager 事务管理器
    全局事务的管理者，或者说是全局事务的发起方，再通俗一点就是标注了@GlobalTransactional的方法所在的服务
RM: Resources Manager 资源管理
    负责分支(本地)事务注册、提交和回滚。每个服务都是一个RM，负责本地事务的管理
TC：Transaction Coordinate 事务协调器
    全局事务的协调者，TM,RM启动的时候要向TC注册，TM创建的时候要向TC申请一个全局事务ID，所以整个事务的把控是在TC中的，但是各自事务的管理是在RM中


AT(自动事务Auto Transaction): 两阶段
    一阶段：拦截并且解析sql，生成还原操作sql经过处理之后，保存在每个数据库的undo_log表中，对对应数据添加全局行锁，然后再执行业务sql
    二阶段：第一阶段成功执行后会通知各个库删除一阶段生成的undo_log记录和全局行锁，但是如果失败了就会通过各个库的undo_log表中的记录来进行回滚，
        此时会校验 当前数据 和 after image 是否一致，一致则表明可以还原，否则表示出现了脏写，需要转人工处理
    全局行锁保证数据正常回滚，局部行锁的话会导致回滚失败
    无代码侵入
TCC: Try, Confirm, Cancel需要业务层面支持第一阶段Try和第二阶段的Confirm, Cancel.
    用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。
    相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。

SAGA:
    手动实现数据回滚，适合与第三方接入时操作

XA:
    整个事务提交分为 prepare 和 commit 两个阶段
    第一阶段，事务协调者向事务参与者发送 prepare 请求，事务参与者收到请求后，如果可以提交事务，回复 yes，否则回复 no。开启XA，执行sql,
    第二阶段，如果所有事务参与者都回复了 yes，事务协调者向所有事务参与者发送 commit 请求，否则发送 rollback 请求。

seata 与 oauth2 冲突：
    seata进行bean扫描的时候会对全局bean进行读取并解析其方法上面的注解，
    ClientDetailsService 默认创建的方法上是有 @Lazy 注解，只要不主动使用是不会进行创建的，但是seata打破了这个状态，导致提前创建了一个虚假bean
    这个操作将导致 ClientDetailsService 会被默认创建一个不可操作的bean

    解决方案：
        1.0 再虚假 ClientDetailsService 的 bean 创建之后进行真实 bean 创建操作，并且设置可以覆盖 bean 的配置，并
        2.0 不引入 seata 依赖，涉及到全局事务的场景使用类似于 SAGA 原理手动调用补偿接口

七、分布式锁

八、限流熔断降级

出现场景：
    服务雪崩：
        因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程
        服务雪崩的出现原因：激增流量，不稳定服务依赖

解决方案：
    稳定性、恢复性

    常见的容错机制：
        超时机制：
            在不做任何处理的情况下，服务提供者不可用会导致消费请求线程强制等待，而造成系统资源耗尽。加入超时机制，一旦超时，就释放资源。
            由于释放资源速度较快，一定程度上可以抑制资源耗尽的问题。

        服务限流：

        服务隔离：
            用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来进行访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞，
            至少可以看到一个执行结果(例如返回友好的提示信息)，而不是无休止的等待或者看到系统奔溃。

        服务熔断：
            远程服务不稳定或网络抖动时暂时关闭，就叫服务熔断
            现实世界的断路器大家肯定都很了解，断路器实时监控电路的情况，如果发现电路电流异常，就会跳闸，从而防止电路被烧毁。
            软件世界的断路器可以这样理解:实时监测应用，如果发现在一定时间内失败次数/失败率达到一定阈值，就"跳闸"，断路器打开，此时，请求直接返回，而不去调用原本调用的逻辑。
            跳间一段时间后(10秒 ，断路器会进入半开状态，这是一个瞬间态，此时允许一次请求调用该调的逻辑，如果成功，则断路器关闭，应用正常调用；如果调用依然不成功，断路器继续回到打开状态，
            过段时间再进入半开状态尝试一一通过"跳闸"，应用可以保护自己，而且避免浪费资源，而通过半开的设计，可实现应用的"自我修复"。
            所以，同样的道理，当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源。比如我们设置了超时时间为1s，如果短时间内有大量请求在1s内都得不到响应，
            就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个依赖了，这个时候就应该使用断路器避免资源浪费。

        服务降级(弱依赖-不那么重要服务的依赖)：
            有服务熔断，必然要有服务降级。
            所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自已准备个本地的 fallback 回退)回调，返回一个缺省值。例如:(备用接口/缓存/mock数据)。这样做，虽然服务水平
            下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。

九、RPC与HTTP协议有什么区别？

rpc是一种针对跨进程或者跨网络节点之间的远程过程调用协议，核心是让开发人员在调用远程方法与调用本地方法一样，不需要额外的编码交互（底层的数据传输可以使用TCP协议也可以使用http协议）

http:是为了web浏览器与web服务器之间通信而设计的远程通信协议。

十、NACOS 的注册机制

本文由 zzpp 创作，采用知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: 2024/09/12 09:05