幂等解疑

r囧r小猫 2022-01-28 03:17 204阅读 0赞

在编程中，[幂等][Link 1]（idempotent）特点就是其任意多次执行所产生的影响均与一次执行的影响相同。幂等的场景有很多，这里不再列举。然而很多人对幂等有一些误解：提到幂等就侃侃而谈悲观锁、乐观锁和分布式锁。这是不对的，其实幂等并不是并发场景下的才有问题，**幂等的核心是确保唯一性，重点是防止数据重复**。

> **关于并发**
> 
> 可以用幂等的手段来解决部分并发场景，也可以使用并发的手段来解决部分幂等，也可[参阅之前文章][Link 2]。

回到主题，如何确保唯一性呢？

### 唯一索引 ###

大概80%的人都会想到：在数据库中建立唯一索引，用作幂等记录，可以防止插入重复的数据。一般采用的手段都是：幂等函数中先执行一次查询操作，如存在幂等记录则返回第一次执行的结果，如不存在幂等记录则继续执行。

**好处**：很简单就能满足分布式场景，并发场景下也可以保证只有一个线程插入成功。

**缺点：**如果所以场景都先落数据到数据库并结合事务使用，成功后再向下执行，一方面存储了很多一次性的数据浪费空间，另一方面数据库性能可能会成为瓶颈。

### 状态机约束 ###

在单据相关的业务，基本会涉及到状态机。通过约束状态机的跳转，就可以做到有限状态机的幂等。比如：订单状态的流转最好满足正向更新，即后一次更新一定大于等于前一次。

### CAS之version 字段 ###

该方案应用非常广泛，version 字段每次更新自动增长，作为乐观锁（compare and sweep）依据，理论上没有性能瓶颈，但局限性很大：仅适用于update。

### SETNX ###

在分布式场景中，新增除了上面利用唯一索引外，还可以使用redis、memcache和zookeeper都可以实现唯一数据。以redis的SETNX：『SET if Not eXists』(如果不存在，则 SET) 。它的使用很特别巧妙，利用一个较短的时间窗口（key的有效期）便可保障一段时间内唯一（并发）。

### 消息有序 ###

对于有些业务如果上面的手段不再适合时，消息端的有序变得尤为重要，应从集群消费端上加以控制（必定单机控制手段很多，比如：一致性 hash 负载均衡策略），可以修改负载均衡策略或mq拉取的规则（如订单号取模），保证同一笔订单的变更始终会被推送到集群中某一台机器上处理，再分配到其中一个**内存队列**中强制排队来确保他们的顺序性，这样就保证一个订单始终在一个内存队列中，并由一个线程去消费，是不是有点RocketMQ局部有序性的味道。优势很明显，放弃唯一索引和SETNX，高性能。但该方案并发完美，如果集群中某一台宕机会需考虑单机控制手段是否满足。![77096705][]

很多时候我们要做到真正幂等，主要考虑分布式集群的环境、去重、并发等。

[Link 1]: https://baike.baidu.com/item/%E5%B9%82%E7%AD%89/8600688
[Link 2]: https://blog.csdn.net/alex_xfboy/article/details/82808216#2.%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81
[77096705]: /images/20220128/11456a9adc444bacbb327f2c519c9f82.png