分布式系统接口的调用顺序一般无需保证的，但有时候确实需要严格的顺序保证。
案例服务 A 调用服务 B，先插入再删除。
俩请求过去了，落在不同机器，可能插入请求因某些原因执行慢了一些，导致删除请求先执行了，此时因为没数据所以啥效果也没。
结果这时候插入请求过来了，数据插进去了！
本该 “先插入 => 再删除”，这条数据应该不存在，但现在 “先删除 => 再插入”，数据还存在！
所以这都是分布式系统一些很常见的问题。
解决方案推荐从业务逻辑上设计的系统最好是不需要这种顺序性保证，因为一旦引入顺序性保障，那就要使用分布式锁，导致系统复杂度上升，效率低下，热点数据压力过大。
简单来说，首先你得用 Dubbo 的一致性 hash 负载均衡策略，将比如某一个订单 id 对应的请求都给分发到某机器，接着就是在那个机器上因为可能还是多线程并发执行，你可能得立即将某个订单 id 对应的请求扔一个队列，强制排队确保他们的顺序性。
但这样引发的后续问题就很多!
比如说要是某个订单对应的请求特别多，造成某台机器成热点怎么办？解决这些问题又要开启后续一连串的复杂技术方案…曾经这类问题弄的我们头疼不已，所以，还是建议什么呢？
最好是比如说刚才那种，一个订单的插入和删除操作，是否能合并成一个操作，比如就是一个删除，避免这种问题产生。
