首先提出一个问题，让我们考虑一下：在分布式系统中，我们如何确保多个请求的顺序，例如A/B的两个系统，A系统A将三个请求发送给B系统，以一个订单业务向B系统发送一次处理。首先插入订单操作，然后修改订单状态，最后添加用户点。
但是，这三个请求落在不同的机器上，由于某些事故，插入订单的操作被延迟了。首先执行订单操作。
我们应该如何避免这种情况？这需要了解Hua Ge今天所说的：如何确保分布式服务中请求的顺序。
我们可以在A和B系统之间添加访问服务。例如，在上述情况下，完整的业务包含三个请求。在中间的每个请求中，访问服务将根据ID将所有相应的请求发送到某台计算机，以便所有这三个请求都可以通过同一服务来完成操作。
添加[访问服务]后，可以将同一ID的请求分发给同一台计算机。只要系统依次发送系统，系统B也将按顺序接收，但是会有问题。处理接收请求时，这仍然会按消费顺序进行。
实际上，解决此问题的想法是添加一个内存队列并将同一ID的所有请求扔到内存队列中，以允许这些请求排队以消费，以确保多线程的顺序。
通常，以上两个步骤基本上满足了我们的业务需求，但实际上，仍然会有极端条件导致顺序问题。例如，在访问服务的过程中，该订单分布给系统B。对于某些需要100％保证接口序列的系统，我们可以通过访问分布式锁实现。
如上图所示，这三个请求现在已经到达了系统B。除了在每个请求中携带唯一ID之外，请求的订单编号还会引入，并且在每个请求执行业务逻辑之前，您还将请求Zookeeper锁。只能执行获取锁的线程：
通过这三个步骤，可以达到100％的消耗顺序，但是在此通行证之后，系统吞吐量严重减少，尤其是引入分布式锁，成为系统并发的瓶颈。
此外，我们还需要确保引入的中间件的可用性，该中间件得出了一系列解决方案，该解决方案改善了系统的复杂性，并且是对未来维护的挑战。因此，最好的解决方案是是否可以在业务中解决。逻辑。例如，将几个步骤合并为一个步骤或用其他方案替换以避免根。