分布式系统开发库存超卖的解决方法

这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处理发货的最大时间