以前跟开发提过很多次，今天又有人出错了，看样子不经常提不行
这里记录一下，看到的开发人员都注意一下：
这3个问题经常出现，不解决的话，一定会造成经济损失的
1、同一个请求被发送了多次
可能出现的地方：(1)和别人接口对接，别人同一份数据发送了多次
(2)用户在“提交”按钮里点击了多次
(3) 其他可能的一些恶意调用，尤其是涉及支付环节的，危险性非常大
解决办法： (1) 在网页端，用户点击“提交”后，将按钮disable掉
(2) 对于收到的数据插入到数据库或者其他一些地方，做好唯一键控制
能够确定唯一的：订单号，或者几个字段拼凑在一起，或者把时间考虑进去，精确到分钟。整个md5一次，放到一个字段里，加个唯一键
2、同一秒内有多次请求
这个就是并发控制，涉及到抽奖等等需要控制到数量的地方，控制不好，会出现抽奖抽多了，卖东西卖超了等情况
出现的原因也很清晰，同一秒内收到多个请求，分布式的，可能不同的请求会分布到不同的机器或者程序上去执行，都去读取一下计数器(记录卖的数量)，比如：1，每个请求都各自执行读取操作，发现都是1，没有超出1的限制，然后都来修改计数器为0，然后各自都去发货或者发送奖品，结果造成了卖超。
解决办法：
利用数据库或者其他有并发控制的程序来做一个锁的逻辑
利用数据库的话，有一个小技巧提供给大家
伪代码如下：
//字段A里存储的是计数器数字，控制最多奖品数量,1个奖品和多个奖品的逻辑有点不一样，注意下面的伪代码
// 如果是1个奖品
select A from 字段B；
$a = A;
if ( $a == 1)
{
update A=0 where A==1;
//如果执行成功，则可以领取奖品
//这样可以控制并发时只卖掉一个奖品
}
// 如果是N个奖品
select A from 字段B；
$a = A;
if ( $a <= N)
{
update A=A-1 where A<=N and A > 0;
//如果执行成功，则可以领取奖品
//这样可以控制并发时只卖掉N个奖品
}3、分布式系统里的超时控制
如果有这样一个分布式业务：用户购买东西，扣钱成功后发货，发货失败的话，退钱给用户
如果A负责处理业务逻辑
B负责扣钱 C负责发货 D负责退钱
正常逻辑1：A调用 B扣钱成功的话，C发货
正常逻辑2：A调用B扣钱，扣钱成功，调用C发货，C发货失败，调用D退钱
那么A调用C的超时时间一定要足够大，大于C处理发货的时间
否则会出现一种情况：
A调用C发货，超时了，A以为发货失败了，调用D给别人退钱了，结果C发货是成功的，D也把钱退了
所以A调用C发货的系统超时时间一定要远远大于C处理发货的最大时间