1 问题
服务A调用服务B，先插入再删除。俩请求过去了，落在不同机器上，可能插入请求因为某些原因执行慢一些，导致删除请求先执行了，此时因为没数据所以啥效果也没有；结果这个时候插入请求过来了，好，数据插入进去。
本该先插入再删除，这条数据应该没了，结果现在先删除再插入，数据还存在。
建议从业务逻辑上最好设计的这个系统不需要这种顺序性的保证，一旦引入顺序性保障，会导致系统复杂度上升，而且会带来效率低下，热点数据压力过大等问题。
2 方案
2.1 一致性hash 内存队列
将比如某个订单id对应的请求都给分发到某机器，在那个机器上因为可能还是多线程并发执行，你得立即将某个订单id对应的请求扔一个内存队列，强制排队，确保顺序性。
但这样后续问题很多，比如某订单对应请求特别多，造成某台机器成热点怎么办？解决这些问题又要开启后续一连串的复杂技术方案。
2.2 分布式锁
使用基于zk的分布式锁，实现接口调用的强顺序性。
服务A发送的三个有序请求请求1、2、3，依次发到MQ，然后服务B的多个实例从MQ消费。假如分别是三个实例拿到1、2、3三个请求，则当请求执行时需从zk获取锁，才能执行。所以此时A还要指明这三个请求的执行顺序，即seq=1、2、3，服务B才知道执行顺序。
这时三个请求都来获取锁：
- 如请求3先获取到锁，然后看Redis这个list是否有比自己小的序号，有（1、2）则释放锁
- 然后若请求1拿到锁，也去Redis判断是不是有比自己小的序号，无，就能执行请求1，然后从Redis的list里删掉该序号
依次同理获取锁 =》判断是否有更小的序号 =》删除Redis里的序号，来保证接口顺序性。
