一、服务之间如何保证数据一致性
理论知识包括CAP、BASE 分布式事务解决方案包括2PC、3PC、TCC、本地消息表、可靠消息最终一致性
1. CAP理论
一致性： 多个服务的数据需要在同一时刻保持一致性
可用性： 单个服务需要保持可用状态，超时或者无响应就是不可用
分区容错性： 分布式系统再遇到任何网络分区故障时，仍能够保证对外提供满足一致性和可用性的服务，除非整个网络环境发生故障。
三个条件只能满足两个，在实际应用中，一般保证服务可用性达到几个9，即保证PA。至于一致性得看具体的业务场景，如果需要保证一致性，需要引入分布式事务。
2. BASE理论
BASE理论是对CAP理论中的一致性和可用性的一种权衡的结果，主要思想就是：无法做到强一致，但每个应用可以根据自身业务的特点，采用适当的方式来使系统达到最终的一致性。
基本可用：
软状态：
最终一致性
3. 2PC--两阶段提交
定义：第一阶段是准备阶段，第二阶段是执行阶段。
阻塞式，严格满足ACID原则的方案，但是因为性能上的原因在微服务架构下并不是最佳的方案。
2PC其实更适合这种多数据源的情况，并且数据源都是关系型数据库。这样可以让两个数据库中的事务都同时处于prepare阶段，提交的时候两个数据库中的事务一起commit。
第一阶段（准备阶段）： 发起方向参与者发起指定，参与者评估状态，如果参与者评估可以完成，会写redo和undo日志，然后锁定资源，执行操作。但是并不提交
第二阶段（提交阶段）： 如果每个参与者明确返回准备成功，发起方向参与者发起提交指令，参与者就会提交资源变更的事务，释放锁定的资源。如果有任何一个明确返回失败，发起方就会发起中止指令，取消已经变更的事务，执行undo日志，释放资源。
两阶段的缺点：
两阶段提交协议在准备阶段锁定资源，是一个重量级的操作，能保证强一致性，但是实现起来复杂、成本较高，不够灵活。更有一下致命问题：
- 阻塞： 从流程图可以看出，对于任何一次指令必须收到明确的响应，才会继续下一步，否则处于阻塞状态，占用的资源一直被锁定，不会被释放。
- 单点故障： 如果协调者宕机，参与者没有了协调者指挥，会一直阻塞。如果协调者发出指令会宕机，参与者也宕机，就玩不转了。
- 脑裂： 发起者发送提交指令，有的参与者接收到执行了事务，有的参与者没有接收到指令就没有执行事务，多个参与者之间是不一致的。
4. 3PC
原理与示意图
3PC是对2PC的改进，通过超时机制解决阻塞的问题，把准备阶段一分为二。两个阶段编程三个阶段。
1. 询问阶段： 询问参与者能不能完成指令，只需要回答行或者不行，不需要真正操作，这个阶段参与者在等待超时后会自动中止
2. 准备阶段： 发起预执行请求，参与者写redo和undo日志，锁定资源，执行操作，但是不会提交，参与者进入等待，等待超时则会提交、并释放资源，如果准备失败，则进行回滚操作。
3. 提交阶段： 每个参与者返回准备成功，协调者发起提交指令，参与者提交资源变更事务，释放资源。
与2PC对比： 解决了因为网络原因协调者与参与者断开通信，参与者也会自动提交commit，这样防止了一直锁表的风险，但是极端情况下想想，若事务管理器发送中断命令对参与者，恰巧参与者网络断了接收不到，那么这回参与者默默提交，造成的问题就是数据不一直性。
5. 补偿事务 TCC
TCC又称补偿事务，TCC与2PC的思想相似，事务处理流程也相似，但是2PC应用在DB层面，TCC则可以理解为应用层面，需要我们编写业务逻辑来实现。
Try： 完成业务检查、预留业务资源。
Confirm: 使用预留的资源执行业务操作（需要保证幂等性，要求强一致性或者最终一致性的数据接口都需要实现幂等性）
Cancel: 取消执行业务流程，释放预留的资源（需要保证幂等性）
以转账为例示意图
TCC常见的异常情况
- 空回滚：
在没有调用TCC资源try方法的情况下，调用了二阶段的cancel方法，cancel方法需要识别出这是一个空回滚，然后直接返回成功。
- 幂等：
confirm/cancel阶段都需要保证幂等性。
- 资源悬挂：
问题：cancel接口比try先执行。出现原因是RPC调用分支事务try时候，先注册分支事务，再执行RPC调用，如果此时RPC调用的网络发生拥堵，RPC超时以后，TM会通知RM回滚该事务，可能回滚完成后，RPC请求才能到达参与者真正执行。
解决：事务状态控制记录作为控制手段，二阶段发现无记录时插入记录，一阶段执行时检查记录是否存在
与2PC对比
- 2PC应用在DB层面，TCC则可以理解为应用层面，需要我们编写业务逻辑来实现。
- 不足之处在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现Try,Confirm,Cancel三个操作。还需要考虑按照网络状态，系统故障的不同失败原因实现不同的回滚策略
6. 开源分布式事务组件-seata
基本概念
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata将为用户提供了AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
基于事务ID和三组件模型
-
TC-事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚
-
TM-事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务
-
RM-资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
AT模式
TCC模式
二、docker相关
docker的架构 docker面试题 juejin.cn/post/699568…
三、注册中心对比
四、sentinel熔断限流
sentinel限流原理
熔断原理
降级
服务器压力剧增，为了保证核心功能可用性,选择性的降低一些功能的可用性，或者直接关闭功能，类似于弃卒保帅。
熔断
熔断一般是依赖的外部接口出现故障的情况断绝和外部接口的关系。
限流
系统规定了多少承受能力，只允许这么多请求过来，其他请求直接拒绝。
一般指标是单位时间的请求量。
