幂等性问题

一个分布式系统中的某个接口，该如何保证幂等性？这个事儿其实是你做分布式系统的时候必须要考虑的一个生产环境的技术问题。啥意思呢？
你看，假如你有个服务提供一些接口供外部调用，这个服务部署在了 5 台机器上，接着有个接口就是付款接口。然后人家用户在前端上操作的时候，不知道为啥，总之就是一个订单不小心发起了两次支付请求，然后这俩请求分散在了这个服务部署的不同的机器上，好了，结果一个订单扣款扣两次。
或者是订单系统调用支付系统进行支付，结果不小心因为网络超时了，然后订单系统走了前面我们看到的那个重试机制，咔嚓给你重试了一把，好，支付系统收到一个支付请求两次，而且因为负载均衡算法落在了不同的机器上，尴尬了。。。
所以你肯定得知道这事儿，否则你做出来的分布式系统恐怕容易埋坑。
这个不是技术问题，这个没有通用的一个方法，这个应该结合业务来保证幂等性。
所谓幂等性，就是说一个接口，多次发起同一个请求，你这个接口得保证结果是准确的，比如不能多扣款、不能多插入一条数据、不能将统计值多加了 1。这就是幂等性。
其实保证幂等性主要是三点：

  • 对于每个请求必须有一个唯一的标识，举个栗子：订单支付请求，肯定得包含订单 id，一个订单 id 最多支付一次，对吧。
  • 每次处理完请求之后，必须有一个记录标识这个请求处理过了。常见的方案是在 mysql 中记录个状态啥的，比如支付之前记录一条这个订单的支付流水。
  • 每次接收请求需要进行判断，判断之前是否处理过。比如说，如果有一个订单已经支付了，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId 已经存在了，唯一键约束生效，报错插入不进去的。然后你就不用再扣款了。

实际运作过程中，你要结合自己的业务来，比如说利用 redis，用 orderId 作为唯一键。只有成功插入这个支付流水，才可以执行实际的支付扣款。
要求是支付一个订单，必须插入一条支付流水，order_id 建一个唯一键 unique key。你在支付一个订单之前，先插入一条支付流水，order_id 就已经进去了。你就可以写一个标识到 redis 里面去，set order_id payed，下一次重复请求过来了，先查 redis 的 order_id 对应的 value，如果是 payed 就说明已经支付过了，你就别重复支付了。

服务调用顺序性

一般情况下，分布式系统接口的调用顺序是不需要保证顺序性的，但是有时候确实需要保证严格的顺序。比如你的服务A需要调用服务B，先插入再删除。好，结果俩请求过去了，落在不同机器上，可能插入请求因为某些原因执行慢了一些，导致删除请求先执行了，此时因为没数据所以啥效果也没有；结果这个时候插入请求过来了，好，数据插入进去了，那就尴尬了。
本来应该是 “先插入 -> 再删除”，这条数据应该没了，结果现在 “先删除 -> 再插入”，数据还存在，最后你死都想不明白是怎么回事。
所以这都是分布式系统一些很常见的问题。面试官也有问过这种问题。
首先，一般来说，个人建议是，你们从业务逻辑上设计的这个系统最好是不需要这种顺序性的保证，因为一旦引入顺序性保障，比如使用分布式锁，会导致系统复杂度上升，而且会带来效率低下，热点数据压力过大等问题。下面我给个我们用过的方案吧，简单来说，首先你得用 dubbo 的一致性 hash 负载均衡策略，将比如某一个订单 id 对应的请求都给分发到某个机器上去，接着就是在那个机器上，因为可能还是多线程并发执行的，你可能得立即将某个订单 id 对应的请求扔一个内存队列里去，强制排队，这样来确保他们的顺序性。
image.png
但是这样引发的后续问题就很多，比如说要是某个订单对应的请求特别多，造成某台机器成热点怎么办？解决这些问题又要开启后续一连串的复杂技术方案……曾经这类问题弄的我们头疼不已，所以，还是建议什么呢？
最好是比如说刚才那种，一个订单的插入和删除操作，能不能合并成一个操作，就是一个删除，或者是其它什么，避免这种问题的产生。
如果一定要有一个解答的话，感觉言之有理即可。下面做一个整理：

第一种方案，redis记录

通过加锁的方式，保证请求的串行与执行顺序
image.png
点评：这种方法太重，阻塞的接口会压榨服务器的并发数/吞吐量，只有当请求1失败后其他两个才能释放。
绝对不能本地阻塞，否则多到调用几次整个服务就奔溃了，可以将内容先入库，然后MQ将消息推出去，等会再进行处理，记录失败次数，以此达到一致。

第二种方案：前端串行请求

在不追求高服务体验的时候可以限制下一个请求，当请求1没有处理完成前，前端不会发送第二个请求，并且后端系统在接收到请求2时直接返回错误信息，也可以在前端建立一个队列，按顺序发送请求至后端，后端系统只需要判断顺序是否正常即可。

第三种方案：前置服务

image.png

第四种方案：MQ

image.png
当集群B消费到请求3时，若请求1还未被消费那么集群B直接将消息抛错，扔还给MQ稍后重试，可以通过数据库或redis判断目前消息的执行顺序。

第五种方案：
zk顺序子节点方案。
https://blog.csdn.net/panda_c55/article/details/109079421

1.持久节点(PERSISTENT)

持久节点，创建后一直存在，直到主动删除此节点。

2.持久顺序节点(PERSISTENT_SEQUENTIAL)

持久顺序节点，创建后一直存在，直到主动删除此节点。在ZK中，每个父节点会为它的第一级子节点维护一份时序，记录每个子节点创建的先后顺序。

3.临时节点(EPHEMERAL)

临时节点在客户端会话失效后节点自动清除。临时节点下面不能创建子节点。

4.顺序临时节点(EPHEMERAL_SEQUENTIAL)

临时节点在客户端会话失效后节点自动清除。临时节点下面不能创建子节点。父节点getChildren会获得顺序的节点列表。

顺序节点的名字必须是唯一的。

Container Nodes

TTL Nodes