例如,我有一个同步(同步)REST 端点和一个异步(异步)REST 端点(它只在几分钟后保存数据并处理它)。
它可能是这样的:
- 异步请求到来 -> 获取数据进行处理
- 同步请求来了并成功运行
- 使用第 1 点的数据启动异步作业
这里的问题是:由于异步请求较早到达我们,它应该下降还是 sunc 请求不应该通过?
同时从同步和异步工作的策略是什么?
UDP: entity = profile - 有状态(NEW, DONE, PROCESS, ERROR)和它自己的生命周期(即第一个人填写然后另一个人确认一切正确,第三个更新并设置价格,所有这些人通过第三方服务与问卷异步工作),您可以同步取消此问卷。
也就是说,我有
- 一个事件来了,我们只保存在数据库中
- 我们同步取消问卷
- 必须处理事件,但配置文件已过期且处理失败
让我试着改写和回答。忘记同步性和异步性。
有一个对象,有 2 个进程改变它。
第三种情况应该是对还是错?一切都取决于逻辑。可能的情况。
这两种选择都存在,并且在实践中无处不在。哪个是正确的,哪个不是全部来自逻辑。例如。纯粹假设您同时从 2 个地方更改帐户数据。如果您更改名称,那么在逻辑上谁在最后谁做得很好,但使用密码就不太一样了。
根本问题不在于有
sync/async,而是有两个并行进程同时进行,它们会更改相同的数据。那些。即使所有方法都是同步的,也会出现完全相同的问题,但它们可以被多个客户端并行调用。并发更改有三种主要的冲突解决策略:
使用哪种策略取决于操作的性质。对于每个操作,您都需要回答“如果它读取和修改的数据并行更改,该操作应该如何正确运行?”的问题。有时这可能需要更改操作 API。
例如,对于银行账户的充值操作
updateAcccount,您可以只传递充值金额(即操作变得更加集中topUpAccount),而不是使用接收账户所有字段的一般操作类型。在这种情况下,可以在发生冲突时自动重新启动操作(即,使用选项 3)。很明显,您需要重新读取数据并确保新的更改不会再次发生冲突。