调用外部api时的数据一致性问题

最新推荐文章于 2023-11-02 00:12:50 发布

drjava_2019

最新推荐文章于 2023-11-02 00:12:50 发布

阅读量760

点赞数

本文链接：https://blog.csdn.net/XMEHB/article/details/103912216

版权

春节又要来了，远行的小伙伴们将开始一场刺激的抢票之旅，关于购票，从程序角度上而言，大致分为这么几步：

1、检查是否有剩余的票

2、购票后票数减一

3、账户上扣除金额

4、获得火车票

如果执行顺利，一切ok，如果中途执行出现异常，比如扣除金额的时候出现异常，你账户上的金额未减，也没有获得火车票，但剩余票数却莫名地少了一张，这就是我们常说的事务的一致性问题，是由于数据库运行中途发生故障，导致数据库中的状态部分改变，使数据出现不一致的情况。

事务的一致性需要由原子性来保证，即对于一系列操作，要么全部成功，要么全部失败回滚，以上述例子而言，账户金额扣除发生异常时，之前的写操作就要全部回滚，恢复到执行前的状态，这个大部分数据库都提供支持，我们平时只需要借助spring的aop机制，声明事务即可。

数据库事务与隔离级别

全面分析 Spring 的编程式事务管理及声明式事务管理

ThreadLocal与Spring 事务管理

然而，并不是每一步操作都可以借助数据库的事务机制保持数据一致性的，有时候我们常常要调用开放平台的api接口，比如一些第三方的卖家管理软件有时候会帮助淘宝卖家进行一些自动上下架的操作，这些操作全部是通过定时调用淘宝开放给开发者的自动上下架api进行的，因为后续有新的待操作商品加入，所以调用会每隔几个小时进行一次，调用返回正确结果后再修改本地数据库相关的状态，一个比较的直观的过程是这样：

// 该方法开启事务传播属性为REQUIRED

public void shelveOperation(){

//……other db operation

1 boolean status = ApiUtils.autoShelve();

…….

2 Operation ope = new Operation();

ope.setStatus(status);//status 为操作结果，成功或失败

…….

3 opeDao.insert(ope);

}

以上方法配置了事务，假如2与3步骤之间执行的时候抛出一个异常，所有之前针对数据库的操作都会回滚，但是1步骤却不会回滚，上下架请求已经发送给了淘宝平台，平台已经进行了相应的操作并且返回状态，如果同样对平台的操作作一番回滚，那是一种资源的浪费，而且平台一般会限制这样的操作。

开发一个系统让他能够在常规状况下运行是要花费很多时间和精力的，开发一个健壮的系统使他能够应对各种异常情况，发生错误后我们能够很快定位解决问题，手动乃至自动恢复到正常运行的状态，则需要更细致的思考。

对于以上问题，有一个解决思路是再编写一个定时任务，对于一些失败的状态重新执行，但是由于回滚，最后的失败状态都没记录下来，程序再次定时执行的时候，从本地数据库里获取的状态就会产生误导作用，好像之前从未进行过操作似的，最终导致对请求的重复操作。当然我们可以通过log日志排查解决这些问题，但其自动化和实时性程度毕竟不够。

因此，在开始调用平台的接口之前，可以再执行一个原子性操作：

// 该方法开启事务传播属性为REQUIRED

public void shelveJob(){

boolean result= obj.startShelve();

if(result){

obj.shelveOperation();

}

// 该方法开启事务，传播属性为REQUIRES_NEW

public void startShelve(){

//……other db operation

Operation ope = new Operation();

…….

ope.setStatus(status);// status 为“开始操作”

opeDao.insert(ope);

}

shelveOperation方法改为：

// 该方法开启事务 REQUIRED

public void shelveOperation(){

//……other db operation

1 boolean status = ApiUtils.autoShelve();

…….

2 Operation ope = new Operation();

……

ope.setStatus(status);//status 为操作结果，成功或失败

3 opeDao.update(ope); //新增变成更新操作

}

startShelve()方法主要是做一些准备操作，该新增的记录则新增，并且将相关记录的状态变成“开始操作”，下次如果shelveOperation()执行失败，数据回滚，startShelve()的执行结果依然保存。标注为开启事务的方法传播机制默认为“REQUIRED”，而startShelve()方法则为REQUIRES_NEW。这是为了将它和当前事务独立开来，使startShelve()执行完毕后提交插入的记录，而不被外层调用方法的回滚影响。下面简单罗列下事务的传播属性：

REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。

SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。

MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。

REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。

NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。

PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常

NESTED 如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

定时检查任务会对状态处于“开始操作”或者“失败”的记录状态进行再执行

public void shelveOpeRecoveryJob(){

shelveOpeRecovery();

}

// 该方法开启事务