其实分布式系统接⼝的调⽤顺序，也是个问题，⼀般来说是不⽤保证顺序的。但是 有时候 可能
确实是需要 严格的顺序 保证。给⼤家举个例⼦，你服务 A 调⽤服务 B ，先插⼊再删除。好，结
果俩请求过去了，落在不同机器上，可能插⼊请求因为某些原因执⾏慢了⼀些，导致删除请求
先执⾏了，此时因为没数据所以啥效果也没有；结果这个时候插⼊请求过来了，好，数据插⼊
进去了，那就尴尬了。
本来应该是 “ 先插⼊ -> 再删除 ” ，这条数据应该没了，结果现在 “ 先删除 -> 再插⼊ ” ，数据还存
在，最后你死都想不明⽩是怎么回事。
所以这都是分布式系统⼀些很常⻅的问题。
⾯试题剖析
⾸先，⼀般来说，个⼈建议是，你们从业务逻辑上设计的这个系统最好是不需要这种顺序性的
保证，因为⼀旦引⼊顺序性保障，⽐如使⽤ 分布式锁 ，会 导致系统复杂度上升 ，⽽且会带来 效
率低下 ，热点数据压⼒过⼤等问题。
下⾯我给个我们⽤过的⽅案吧，简单来说，⾸先你得⽤ dubbo 的⼀致性 hash 负载均衡策略，
将⽐如某⼀个订单 id 对应的请求都给分发到某个机器上去，接着就是在那个机器上，因为可能
还是多线程并发执⾏的，你可能得⽴即将某个订单 id 对应的请求扔⼀个 内存队列 ⾥去，强制排
队，这样来确保他们的顺序性。
但是这样引发的后续问题就很多，⽐如说要是某个订单对应的请求特别多，造成某台机器成 热
点 怎么办？解决这些问题⼜要开启后续⼀连串的复杂技术⽅案 ...... 曾经这类问题弄的我们头疼不
已，所以，还是建议什么呢？
最好是⽐如说刚才那种，⼀个订单的插⼊和删除操作，能不能合并成⼀个操作，就是⼀个删
除，或者是其它什么，避免这种问题的产⽣。