分布式理解

集群和分布式,微服务的概念

集群：单体1个节点-》单体多节点（A,B,C…等节点），用nginx做请求转发，请求打到nginx,由nginx把请求的分发到这两个节点中的请求。 这两个节点都能够提供完整的服务，每个节点部署的实例是一致的。
集群是物理形态

每个节点都具备完整的服务，服务中可能存在A,B,C模块，但可能A模块访问量是最大的，而B，C.访问量较小。此时将3个模块部署到一个实例(节点)中，用nginx负载，显然这种形式效率不高。

分布式：将A，B，C都做成一个单独的实例，单独部署。有一些服务请求可能即需要调用A有需要调用B,C才能都形成一个完整的服务，这就需要A，B，C协同工作。

其实集群和分布式并没有明显的区别，上面集群的实例和实例之间就没有交互么？不一定。比如说X接口调用Y接口，通过MQ去交互，那么X调到的Y不一定是他自己节点上的Y,
可能是其他节点上的Y。也是分布式的概念

总结：(侧重点不同)
集群：节点对等，完整的服务实例，强调物理形态
分布式：强调节点之间进行协调(工作方式)

SOA

SOA：面向服务
里面有ESB,
比如A需要调用D,E，F…等服务，想要A调用到其他的，A得维护其他的地址，才能发起调用。其他服务也相应如此。此时SOA就提供了一个SOA机制。SOA总线服务。
此时，所有的服务不在直接找到其他服务，而是通过SOA。只需记住ESB的地址，ESB帮我去掉其他的服务。

缺点：所有节点的交互都通过ESB,那个系统的运行的效率完全取决于ESB。ESB往往会成为单点瓶颈。

微服务

中心化思想
服务间相互调用，记录的节点信息很多。
比如互相调用地址的问题===>注册中心（服务注册与发现）

分布式事务

分类

多数据源

例如：一个方法里面操作的2个数据源
@Transtrance只对第一个数据源生效了，第二个数据源没有生效

多服务

例如：A服务访问DB1数据源
B服务访问DB2数据源
当A发起远程调用B
一次业务操作需要跨多个数据源或多个系统进行远程调用，就会产生分布式事务。
分布式事务的目的：解决全局数据一致性的问题。

解决方案

1：XA协议

两阶段提交和三阶段提交，需要数据库层面的支持(mysql的InnoDB支持XA协议)

XA协议-----------（JAVA中实现XA）--------------------JTA(一系列接口)

两阶段

两阶段有超时机制：协调者TM
数据不一致：当第二步放松commit让数据库提交数据时，因为网络故障，有数据库没接收到有的接受到，会导致数据不一致。

三阶段

阶段一：发送CanCommit消息确认数据库环境(先探测一下数据库是否都存活，能够和自己交互)
阶段二：发送PreCommit消息,完成sql操作，但未提交事务
阶段三：发送DoCommit消息,通知所有库提交事务/回滚事务

对于三阶段而言
第一阶段只发送PreCommit消息(不发送sql了)，有响应，则证明这三个数据库都没挂。而在第一阶段，上来就发送sql，你都不知道此时数据库挂没挂，而且就算没挂，此时数据库接受到sql，也不立即commit,还得锁定资源。
虽然三阶段比二阶段多了一步探测的操作，但还是有问题。如果第一步探测数据库没问题，但在第二步发送sql时，数据库挂掉了，那么此时右回到二阶段上了。可以看出三阶段只是比二阶段降低了问题出现的概率

三阶段也解决了事务管理器单点故障的问题：参与者也有超时机制，不会一直阻塞

两阶段有超时机制的：协调者TM和参与者数据库
引入超时机制解决参与者阻塞的问题（参与者：数据库），超时后本地提交。
超时本地提交：如果数据库一直收不到TM的DoCommit,那么数据库就会本地提交。因此也会引发数据不一致的问题。

2：基于事务补偿机制

事务补偿机制有很多种，典型代表：TCC(基于业务层的实现)

TCC(补偿事务)

例子：
---------- 订单--------支付-------------------库存------------------
try-------更新中-------(暂不考虑)--------数据库库存表加一个扩展字段（库存扣减中）
如果try都成功了
confirm----订单完成-------(暂不考虑)—库存扣减成功，num–

3：本地消息表

基于本地数据库+mq,维护本地状态(进行中)

4：基于消息中间件(MQ)

也是基于2pc的理念，A模块调用B模块，A发送消息给中间件，此时中间件中的消息的状态是一个不可消费的状态，即B不能消费它。当A模块的本地事务成功了，再把中间件中的消息状态改为可消费状态。
但可能出现的问题：
如果本地事务失败了，就把这个消息删掉
如果本地事务成功了，但在改这个消息的状态的时候，网络出现故障，状态为被改掉，这就有问题了。rocketmq有个机制，会多次定时询问这个消息的事务到底成功没？

Seata

一阶段

二阶段

Seate支持的分布式事务方案
1：AT --代码无侵入
2：TCC --代码有侵入
3：Sage --代码有侵入

AT模式(也是2PC)

AT模式是Seata最主推的分布式事务且基于XA演进而来的解决方案，主要有三个角色：TM、RM和TC，其中TM和RM作为Seata的客户端和业务集成，TC作为Seata服务器独立部署。TM向TC注册一个全局事务，并生成全局唯一的XID；在AT模式下，数据库资源被当做RM，访问RM时，Seata会对请求进行拦截；每个本地事务提交时，RM会向TC（Transaction Coordinator，事务协调器）注册一个分支事务。

从三个角色TM、RM和TC的角度来记录具体的流程的话，可以总结如下：

TM向TC注册全局事务，并生成全局唯一XID；
RM向TC注册分支事务，并将其纳入到该XID对应的全局事务范围。
RM向TC汇报资源的准备状态
TC汇总所有事务参与者的执行状态，决定分布式事务全部回滚还是提交
TC通知所有的RM提交/回滚事务

RPC

远程过程调用：即通过本地调用地方式调用远程(以类名方法名替换http地址)