8.分布式高并发
1.分布式
1.分布式事务框架TX-LCN
分布式事务的两阶段提交策略
首先事务管理器通知各个数据源进行操作，并返回是否准备好的信息。等所有数据源都准备好后，再统一发送事务提交（回滚）的通知让各个数据源提交事务。由于最后的提交操作耗时极短，所以操作失败的可能性会很低。如果整个事务将被阻塞。对应的策略是添加一些倒计时的操作，或者是重新发送消息。
思路和我们上面讲的两阶段分布式事务处理流程差不多（有小不同），核心步骤分为3步：
- 创建事务组：在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务表示GroupId的过程。简单来说就是对这次下订单的操作在事务管理中心里创建一个对象，拿到一个id。
- 加入事务组：参与方在执行完业务方法后，将该模块的事务信息通知给TxManager的操作。也就是指各个数据源（各个服务）完成操作后，和事务管理中心说一声，注册一下自己。
- 通知事务组：发起方执行业务代码后，将发起方执行结果状态通知给TxManager，TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。和客户打交道的下订单服务会收到减库存和加订单是否成功消息，它会把这两个消息通知给事务管理者，事务管理者根据情况通知两个库存服务提交事务或回滚事务。
LCN的事务协调机制:
LCN的口号是：LCN并不生产事务，LCN只是本地事务的协调工。大家肯定会有个疑问，它不生产事务，那么它是怎么控制各个模块在完成事务的逻辑操作之后不马上提交，而是等到TxManager最后一起通知各模块提交的呢？
因为每个模块都是一个TxClient，每个TxClient下都有一个连接池，是框架自定义的连接池，对Connection使用静态代理的方式进行包装。连接池在没有接收到通知事务之前会一直占有着这次分布式事务的连接资源。等到最后TxManager通知TxClient时，TxClient才会去执行相应的提交或回滚。所以LCN的事务协调机制相当于是拦截了一下连接池，控制了连接的事务提交。
LCN的事务补偿机制:
由于我们不能保证事务每次都正常执行，如果在执行某个业务方法时，本应该执行成功的操作却因为服务器挂机或网络抖动等问题导致事务没有正常提交，这种场景就需要通过补偿来完成事务。
在这种情况下TxManager会做一个标示;然后返回给发起方。告诉他本次事务有存在没有通知到的情况，然后TxClient再次执行该次请求事务。
