文章目录

• • 🔥分布式架构的理论知识_BASE理论
  • 🔥分布式事务解决方案_最终一致性分布式事务
  • 🔥最终一致性分布式事务解决方案_TCC是什么
  • 🔥Hmily实现TCC分布式事务实战_认识Hmily-TCC

🔥分布式架构的理论知识_BASE理论

为什么会出现BASE理论
CAP 理论表明，对于一个分布式系统而言，它是无法同时满足Consistency(强一致性)、Availability(可用性) 和 Partition tolerance(分区容忍性) 这三个条件的，最多只能满足其中两个。

理由：
⭐为了用户体验，先选可用性。
⭐放弃了一致性的系统又失去了存在的意义。

简介
BASE 理论起源于 2008 年， 由 eBay 的架构师 Dan Pritchett 在ACM 上发表。

什么是BASE理论
BASE 是 Basically Available（基本可用） 、Soft-state（软状态）和 Eventually Consistent（最终一致性） 三个短语的缩写。

核心思想:
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

BASE 理论三要素

基本可用(Basically Available)
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。允许损失部分可用性。但是，这绝不等价于系统不可用。

软状态(Soft State)
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。即允许系统在多个不同节点的数据副本存在数据延时。

注意：
用户在商城下单时，因网络超时等因素，订单处于“支付中”的状态，待数据最终一致后状态将变更为“关闭”或“成功”状态。

最终一致性(Eventual Consistency)
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

分布式一致性的 3 种级别：
⭐强一致性 ：系统写入了什么，读出来的就是什么。
⭐弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
⭐最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。
ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。符合Base理论的事务可以称为柔性事务。

🔥分布式事务解决方案_最终一致性分布式事务

什么是最终一致性事务
强一致性分布式事务解决方案要求参与事务的各个节点的数据时刻保持一致，查询任意节点的数据都能得到最新的数据结果。这就导致在分布式场景，尤其是高并发场景下，系统的性能受到影响。而最终一致性分布式事务解决方案并不要求参与事务的各节点数据时刻保持一致，允许其存在中间状态，只要一段时间后，能够达到数据的最终一致状态即可。

典型方案
为了解决分布式、高并发场景下系统的性能问题，业界基于Base理论提出了最终一致性分布式事务解决方案。

⭐TCC解决方案。
⭐可靠消息最终一致性解决方案。
⭐最大努力通知型解决方案。

适用场景

注意：
每个服务都存在中间状态，服务与服务之间不必保持强一致性，允许在某个时刻查询出来的数据存在短暂的不一致性，经过一段时间后，各个服务之间的数据能够达到最终一致性。这样，不仅各个服务的数据达到了最终一致性，还极大地提高了系统的整体性能并降低了分布式事务执行过程中出错的概率。

优缺点
最终一致性分布式事务解决方案的优点：
⭐性能比较高，这是因为最终一致性分布式事务解决方案不要求数据时刻保持一致，不会因长时间持有事务占用的资源而消耗过多的性能。
⭐具备可用性。
⭐适合高并发场景。
最终一致性分布式事务解决方案的缺点：
⭐因为数据存在短暂的不一致，所以在某个时刻查询出的数据状态可能会不一致。
⭐对于事务一致性要求特别高的场景不太适用。

🔥最终一致性分布式事务解决方案_TCC是什么

概念
TCC(Try-Confirm-Cancel)又称补偿事务。

TCC核心思想
TCC分布式事务最核心的思想就是在应用层将一个完整的事务操作分为三个阶段。在某种程度上讲，TCC是一种资源，实现了Try、Confirm、Cancel三个操作接口。

Try阶段
Try阶段是准备执行业务的阶段，在这个阶段尝试执行业务。
⭐完成所有的业务检查，确保数据的一致性。
⭐预留必要的业务资源，确保数据的隔离性。

Confirm阶段
Confirm阶段是确认执行业务的阶段，在这个阶段确认执行的业务。
⭐真正地执行业务。
⭐不做任何业务逻辑检查，直接将数据持久化到数据库。
⭐直接Try阶段预留的业务资源。

Cancel阶段
Cancel阶段取消执行业务。
⭐释放Try阶段预留的业务资源。
⭐将数据库中的数据恢复到最初的状态。

TCC核心组成

🔥Hmily实现TCC分布式事务实战_认识Hmily-TCC

概述
Hmily是一款高性能，零侵入，金融级分布式事务解决方案，目前主要提供柔性事务的支持，包含 TCC , TAC (自动生成回滚SQL) 方案，未来还会支持 XA 等方案。

功能
⭐高可靠性 ：支持分布式场景下，事务异常回滚，超时异常恢复，防止事务悬挂
⭐易用性 ：提供零侵入性式的 Spring-Boot , Spring-Namespace 快速与业务系统集成。
⭐高性能 ：去中心化设计，与业务系统完全融合，天然支持集群部署
⭐可观测性 ：Metrics多项指标性能监控，以及admin管理后台UI展示
⭐多种RPC ： 支持 Dubbo , SpringCloud , Motan , Sofa-rpc , brpc , tars 等知名RPC框架
⭐日志存储 ： 支持 mysql , oracle , mongodb , redis , zookeeper 等方式
⭐复杂场景 ： 支持RPC嵌套调用事务

Hmily对RPC框架的支持
⭐对Dubbo框架的支持
⭐对Spring Cloud框架的支持
⭐对BRPC框架的支持
⭐对Motan框架的支持
⭐gRPC框架的支持
⭐对Sofa-RPC框架的支持
⭐对Tars框架的支持

必要前提
⭐必须使用 JDK8+
⭐TCC模式必须要使用一款 RPC 框架, 比如 : Dubbo , SpringCloud , Montan