今天难得和一位阔别已久的老朋友吃饭，谈得甚是欢乐，就不继续向下读书，不如就写写这两天一直在思考的一个话题，同步和异步。
为了降低系统之间的耦合，我们在很多地方用上了消息队列的方式，发送方向消息队列中一扔。接收方等到有空的时候去消费，处理后续逻辑，完美解耦，互不等待，减少依赖。
这个特性看上去很美，不过实际情况中似乎并没有想象中完美。先不说中间件处理带来的复杂度和可能的失败点，就具体发送后不管的情况在大多数情况也不成立。
举一个取消运单的case，当一个运单在TMS中被取消后，我们要同步给上游系统，让他也取消。那么我们发出了一个包含取消运单的消息给上游。OK，完美发送，没有瑕疵，我们的运单也自然取消了。可是结果因为上游系统的限制，在上游系统取消失败了，这就产生了一个状态的不同步。这个状态的不同步要花费比较长的时间来解决。
比如我们用了一个ACK消息来处理这样的问题，说上游系统在处理完消息后给我们一个确认，成功了还是失败了，成功了万事大吉，失败了要做一系列特殊处理。
如此看来似乎“发送后不管”的目标并没有达到，仔细想想这个发送后不管并不是一个技术方案，而是一个业务场景，是否可以做到发送后不管是业务需要来决定的。
看看在我们的场景里有没有能做到发送后不管的情况？仔细想了想，真的不多。可能在最近从I系统同步地理信息是一个例子，那是因为I系统处于主导地位，把自己的数据发出来即可，接收系统你们各凭本事去处理。比较遗憾的是，我们系统中这样的场景似乎不多。
既然在大多数场景中发送方都要管一下对方的成功与失败，我们再简单分析一下异步的管和同步的管的区别，显然同步的管比异步的管在多数场景中要更简单一点，即时处理和事后补偿处理显然补偿的逻辑要复杂一点，比如上面这个案例来说我可以实时告诉用户取消失败了，让他做xxx调整后再试。
那么异步似乎就没有什么用武之地了吗？当然也不是，异步有一个非常好的特点叫发送后不等，就是我可以暂时不管成功与否，先进行后续操作，等待对方的反馈后再根据少数的意外情况做应对。这是在对方无法做出实时响应的情况下唯一的选择。
小结一下：1, 异步操作也必须要提前考虑对方的成功与否，保证做好应对。
2, 在对方能够快速给出响应的情况里，可以考虑同步调用，通常更简单也更直接。
网友评论