06 | 每个工程师都应该了解的：聊聊幂等

如何测试是否达到幂等呢？是否存在一些方法论呢？特别是在大量使用开源软件等第三方技术和平台的时候，如果不是很清楚里面的坑，心里特别没底，但是我们没有那么多精力深入每一个细节。

这里说的数据库“竞争条件”就是“脏读”吧。打个比方： 小张和小华同时喜欢上小芳，小张在探得小芳未婚后首先展开追求，并确定了关系。小华在几经打探确定小芳未婚后也打算采取行动，但在他准备行动的过程中小张和小芳闪婚了，使得上次的打探结果无效。 简单来说大概是“你读的时候并不知道别人也已经读过并已经采取了一些行动，只是行动尚未达成，对你不可见而已”

第一次听到这样的概念，学到了

6年前曾设计了一个发短信然后银联自动给校园一卡通充值的系统，当时就是使用消息驱动，基于事物ID的幂等性，超时重发机制处理错误，最终效果不错。

例子中，幂等令牌的生成，不应该客户端完成，客户端只能保证单机幂等令牌的唯一性，不能保证全站幂等令牌的唯一性。

做消息队列的consumer时候，特别要重视幂等信，保证相同的消息不论监听到多少次，也只能做处理一次

幂等操作确实很重要，除了文章支付的例子之外，像购物车占用库存操作，也是需要幂等的，不然可能出现超卖少卖现象。

重复执行工单，多次下发操作数据 也会出现幂等情况。需要增加操作令牌以保证同一个资源数据只能操作一次

我来尝试回答一下，为什么只是读检查会发生race condition，而只有写入database as primary key才可以正确的检查到是否是相同的idempotency key： 考虑一个用户第一次发出了请求，但是超时了，然后他接着发出了第二次请求，但是第一个请求由于网络堵塞的原因，这个时候才跟第二个请求同时到达服务器。我server端的逻辑是： try { db.get(idempotencyKey); } catch (ObjectNotFoundException e) { processPayment; db.write(idempotencyKey); } 那么在上述的情况下，第一个跟第二个请求都会进入到exception的处理逻辑处，然后process payment。就会发生重复，即使是我后面只成功写入db一个order record。（因为primary key constrains idempotency id）。 那么如果修改成 try { db.write(idempotencyKey); processPayment; } catch (WriteException e) { return "success"; } 这样只有成功写入idempotencykey到db之后才可以处理payment，否则会返回该order已经成功处理

不光是互联网支付，其实企业内部的对外支付也是一样，只要把微信服务端替换成银行就行了