CAP 定理

    • 在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
    • 虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构

    BASE 理论

    • Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
    • Soft state（软状态）：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
    • Eventually consistent（最终一致性）：最终一致是指经过一段时间后，所有节点数据都将会达到一致。
    • BASE 是对CAP 中 AP 方案的一种补充。在 BASE 中用软状态和最终一致，保证了延迟后的一致性。BASE 和 ACID 是相反的，ACID 是一种强一致性模型，而 BASE 却是牺牲这种强一致性，允许数据短时间内不一致，最终一致性。

    TCC 事务

    Trying：

    • 完成所有业务检查(一致性)
    • 预留必须业务资源(准隔离性)

    Confirm:

    • 真正执行业务
    • Confirm操作要满足幂等性

    Cancel:

    • 释放Try阶段预留的业务资源
    • Cancel操作要满足幂等性

    Eureka 自我保护机制

    • 如果Eureka在指定时间没有收到client的心跳时，server就会剔除这个节点，但是有时候由于网络，会造成大部分节点都出现心跳接收过慢，所以Eureka自我保护机制就是，当在15分钟内85%以上的client 都没有正常收到心跳时，server就会认为是出现了网络故障，不会移除client，仍然接收新服务注册，只不过不会同步到其它节点。而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

    Ribbon 负载均衡

    • 是进程内LB（负载均衡）
    • IRule：根据特定算法获取一个访问服务

    OpenFeign 服务接口调用

    • 使调用服务更加简单，更加符合面向接口调用，让调用像调用本地服务一样
    • 默认继承了Ribbon负载均衡器
    • 可以配置调用超时时间

    服务雪崩

    • 微服务调用链路上，某个服务挂掉之后导致级联故障，影响到整个应用的其它模块，导致雪崩

    Hystrix

    • 处理分布式系统的延迟和容错，当某个服务故障时，返回给调用者一个预期的结果，避免发生雪崩
    • 核心功能
      • 服务降级
      • 服务熔断
      • 服务健康实时监控
    • 服务降级
      • 不让客户端等待，返回预先定义好的返回结果（fallback）
      • 触发情况
        • 程序运行异常
        • 超时
        • 服务熔断触发降级
        • 线程池、信号量打满也会触发
    • 服务熔断
      • 直接拒绝访问，放回降级方法定义的返回结果
      • 服务降级 -》 服务熔断 -》 回复调用链路
      • 服务限流： 限制QPS
      • 熔断时机
        • 请求次数超过峰值
        • 超时时间
        • 失败率
      • 熔断一段时间后，熔断器会处于半开状态，会放入一部分请求，如果成功，则会关闭断路器

    Gateway 网关

    • 主要功能
      • 反向代理
      • 鉴权
      • 流量控制
      • 熔断
      • 日志监控
    • 核心概念
      • 路由：是网关的基本模块，它记录着服务的ID、URL等，通过一系列的断言和过滤器匹配路由
      • 过滤器
    • 工作流程
      • 客户端发起请求，通过负载均衡到达对应的网关，然后通过Gateway Handler Mapping中找到请求匹配的路由，发送到对用的Handler，Handler在通过指定的过滤器链最终将请求发送到我们的目标服务器
      • 核心逻辑：路由转发 + 执行过滤链

    SpringCloud Confg 配置中心

    • 依赖GitHub 实现配置云存储，但每次配置变更需要依赖健康检测接口进行手动刷新，才能更新配置

    SpringCloud Bus 消息总线

    • 由于每次修改配置中心的配置之后都需要手动刷新，所以通过消息总线借助消息队列的广播模式，通知所有服务更新配置

    SpringCloud Stream

    • 屏蔽底层消息中间件的差异，统一消息的编程模型

    分布式事务

    • 2阶段提交（2PC）
      • 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复
      • 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）
      • 如参与者执行成功，给协调者反馈同意，否则反馈中止
    • 3PC
      • 在协调者和参与者中都引入超时机制
      • 增加预提交步骤，保证了在最后提交阶段之前各参与节点的状态是一致的。
      • PreCommit只记录日志不提交事务
    • TCC(事务补偿)
      • TCC 事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开
      • Try 阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。
    • 本地消息表
      • 主动事务方会把事务信息记录到本地消息列表，再通过消息中间推送给被动事务方
    • MQ事务方案（可靠消息事务）
      • 是对本地消息表的进一步封装
    • Seata
      • 提供了 AT、TCC、SAGA 和 XA 事务模式
      • 核心组件
        • TC（Transaction Coordinator）：事务协调者。管理全局的分支事务的状态，用于全局性事务的提交和回滚。
        • TM（Transaction Manager）：事务管理者。用于开启、提交或回滚事务。
        • RM（Resource Manager）：资源管理器。用于分支事务上的资源管理，向 TC 注册分支事务，上报分支事务的状态，接收 TC 的命令来提交或者回滚分支事务。