文章目录
SpringCloud Alibaba
Spring Cloud Alibaba是阿里巴巴提供的一站式微服务解决方案，是Spring Cloud体系中的一个重要分支，它将阿里巴巴在微服务领域的实践经验和开源技术进行了整合，为开发者提供了一系列便捷的工具和组件，用于构建分布式微服务应用。以下是其详细介绍：
1、核心组件
- Nacos：用于服务注册与发现以及配置管理。它可以帮助微服务实例自动注册到注册中心，并能够动态获取配置信息，使应用程序能够灵活地应对配置的变化，无需重启服务。
- Sentinel：主要用于流量控制、熔断降级等功能。它可以保护微服务免受高并发、流量异常等情况的影响，确保系统在压力下能够稳定运行，避免因个别服务出现问题而导致整个系统崩溃。
- RocketMQ：是一款高性能、高可靠的分布式消息队列。它在微服务架构中常用于实现异步消息传递、解耦系统组件之间的依赖关系，从而提高系统的整体性能和可扩展性。
- Seata：致力于提供分布式事务解决方案，确保在分布式系统中数据的一致性。它通过对事务的协调和管理，使得多个微服务之间在进行数据交互时能够遵循ACID原则。
2、优势
- 一站式解决方案：涵盖了微服务架构中的多个关键领域，包括服务治理、配置管理、流量控制、分布式事务等，开发者无需再从多个不同的开源项目中进行整合，大大降低了微服务架构的搭建和维护成本。
- 与Spring Cloud生态的深度集成：基于Spring Cloud的编程模型和规范进行开发，使得熟悉Spring Cloud的开发者能够快速上手并轻松集成到现有的Spring Cloud项目中，充分利用Spring Cloud的各种特性和优势。
- 阿里巴巴的技术实力和实践经验支持：得益于阿里巴巴在大规模分布式系统开发和运营方面的丰富经验，Spring Cloud Alibaba的组件经过了实际生产环境的考验，具有较高的稳定性、性能和可扩展性，能够应对各种复杂的业务场景和高并发流量。
3、应用场景
- 电商系统：在电商业务中，存在多个微服务，如商品服务、订单服务、库存服务等。Spring Cloud Alibaba可以通过Nacos进行服务注册与发现，使用Sentinel对各个服务的流量进行控制，利用RocketMQ实现异步消息通知，比如下单成功后异步通知库存服务扣减库存，通过Seata保证分布式事务的一致性，确保订单和库存等数据的准确性。
- 金融系统：金融领域对数据一致性和系统稳定性要求极高。Spring Cloud Alibaba的Seata可以确保在多个金融业务操作之间的分布式事务一致性，如转账操作涉及到两个不同账户服务之间的资金变动。Nacos可以提供配置管理，方便对金融业务的各种配置参数进行动态调整，Sentinel则可以防止因突发的高并发交易对系统造成冲击。
- 物联网（IoT）平台：物联网场景中，大量的设备会产生实时数据并上传到云端。Spring Cloud Alibaba可以通过Nacos管理各个物联网服务的注册与发现，使用RocketMQ接收和处理大量的设备数据消息，进行异步处理和分发。Sentinel可以对物联网服务的流量进行控制，防止因设备数据突发增长导致系统过载。
一、数据库事务ACID特性
基础概念：事务ACID
- A（Atomic）：原子性，构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失 败的情况。
- C（Consistency）：一致性，在事务执行前后，数据库的一致性约束没有被破坏。比如：张三向李四转100元， 转账前和转账后的数据是正确状态这叫一致性，如果出现张三转出100元，李四账户没有增加100元这就出现了数 据错误，就没有达到一致性。
- I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事 务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读、重复读等问题。
- D（Durability）：持久性，事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚。
二、什么是分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
三、分布式事务典型场景
1、多服务
随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，会出现很多分布式事务问题如下：
2、多数据源
2.1 跨库
跨库事务指的是，一个应用某个功能需要操作多个库，如下图：
2.2 分库分表
通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。如下图，将订单数据库拆分成了4个库：
小结：上述讨论的分布式事务场景中，无一例外的都直接或者间接的操作了多个数据库。如何保证事务的ACID特性，对于分布式事务实现方案而言，是非常大的挑战。同时，分布式事务实现方案还必须要考虑性能的问题，如果为了严格保证ACID特性，导致性能严重下降，那么对于一些要求快速响应的业务，是无法接受的。
四、分布式事务基础理论
随着互联化的蔓延，各种项目都逐渐向分布式服务做转换。如今微服务已经普遍存在，本地事务已经无法满足分布式的要求，由此分布式事务问题诞生。 分布式事务被称为世界性的难题，目前分布式存在两大理论依据：CAP定律 BASE理论。
1、CAP定律
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
-
一致性（C）
对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。
-
可用性（A）
非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。
-
分区容错性（P）
当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。
在分布式系统中，网络无法100%可靠，分区其实是一个必然现象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。
对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。
2、BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
-
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性—-注意，这绝不等价于系统不可用。比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
-
软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
-
最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
3、酸碱平衡
ACID （酸）能够保证事务的强一致性，即数据是实时一致的。
BASE（碱） 要求的最终一致性
| 目标 | 说明 | 场景 |
|---|---|---|
| 强一致（ACID） | 参与事务的分支全部一起行动，单个子事务操作不完全提交，等待最终提交<br />当事务完成后，后续其它的访问都会返回最新的更新过的值。 | 比如下单扣优惠券，需要强一致性，不然优惠券可以用多次 |
| 最终一致（BASE） | 参与事务的分支可以单独行动，单个子事务操作可以先行提交不保证后续的访问，<br />能够立刻返回最新的值，不确定多久之后可以访问到，但是需要保证过一段时间之后，最终能够访问到最新的值。 | 比如下单送积分，积分可以晚一点再送，不会影响主流程 |
强一致性
最终一致性
五、分布式事务协议
1、2PC
1.1 流程
1.2 优缺点
优点： 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持(XA)。
缺点：
- 单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
- 同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
- 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。
2、3PC
三段提交（3PC）是对两段提交（2PC）的一种升级优化，3PC在 2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前，各参与者节点的状态都一致。同时在协调者和参与者中都引入超时机制，当 参与者各种原因未收到 协调者的commit请求后，会对本地事务进行abort，不会一直阻塞等待，解决了 2PC的单点故障问题，但 3PC 还是没能从根本上解决数据一致性的问题。
2.1 流程
CanCommit：协调者向所有参与者发送CanCommit命令，询问是否可以执行事务提交操作。如果全部响应YES则进入下一个阶段。
PreCommit：协调者向所有 参与者发送 PreCommit命令，询问是否可以进行事务的预提交操作，参与者接收到PreCommit请求后，如参与者成功的执行了事务操作，则返回 Yes响应，进入最终commit阶段。一旦参与者中有向协调者发送了 No响应，或因网络造成超时，协调者没有接到参与者的响应，协调者向所有参与者发送 abort请求，参与者接受abort命令执行事务的中断。
DoCommit： 在前两个阶段中所有参与者的响应反馈均是 YES后，协调者向参与者发送 DoCommit命令正式提交事务，如协调者没有接收到参与者发送的ACK响应，会向所有参与者发送 abort请求命令，执行事务的中断
2.2 优缺点
-
优点：
1、引入超时机制。解决了事务管理器突然宕机导致资源一直处于阻塞的问题
2、多了一次询问阶段。防止个别参与者不正常的情况下，其他参与者都执行了事务，锁定资源。
-
缺点：
1、 3PC 用超时机制，同步阻塞问题，但与此同时却多了一次网络通信，性能上反而变得更差，也不太推荐。
2、没有解决数据不一致的问题