5.4 服务幂等性设计

什么是幂等性

幂等性最初是一个数学概念,后来被引入计算机科学中,用来描述某个操作可以安全地重试,即多次执行的结果与单次执行的结果完全一致。

柔性事务普遍基于“最大努力交付”机制。也就是说,当网络通信失败、节点宕机或者进程崩溃时,采用重复请求的方式来容错。因此,如果某些关键服务不具备幂等性,重复处理可能导致数据不一致或其他风险。例如,在退款接口中,缺乏幂等性可能导致重复退款。

接下来,笔者将介绍两种实现系统幂等的方式,供读者参考。

5.4.1 全局唯一 ID

全局唯一ID 是在应用层使用最广泛的一种。它的核心思想是为每个操作生成一个独一无二的标识符,以此来判断是否已经执行过该操作。

全局唯一 ID 的实施步骤如下:

  • 生成唯一 ID:在每次执行操作前,根据业务操作内容生成一个全局唯一ID,这个 ID 可以利用 UUID、雪花算法(Snowflake) 、Uidgenerator 或 Leaf 等算法生成。
  • 附加到请求: 将生成的唯一 ID 附加到请求中,作为请求的一个参数、HTTP 头或请求体的一部分。
  • 处理请求: 在服务器端,接收到请求后,首先检查这个唯一 ID:
    • 如果 ID 已存在:说明该请求已经被处理过,服务器可以直接返回之前的响应结果,避免重复处理。
    • 如果 ID 不存在:执行请求的操作,并将操作结果和该 ID 存储在数据存储中(如数据库、缓存等),以供后续请求检查。

值得一提的是,唯一ID 生成算法 snowflake,取自世界上没有两片相同的雪花之意。在使用分布式部署的情况下每秒可生成百万个不重复、递增 id。已经广泛应用于需要分布式系统中生成唯一标识符的场景。

5.4.2 乐观锁

接下来,再看数据库中关于修改相关的操作。

假设有一个账户表 accounts,包含字段 id(账户ID)和 balance(账户余额)。现在要给账户 ID 为 1 的账户增加余额

UPDATE accounts SET balance = balance + 100 WHERE id = 1;

如果这个SQL语句执行一次,那么账户的余额会增加100。但是如果由于某些原因(比如网络重试或者程序逻辑错误),这个 SQL 语句被执行了两次,那么账户的余额将会增加 200,而不是预期的 100。

每次执行这个语句都会对账户余额产生不同的影响,这也是典型的非幂等性操作。对于此类的非幂等性操作,我们看看使用乐观锁(Optimistic Locking)如何解决。

乐观锁基本思想是,在执行更新操作时,假设不会发生冲突,因此不加锁;只有在提交更新时,才检查数据是否被其他事务修改过。如果数据未被修改,则提交;如果被修改,则回滚或重新尝试。

结合上述增加余额的 SQL,请看下面具体的操作:

  • 增加版本号字段:在涉及更新的数据表中增加一个version字段,每次更新数据时,版本号增加。
  • 更新时检查版本号:在执行更新操作时,通过WHERE子句检查当前版本号是否与读取时的版本号一致,如果一致则执行更新,并更新版本号。
  • 重试机制:如果更新操作因为版本号不一致而失败,可以实施重试机制,直到更新成功或达到重试次数限制。
UPDATE accounts 
SET balance = balance + ?, 
    version = version + 1 
WHERE id = ? AND version = ?;

在这个例子中,? 代表将要被更新的数值,id 是账户的唯一标识符,version 是用于检查数据在读取后是否被修改的版本号。

如果更新操作因为版本号不匹配而失败,可以重试更新,直到成功或达到最大重试次数。这样即使在高并发环境下,也可以确保数据的一致性,并且每次更新操作都是幂等的。

上面实现乐观锁的方式,是一种典型的 CAS(Compare And Swap | Compare And Set,比较并交换)操作,CAS 有时也被称为轻量级事务。由于乐观锁不需要在读取和写入时持有锁,在系统冲突不频繁的情况下(也就是读多写少的场景),乐观锁除保证一致性之外,还可提供更好的并发性能。

总字数:1226
Last Updated:
Contributors: isno