本地事务会出现的问题
1、远程服务假失败
远程服务其实成功了，由于网络故障等没有返回，导致订单回滚，库存扣减
2、远程服务执行完成，下面其他方法出现问题，导致已执行的其他远程请求不能回滚。
伪代码：
//TODO 3、保存订单
saveOrder(order);
//、库存锁定，只要有异常回滚订单数据
//订单号，所有订单项（skuId,skuName,num）
WareSkuLockVo lockVo = new WareSkuLockVo();
lockVo.setOrderSn(order.getOrder().getOrderSn());
List<OrderItemVo> locks = order.getOrderItems().stream().map(item -> {
OrderItemVo itemVo = new OrderItemVo();
itemVo.setSkuId(item.getSkuId());
itemVo.setCount(item.getSkuQuantity());
itemVo.setTitle(item.getSkuName());
return itemVo;
}).collect(Collectors.toList());
lockVo.setLocks(locks);
//TODO 4、远程锁库存
R r = wmsFeignService.orderLockStock(lockVo);
if(r.getCode()==0){
//锁成功
response.setOrder(order.getOrder());
//TODO 5、远程扣减积分
int i=10/0;
return response;
}else{
//锁失败
String msg=(String)r.get("msg");
throw new NoStockException(4L);
//return response;
}2、本地事务的基本性质
3、事务的隔离级别
以上4是事务级别的并发能力依次降低。
4、事务的传播行为
总结一句话就是 子继承父 。不是自己的儿子。可以有自己的特性
伪代码：
@Transactional
public void a(){
}
@Transactional(propagation = Propagation.REQUIRED)
public void b(){
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void c(){
}前面还有一个坑就是
同一个对象内事务方法互调默认失效，原先绕过了代理对象，事务使用代理对象来控制的。
不同XXXservice调用不同方法才生效
@Transactional
public void a(){
bService.b();
cService.c();
}
@Transactional(propagation = Propagation.REQUIRED)
public void b(){
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void c(){
}解决：使用代理对象来调用事务方法
1）、引入spring-boot-starter-aop，引入了aspectj
2）、@EnableAspectJAutoProxy(exposeProxy = true) ;开启了aspectj 动态代理功能；以后所有的动态代理都是aspectj创建的（即使没有接口也能创建动态代理）
3)、用代理对象调用
分布式事务
1、为什么会出现分布式事务
节点之间互相的状态不能同步，网络状况，数据互相感知不到
2、CAP定理和BASE理论
1）、一致性（Consistency）
（在分布式系统下。所有的数据在同一时候是否是同样的值）
2）、可用性（Availability）
3）、分区容错性（Partition tolerance）
（一台在北京，一台在上海，网络区不同，可能这两个区不能通信怎么办）
CAP原则指的是，这三个要素最多只能同时实现两个，不可能三者兼顾。
而在分布式系统下一定要满足分区容错性，因为网络肯定会出现问题。
而在P的基础上如果满足A可用想就会出现c的错误
例如：3台服务。如果A，B，C。出现分区容错性.满足可用性的话。客户能同时访问A，B，C。但是由于出现了分区容错性。那么这个三个直接的数据就不是一致性的
同理：3台服务器，如果A,B，C.。出现了分区容错性。满足数据一致性的话。就必须不能让这3台服务器都相应。
Raft Consensus Algorithm --更详细的可以查看此网站
3、BASE理论
分布式事务几种方案
1、）2PC模式
2）、柔性事务-TCC事务补偿型方案
就是有回滚的方法
3）、柔性事务-最大努力通知型方案
就是主流程里的各个分支去订阅消息。那个分支错误。就发送消息到消息队列主流程失败。各分支去监听消息，然后各自回滚。怕有分支因为各种原先收不到消息。会隔几秒发送消息到队列。主流程消息错误。等待分支正常。就收到消息后。返回接受到消息了。不需要通知了。就结束。这就是最大努力通知型方案。
4）、柔性事务+可靠消息+最终一致性方案（异步确保型）
2761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
