社区编辑申请
注册/登录
SQL 设计模式 | 关系型数据库的幂等性处理
数据库 其他数据库
来看关系型数据库的 DML 的幂等性处理。在库存管理软件中,对同一批货物操作增删改,就可能带来负面影响。

在 IT 的很多术语中,正向解释非常难,反向描述反而更容易懂。幂等性处理就是这类。

举两个数据处理时,非幂等性常见的场景:

1.在创建订单时,偶有因网络抖动,痴呆,掉线等因素,造成客户端与服务器之间通讯不畅。比如,客户端发起请求后,在约定时间内(通常 30秒),没有得到服务器的反馈,导致重复发起创建订单的请求,实际上前面看似失败的订单已创建成功,最终造成创建两个甚至多个同样的订单

2.重复扣款,扣库存。这个是最不能容忍的。如前所述,客户端重新不断发起扣款、扣库存的请求,会导致账目混乱。

由此可见,做好程序的幂等性处理,非常重要!

很多教科书,会笼统的说,幂等性处理是一种最终返回结果一致的程序处理。这么讲,不完美。幂等性处理,不仅对结果有约束,对处理造成的负面影响也有约束。

来看关系型数据库的 DML 的幂等性处理。在库存管理软件中,对同一批货物操作增删改,就可能带来负面影响。

比如在苹果门店的仓库管理软件中,某天门店客流量非常大,操作库存也比平时频繁了很多。这样一来,给库存管理就带来了风险。

比如某台结算终端,就因为访问人数过多,经常掉线,超时。小王好不容易卖出去两台,结果死活就是结账不成功,连续操作4,5次后无果后,小王叫店长来重启了电脑。

等重启后,结算是成功了,但库存为 0 了。店长跑去仓库一看,10 台 iPhone 13 都好好躺在那里,为什么库存为 0 了呢?

这就是非幂等性处理造成的。客户端发起交易后,网络堵塞,结账请求一直没发成功。等计算机重启后,连续将之前的订单,重复发送了 10次,结果库存全扣没了。

看下库存表的设计:

create table ProductInventory(
ProductLotId INT,
ProductName VARCHAR(200),
ProductInventoryVolume INT )

iPhone 13 库存是这样的:

ProductLotId   ProductName   ProductInventoryVolume
A0001 iPhone13 10

更新程序也挺简单:

UPDATE ProductInventory 
SET ProductInventoryVolume = ProductInventoryVolume - 1
WHERE ProductLotId = 'A0001'

由此可见,是连续的交易请求,让库存清 0 了。

于是,第一种幂等性处理方法就来了 - UUID 通用唯一标识符:


CREATE TABLE ProductSalesTransactionAudit(
AuditId BIGINT,
RequestUUID UniqueIdentifier,
RequestCompleted BIT )

