问个保持数据一致性问题

[我2我骄傲]

比如有个场景：

首先需要在本地数据库插入一条数据，调用第三方接口，在第三方的数据库中插入一条辅助数据，这两条数据保持一致。

现在的疑问是：如果本地数据库插入成功了，再调接口的时候由于各种原因没成功，这时 本地数据库的这条记录就成了

脏数据，想问下，各位是如何处理这种情况的？？？谢谢！

[我2我骄傲]

我以前的做法是：先调用接口 获取返回值 true才 往本地数据库插入数据。

[全栈极简]

可以呀，本来逻辑就是接口操作成功了，才在本地插入一条日志记录。

[wctmac123]

你可以在本地数据库加一个字段 state，比如1代表成功，0代表失败（也就是你说得脏数据），那么你就仍旧可以先插入本地数据库，然后根据接口失败与否来对本地数据库的state字段做更新，这样也方便于你本地查询哪些数据是调用接口失败引起的，如果你不需要做这些记录，也可以在调用失败的时候 直接删了这条数据

[以专业开发人员为伍]

引用 1 楼 jmlovews 的回复:

我以前的做法是：先调用接口 获取返回值 true才 往本地数据库插入数据。

这产生同一个问题。

[以专业开发人员为伍]

不论是本地优先，还是远程优先，都是同一个问题，就是你们在业务设计上都不考虑“两阶段提交数据”。 比如说你以远程优先原则，那么调用远程操作时是否需要两个阶段提交数据？ 如果远程不考虑两阶段提交数据需求，但是你在本地考虑了两阶段提交，那么你自然就是优先调用本地，因为一旦后续调用远程出错，那么本地的数据也不脏（因为还没有实际更新到第二阶段）。反之如果远程服务设计考虑了可两阶段的机制，但是本地不考虑，那么你自然就是优先调用远程的，因为一旦不给远程操作推进到第二阶段，远程数据也不会真正改变。 第一个阶段一般都是大量数据操作，第二个阶段一般都是瞬间完成的“确认信号”，第二阶段出错的可能性极小。

[以专业开发人员为伍]

但是，这种传统的并发数据库提交方法，在今天的大数据时代用的并不普遍。过去几十年的方法在最近几年也会变得其实不太实用。 今天许多系统并发量太大，动不动就上万台服务器、几十个业务步骤，对极其复杂的前置业务操作也需要100毫秒就能把反馈响应给客户端。那么这样的系统许多都是“最终一致性”的，不搞上述数据库这一套繁琐、造成瓶颈的思路。 出现问题的几率很小，出现问题的时候可以再用日志来运行事先编写好的处理措施。而并不使用传统的数据库的那种动不动就“锁”动不动就担心“不安全”的思路。

[大鱼>]

开启一个后台线程呢？你本地修改后存到缓存然后就交给后台线程调用接口成功后删除改缓存数据。不成功继续执行，直到成功为止。不知道是不是适用你的项目。

[我2我骄傲]

引用 8 楼 sp1234 的回复:

但是，这种传统的并发数据库提交方法，在今天的大数据时代用的并不普遍。过去几十年的方法在最近几年也会变得其实不太实用。 今天许多系统并发量太大，动不动就上万台服务器、几十个业务步骤，对极其复杂的前置业务操作也需要100毫秒就能把反馈响应给客户端。那么这样的系统许多都是“最终一致性”的，不搞上述数据库这一套繁琐、造成瓶颈的思路。 出现问题的几率很小，出现问题的时候可以再用日志来运行事先编写好的处理措施。而并不使用传统的数据库的那种动不动就“锁”动不动就担心“不安全”的思路。

谢谢！！！

[我2我骄傲]

谢谢各位！！！

[卧_槽]

插入本地数据时设置状态为未确定，等第三方接口确定成功后修改状态。 再写一个机制处理所有为确定状态数据。

[闭包客]

引用 1 楼 jmlovews 的回复:

我以前的做法是：先调用接口 获取返回值 true才 往本地数据库插入数据。

现在也可以这样做啊。

[okkk]

传统的方法是使用事务 beginTran 成功时commit 失败时 rollback 在高并发时代： 需要在数据结构上处理,就是说需要把“错误数据”记录到 数据记录中，表示已经经历过某种操作，否则表示还未执行该操作，需要系统调度。