2017-11-24如何测试是否达到幂等呢？是否存在一些方法论呢？特别是在大量使用开源软件等第三方技术和平台的时候，如果不是很清楚里面的坑，心里特别没底，但是我们没有那么多精力深入每一个细节。 18
2018-06-10这里说的数据库“竞争条件”就是“脏读”吧。打个比方：
小张和小华同时喜欢上小芳，小张在探得小芳未婚后首先展开追求，并确定了关系。小华在几经打探确定小芳未婚后也打算采取行动，但在他准备行动的过程中小张和小芳闪婚了，使得上次的打探结果无效。
简单来说大概是“你读的时候并不知道别人也已经读过并已经采取了一些行动，只是行动尚未达成，对你不可见而已” 10
2017-11-30第一次听到这样的概念，学到了 7
2017-11-286年前曾设计了一个发短信然后银联自动给校园一卡通充值的系统，当时就是使用消息驱动，基于事物ID的幂等性，超时重发机制处理错误，最终效果不错。 4
2017-11-24幂等操作确实很重要，除了文章支付的例子之外，像购物车占用库存操作，也是需要幂等的，不然可能出现超卖少卖现象。 4- 2017-12-04做消息队列的consumer时候，特别要重视幂等信，保证相同的消息不论监听到多少次，也只能做处理一次 3
2017-11-27重复执行工单，多次下发操作数据 也会出现幂等情况。需要增加操作令牌以保证同一个资源数据只能操作一次 3
2018-05-10例子中，幂等令牌的生成，不应该客户端完成，客户端只能保证单机幂等令牌的唯一性，不能保证全站幂等令牌的唯一性。 2
2017-11-27不光是互联网支付，其实企业内部的对外支付也是一样，只要把微信服务端替换成银行就行了 2
2017-11-24学习了，分享给小伙伴们看看 2
2018-11-05我来尝试回答一下，为什么只是读检查会发生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已经成功处理展开 1
2017-11-24其实 我是第一次听说幂等的概念，虽然平常遇到很多幂等的问题 1
2019-04-10幂等的唯一性很重要，尤其是支付的场景
2019-02-28幂等性我公司一般用第一种方法，但是，其实第二种我觉得也不错。无论是幂等令牌的实现，还是保证唯一性，都很容易实现有问题，大多倾向于很容易用读来判断是否有遇到过，这是有问题的。
2018-12-25“making multiple identical requests has the same effect as making a single request. 我觉得需要强调事 是identical的，不然乍一看为什么多次请求只给我一个结果，会有点疑惑。个人意见～
2018-11-17要详细学习下
2018-05-04问一个细节问题，为什么不能读检查而要靠写入报错来判断唯一性？因为我认为按一般的逻辑，是去数据库里面查有没有这个唯一值。不太明白读与读之间有竞争这个原因。谢谢回复。
2018-03-13能不能举个例子解释一下什么是竞争条件
2017-12-24大并发测试幂等