前言
先抛出一个问题大家思考一下：在分布式系统中，我们如何保证多个请求的顺序性问题，比如有A/B两个系统，系统A在一次订单业务处理中，向B系统发送三次请求，先进行插入订单操作，然后对订单状态进行修改，最后增加用户积分。
但是这三次请求分别落在了不同的机器上，并且插入订单的操作由于一些意外导致延迟，修改订单操作先执行了，但是此时并没有订单信息，也就会出现我们期望之外的结果了。
那面对这种情况我们应该如何避免呢，这就需要了解花哥今天说的：分布式服务中，如何保证请求的顺序性。
增加接入服务
我们可以在A、B系统之间增加一个接入服务，比如上述场景中，一次完整的业务中包含了三个请求，在每一次请求时，都携带一个唯一id作为标识传入到接入服务中，接入服务根据id，将对应的请求全部分发到某一台机器上，这样这三次请求就能全部由同一台服务来完成操作。
增加队列
增加【接入服务后】，能够让相同id的请求分发到同一台机器，只要系统A顺序发送，那系统B也会顺序接收，但是还会出现一个问题，就是如果系统B中是以多线程的方式处理接收到的请求时，这样还是会出现消费顺序的问题。
其实解决这个问题的思路就是增加一个内存队列，将相同id的请求，全部丢到一个内存队列中，让这几个请求进行排队消费，这样就可以保证多线程下的顺序性。
分布式锁保证顺序性
在一般的情况下，上述两步基本满足了我们的业务需求，但其实还是会存在极端情况导致顺序性问题，比如接入服务分发过程中，将顺序异常分发到系统B中。对于一些需要100%保证接口顺序性的系统，我们可以通过接入分布式锁来实现。
如上图，现在三条请求都已到达系统B中，每个请求中除了携带唯一id外，还带上本次请求的顺序编号ord，并且在每个请求执行业务逻辑之前，都会去请求zookeeper锁，只有获取到锁的线程才能执行：
- 如果删除请求率先获取锁，它在执行业务逻辑前，会去数据库中判断新增请求、修改请求是否已经完成，如果没有完成，就将锁释放；
- 接下来新增请求获取到锁，它判断当前请求的执行顺序ord=1，可以执行，因此就会去数据库中插入数据，并释放锁；
- 接下来如果删除请求获取到锁，它依旧会去数据库中查询，发现修改请求还没有完成操作，因此继续释放当前锁资源；
- 修改请求获取到锁，发现数据库中已经存在记录，因此对该订单状态修改，并释放锁；
- 删除请求获取锁，并完成删除操作，最后释放锁。
缺陷
通过以上这三个步骤，可以实现100%的消费顺序性，但是这一通操作下来，系统的吞吐量严重下降，特别是分布式锁的引入，成为系统并发的瓶颈。
除此之外，我们还需要保证引入的中间件可用性，衍生出一连串的解决方案，提升了系统的复杂性，对日后的维护都是一种挑战。因此，最好的方案就是能不能在业务逻辑上解决，比如将几个步骤合并为一步或者用其他方案代替，从而在根上避免。