这事你要问chatGPT

没有具体的业务场景么，一般可以给一个批次的请求带相同的流水号，记录对应的执行状态，多次调用根据状态判断是执行还是跳过，再起一个定时任务清理过期的请求批次

操作系统的进程控制， 通过记录性信号量来实现进程的前驱关系。 放到应用里里就是控制线程的前驱关系
设 信号量 b 和信号量 ab 。
设 p(b)操作表示信号量b不为0可以往下操作，v(b)表示为信号量+1。
具体操作
设 b ab初始信号量为0
执行b接口 结束时v(b)
执行a接口 入口处p(b) 结束时v(ab)
执行c接口 入口处p(ab)

三个接口属于同一个任务id，用共享变量记录这个id的行为，每次接口执行的时候查一下

没懂场景 微服务？还是单体？ 单体用缓存记录业务ID 微服务不就是消息队列加redis吗

看了上面的解答一个都看不懂，这是几年的面试题

金融部门，经常有类似的需求
使用高可扩展的状态机。
abc三个接口只是普通例子，状态机支持10个、100个接口(业务逻辑)乃至更多接口按一定顺序执行
本质上还是延迟队列 + 拓扑图 + 分布式锁 的概念

我一个一个call下来，哪一步出错了就哪一步跳异常不就好了？为啥要搞那么复杂

还搞个名词三个的幂等性 毛关系

轮询

幂等和几个接口没关系吧。不都是那一套吗。感觉你这个更像是分布式事务呢

做嵌入式的表示 给信号量？

就是考幂等啊