分布式服务接口请求的顺序性如何保证？

问题

　　其实分布式系统接口的调用顺序，也是个问题，通常来讲是不用保证顺序的。可是有时候可能确实是须要严格的顺序保证。给你们举个例子，你服务 A 调用服务 B，先插入再删除。好，结果俩请求过去了，落在不一样机器上，可能插入请求由于某些缘由执行慢了一些，致使删除请求先执行了，此时由于没数据因此啥效果也没有；结果这个时候插入请求过来了，好，数据插入进去了，那就尴尬了。

　　原本应该是 “先插入 -> 再删除”，这条数据应该没了，结果如今 “先删除 -> 再插入”，数据还存在，最后你死都想不明白是怎么回事。

　　因此这都是分布式系统一些很常见的问题。

剖析

　　首先，通常来讲，我的建议是，大家从业务逻辑上设计的这个系统最好是不须要这种顺序性的保证，由于一旦引入顺序性保障，好比使用分布式锁，会致使系统复杂度上升，并且会带来效率低下，热点数据压力过大等问题。

　　下面我给个咱们用过的方案吧，简单来讲，首先你得用 dubbo 的一致性 hash 负载均衡策略，将好比某一个订单 id 对应的请求都给分发到某个机器上去（及须要保证顺序性的操做请求放到一个机器去处理），接着就是在那个机器上由于可能仍是多线程并发执行的，你可能得当即将某个订单 id 对应的请求扔一个内存队列里去，强制排队，这样来确保他们的顺序性。

　　可是这样引起的后续问题就不少，好比说要是某个订单对应的请求特别多，形成某台机器成热点怎么办？解决这些问题又要开启后续一连串的复杂技术方案......曾经这类问题弄的咱们头疼不已，因此，仍是建议什么呢？

　　最好是好比说刚才那种，一个订单的插入和删除操做，能不能合并成一个操做，就是一个删除，或者是什么，避免这种问题的产生。

 

 出处：https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/distributed-system-request-sequence.md