下面是一道面试题，而且我完全想不到我会卡到这道题上，因为也了解过一些分布式问题的解决方案
题目：微服务之间的调用路径为 A->B->C，问如果B调用C的时候一直出问题（比如C宕机），我们如何保证数据一致性？
在我理解，这就是典型的分布式事务问题，所以我考虑如下方案：
1. MQ：无论A、B、C监听事件失败消息，并针对不同业务类型和业务id进行回滚操作即可
2. TCC：每个服务都开发T、C、C三种类型的接口，A调用B的Try操作成功，当B调用C的Try失败次数达到阈值后，先执行自己的业务Cancel方法，然后调用A的Cancel接口
3. 软状态：A调用B的时候执行为预操作状态，B调用C如果成功也执行为预操作状态，这样无论哪一环出了问题，都不会影响业务数据的一致性。因为中间状态的数据，对于业务一定是不可用的状态。我们只需要在调用失败的时候做出相应的通知等其他处理策略即可（比如通知+人工，定时任务处理软状态等）。如果都执行为预操作状态成功，再触发修改为执行状态
然后我说这就是分布式事务的问题，比如两阶段提交什么的都可以解决，然后面试官紧接着来了一句话“其实可以不用分布式事务来解决的”，这是我就陷入了困惑，难道是B调用C一直失败的时候，B直接打印日志通知人工处理？还是调用失败后我们插入表，等C恢复后批量处理数据？或者直接回滚A->B的操作？
