1 场景
服务A调用服务B，先插再删。俩请求过去了，落在不同机器节点，可能插入请求因某些原因执行慢些，导致删除请求先执行了，此时因DB没数据，所以啥影响也没；结果这时插入请求过来了，数据就插进去了。
业务意图本应先插再删，这条数据最终应该没了，结果现在先删再插，最后数据还在。建议从业务设计时，不需要这种顺序性的保证，一旦引入顺序性保障，会导致系统复杂度上升，而且会带来效率低下，热点数据压力过大等问题。
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里的序号，来保证接口顺序性。
