[发明专利]一种业务延迟方法、装置、计算机设备和存储介质

说明书

本申请涉及一种业务延迟方法、装置、计算机设备和存储介质。方法包括：准备延迟容器，初始化容错标识；执行业务逻辑，遍历每个业务，将可延迟业务存放到延迟容器中，形成可延迟列表；遍历延迟容器的可延迟列表，依次执行可延迟业务。本发明在能够解决问题的同时，能够避免对原有业务产生巨大改动，并且通过封装和容错处理，使得业务使用中能做到安枕无忧。

技术领域

本申请涉及业务开发的技术领域，特别是涉及一种业务延迟方法、装置、计算机设备和存储介质。

背景技术

现有技术在如下场景上存在问题：

场景一：数据库和缓存数据一致性

以订单为例，当订单创建的时候，往往要将订单数据缓存到Redis中，而如果存表的事务未提交，而缓存成功，在后续的操作中又因为数据库事务整体异常回滚，导致缓存不一致的问题。

场景二：数据库事务未及时提交引起脏数据

在数据下发的场景中，要将数据保存到下发表，通过消息队列异步发送给外围，当接收到回执以后，再将数据删除。这时就有可能会出现，存表事务未提交，而下游系统处理速度很快，立即反馈回执。由于前面事务没提交，导致后面的删除操作没有真正删除数据。这样，当原先数据库事务提交后，就会产生了垃圾数据。这类数据其实是已经下发了的数据，而在维护的人员看来，下游可能没有收到该数据，需要手动重新发送一次。

场景三：上下游数据不一致

在业务处理过程中，需要与其他系统交互，这种交互有状态通知，数据分发等等。在将数据保存到数据库中时，如果事务没有提交，就将数据往外围发送，此时，外围系统收到消息，而我＝自身系统因为数据库事务回滚导致业务没有成功。这种场景，就会对整条业务链路造成数据不一致的问题，影响大的情况下可能会波及多个系统。

针对上述问题，目前主流的做法是：为了保证数据库事务回滚的完整性，将非事务的业务逻辑挪到数据库事务之外，当数据库事务成功以后，再执行非数据库事务操作，如果事务失败，则停止执行后续逻辑。

然而上述做法存在如下的缺陷与不足：

1.业务逻辑：在业务中，往往数据库操作和业务操作是成对出现的，比如存入数据库和存入缓存应该是一对操作。假如将存库和存缓存的逻辑分开，则很可能导致业务逻辑割裂，代码不流畅。

2.参数传递：一组数据在存入数据库时，往往需要执行其他的业务逻辑，而单独执行数据库操作，在参数传递上，可能需要有很长的传递链路。

3.业务改造：往往事务和非事务的数据一致性，在正常的业务流程中会被忽略，出现不一致的情况很多时候是因为异常或者并发。因此在业务开发过程中没有注意到对该场景进行事先规划，导致出现问题后，改造代价很大。

发明内容

本发明旨在解决事务和非事务数据一致性的问题。基于此，有必要针对上述技术问题，从后端业务开发或者架构角度，提供一种业务延迟方法、装置、计算机设备和存储介质。

一种业务延迟方法，该方法包括：

准备延迟容器，初始化容错标识。

执行业务逻辑，遍历每个业务，将可延迟业务存放到延迟容器中，形成可延迟列表。

遍历延迟容器的可延迟列表，依次执行可延迟业务。

在一个实施例中，初始化容错标识，包括：将延容错标识修改为已初始化，关闭延容错机制，正常执行功能。

在一个实施例中，执行业务逻辑，遍历每个业务，将可延迟业务存放到延迟容器中，包括：

将业务区分为可延迟业务和不可延迟业务，不改变业务逻辑顺序，依次执行每个业务，执行至可延迟业务时，将可延迟业务存放到延迟容器中，直至所有不可延迟业务执行完。