在每次请求中,加入一个 RequestUUID(Universally Unique Identifier,通用唯一标识符, Java/C#/Python 等编程语言均有实现 UUID 的库)

在数据库端维护一张表 ProductSalesTransactionAudit,若有请求被数据库接收到,先去该表查询是否存在.

若存在且 RequestCompleted 为1,就表示该请求被数据库正确处理过,可以跳过这次处理,并将 RequestCompleted 返回给客户端;没有,则在这表里插入一行,且把数据库的处理结果,更新到 RequestCompleted.

这样,一个可行的幂等性处理,就完成了。但不是十分完美,因为该表数据量,会显著性增长,造成性能缓慢。

于是,要寻找下一种幂等性处理方案。

接下来再看这个例子,依旧是以苹果这家门店为例。

某天仓库中剩余 10只 iPhone 13. 小王和小黄同时销售出去 2只,理论上剩下 6只。按照正常操作,小王和小黄在操作库存时,同时看到有 10只,每人减去 2只,剩余 8只,由于看不到对方的操作,因此显示 8只剩余时,两个人都没觉得库存错了。

create table ProductInventory(
ProductLotId INT,
ProductName VARCHAR(200),
ProductInventoryVolume INT )

小王和小黄,同时查询 iPhone 的库存时,是这样:

ProductLotId     ProductName    ProductInventoryVolume
A0001 iPhone 13 10

他俩抓取后,经过他俩各自的本地计算(网页端或手持设备),变成了这样:

ProductLotId   ProductName   ProductInventoryVolume
A0001 iPhone 13 8

当他们把本地数据上传时,无论谁先,数据库最终的 iPhone 13 的存量,都成了 8. 但事实上,错的离谱,店长要骂娘!

那么平时我们设计系统时,该怎么处理这种意料中的错误呢,这里涉及到事务管理的技巧。

有一种乐观派做法是,在库存表上,加一列,标识行的版本。当本行数据更新时,首先对比这个版本列,若相同,则更新,若不同,则报 ”您修改的数据,已被其他人抢先更新,请确定后再次保存“ 的提示,最后标识列会被自动更新。

接下来,实现上面这种版本控制的做法:

create table ProductInventory(
ProductLotId INT,
ProductName VARCHAR(200),
ProductInventoryVolume INT
ProductLotTS timestamp)

原库存是这样:

ProductLotId   ProductName   ProductInventoryVolume    ProductLotTS
A0001 iPhone 13 10 2022050114364700001

他俩抓取后,经过各自的本地计算,变成了这样:

ProductLotId ProductName ProductInventoryVolume   ProductLotTS
A0001 iPhone 13 8 2022050114364700001

当小王上传数据时,程序会同时以 A0001 + 2022050114364700001 作为更新条件,先将 ProductInventoryVolume 更新成8,同时因 timestamp 是系统自动更新的对象,已经变成了 2022050114364700002 .

等到小黄再更新,程序也同样同时以 A0001 + 2022050114364700001 作为更新条件,发现 ProductLotTS 已经改变了,意味着在读取数据后,有别人先一步做了更新,此时小黄更新库存就会失败。他必须重新读取数据后,再操作。

只要一次更新成功,ProductLotTS 就会改变,即使相同的请求再发送一遍,也会因为 ProductLotTS 不匹配,导致失败!

这就是第二种幂等性处理程序,不仅仅做了防重复处理,还能省去一张表的维护代价。

责任编辑:武晓燕 来源: 有关SQL
相关推荐

2022-05-18 23:42:08

网络安全安全分析工具

2022-04-01 10:08:21

SQL 优化MySQL数据库

2022-04-19 14:41:29

Oracle数据库SQL

2022-05-20 14:54:33

数据安全数字化转型企业

2022-05-12 23:38:19

SQL数据库字符串

2022-05-16 13:37:12

Sysrv僵尸网络微软

2022-05-11 15:08:52

驱动开发系统移植

2022-04-25 11:26:16

开发SpringBoot

2022-05-11 14:48:33

腾讯云寿险民生保险

2022-05-18 08:05:31

2022-04-25 14:41:15

甲骨文数据库机数据库

2022-05-12 14:44:38

数据中心IT云计算

2022-05-10 10:02:51

2022-05-05 15:56:43

数字化转型锐捷网络

2022-05-24 08:21:16

数据安全API

2022-04-23 16:58:24

微服务微服务架构

2022-04-28 09:46:20

Nginx文件Linux

2022-05-17 11:46:48

高并发服务数据库

2022-04-22 14:41:12

美团慢查询数据库

2022-04-20 11:57:30

物联网人工智能

同话题下的热门内容

Abase2:字节跳动新一代高可用 NoSQL 数据库金融业分布式数据库选型及HTAP场景实践谈谈对 Database Plus 认识与畅想再有人问你什么是分库分表,直接把这篇文章发给他​基于智能数据库的自助式机器学习Flink SQL 知其所以然:SQL DDL!每个后端都应该知道的八个提升 SQL 性能的 Tips

编辑推荐

几款开源的图形化Redis客户端管理软件推荐NoSQL数据库概览及其与SQL语法的比较为什么MongoDB敢说“做以前你从未能做的事”Python操作MongoDB看这一篇就够了一文看懂分布式数据库原理和 PostgreSQL 分布式架构
我收藏的内容
点赞
收藏

51CTO技术栈公众号