🚩Distributed - 分布式理论

分布式事务与分布式锁的区别？

分布式锁解决的是分布式资源抢占的问题；分布式事务和本地事务是解决流程化提交问题。

🌟如何解决分布式事务问题的？/Seata 架构？

三种角色：

• TC 事务协调者
• TM 事务管理器
• RM 资源管理器

解决方案：

• Seata XA：RM 互相等待，强一致性【CP：银行】
• Seata AT：利用 undolog 实现高可用，主要⽤于核⼼模块，例如交易/订单等【强一致性场景：商品交易】
• Seata TCC：强调资源预留， 通过TC的协调，保证最终⼀致性，也可以业务解耦【弱一致性场景：通知回显】
• MQ：异步确保型事务，将 MQ 和 MySQL 操作放在同一个事务内执行，实时性高【最终一致性场景：通知支付结果】

  属性	2PC	TCC	Saga	异步确保型事务	尽最⼤努⼒通知
  事务⼀致性	强	弱	弱	弱	弱
  复杂性	中	⾼	中	低	低
  业务侵⼊性	⼩	⼤	⼩	中	中
  使⽤局限性	⼤	⼤	中	⼩	中
  性能	低	中	⾼	⾼	⾼
  维护成本	低	⾼	中	低	中

如何使用？

1. maven 引入 seata-all 依赖
2. 分布式事务处理的方法上添加@GlobalTransactional注解
3. 根据需求选择方案，修改配置文件
   1. XA：enableAutoDataSourceProxy = false，因为 XA 模式需要使用AtomikosDataSourceBean 代理数据源。
   2. AT：enableAutoDataSourceProxy = true，因为 AT 模式需要使用 DataSourceProxy 代理数据源
   3. TCC：enableAutoDataSourceProxy = true，在业务方法上添加 @TwoPhaseBusinessAction 注解，同时修饰三个方法：try（）、confirm（）、cancel（）

CAP定理 - 三选二

• ⼀致性(Consistency) ： 客户端知道⼀系列的操作都会同时发⽣(⽣效)
  • 强一致性：保证客户端看到的数据都是⼀致的
  • 最终一致性：允许存在中间状态，只要求经过⼀段时间后，数据最终是⼀致的
  • 弱一致性：存在部分数据不一致
• 可⽤性(Availability) ： 每个操作都在一定时间范围内，返回可预期的响应。
• 分区容错性(Partition tolerance) ： 分布式系统在遇到任何⽹络分区故障时，仍然需要能够保证对外提供满⾜⼀致性和可⽤性的服务，除⾮是整个⽹络环境都发⽣了故障。

AP系统：在互联⽹领域的绝⼤多数的场景中，都需要牺牲强⼀致性来换取系统的⾼可⽤性，系统往往只需要保证最终⼀致性。 对于涉及到钱财这样不能有⼀丝让步的场景，C 必须保证。⽹络发⽣故障宁可停⽌服务，这是保证 CA，舍弃 P。还有⼀种是保证 CP，舍弃 A。例如⽹络故障是只读不写。

BASE定理

核⼼思想：即使⽆法做到强⼀致性，但每个应⽤都可以根据⾃身业务特点，采⽤适当的⽅式来使系统达到最终⼀致性。 CAP是分布式系统设计理论，BASE是CAP理论中AP⽅案的延伸，对于C我们采⽤的⽅式和策略就是保证最终⼀致性；BASE理论是对CAP理论的延伸，核⼼思想是即使⽆法做到强⼀致性（StrongConsistency，CAP的⼀致性就是强⼀致性），但应⽤可以采⽤适合的⽅式达到最终⼀致性（Eventual Consitency）。

• Basically Available（基本可⽤）：响应时间增加
• Soft state（软状态）：指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可⽤性。
• Eventually consistent（最终⼀致性）：通过牺牲⼀致性来获得可⽤性，并允许数据在⼀段时间内是不⼀致的，但最终达到⼀致状态。

BASE与ACID的区别和联系

BASE理论⾯向的是⼤型⾼可⽤可扩展的分布式系统，和传统的事物ACID 特性是相反的。 它完全不同于ACID的强⼀致性模型，⽽是通过牺牲强⼀致性来获得可⽤性，并允许数据在⼀段时间内是不⼀致的，但最终达到⼀致状态。 但同时，在实际的分布式场景中，不同业务单元和组件对数据⼀致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往⼜会结合在⼀起。

CAP和ACID中的A和C是完全不⼀样的

对于数据库事务而言，A、I、D 是手段，C 是目的。

A的区别

ACID中的A指的是原⼦性(Atomicity)，是指事务被视为⼀个不可分割的最⼩⼯作单元，事务中的所有操作要么全部提交成功，要么全部失败回滚； CAP中的A指的是可⽤性(Availability)，是指集群中⼀部分节点故障后，集群整体是否还能响应客户端的读写请求；

C的区别

ACID的C是有关数据库规则，数据库总是从⼀个⼀致性的状态转换到另外⼀个⼀致性的状态；【数据库完整性】 CAP的C是分布式多服务器之间复制数据令这些服务器拥有同样的数据，由于⽹速限制，这种复制在不同的服务器上所消耗的时间是不固定的，集群通过组织客户端查看不同节点上还未同步的数据维持逻辑视图，这是⼀种分布式领域的⼀致性概念；【分布式节点的数据的⼀致性】

🌟如何实现分布式接口幂等性？

1. 每个请求对应唯一 token，在处理前判断是否处理过，处理完成后保存业务状态到 Redis 中。
2. 分布式锁
3. 数据库悲观锁、乐观锁（version）
4. 唯一索引（只针对新增请求）

如果插入数据库成功，但是更新 Redis 上的总数失败了怎么办？

• 如果数据短时间不一致但是业务可以接受的话，那么就可以考虑异步刷新 Redis 上的总数。
• 使用 Canal 之类的工具监听 MySQL binlog，然后刷新 Redis 上的总数。

在单体应用拆分成微服务架构之后，怎么解决分布式事务？

keyword：最终一致性