我看小米抢购

这几天分析小米抢购机制的帖子网文很多。我也来浅析一下，小米具体的没看，但原理相通。 

鄙人曾在某知名网站做技术。做了一个很复杂的抢票系统，至今在用。 

需求是这样的，网站会跟商业公司合作做一些推广，送出一些演出门票，数码产品什么的让网友来抢。 

第一次上线抢票，只放了一张门票，送个数码相机，再送飞机票。数据库里只放一条记录，第一个网友进来了就立即删除。其他网友全部提示“没抢到”，但也让网友留信息。第一次成功了。 客户很满意，尤其看到了很多热心网友留的信息。 

第二次放20张门票，还沿用第一次的系统设计，放20条记录，在网友抢走了几张票后，后台数据混乱了，票超发了（放出去了不到30张），客户也认了。（这种故障12年的淘宝双十一也出现过） 。 

后来分析，不能在一开始就让所有请求都操作数据库，直接连库MySQL扛不住，主从就超发，加缓存超发估计会更严重。 

解决办法： 

1.让用户分流，让部分用户直接返回“没抢到”，不请求数据库 。 

2.如果还不行就，错开峰值 ，高峰期全部用户都不请求数据库，全部返回“没抢到”。 

分流我们的办法比小米高明，网友猜测不到，每一个请求分配一个随机数，跟编辑设置的“阀值”比较，比阀值大就请求数据库，再判断奖品还有没有。小米傻到直接在页面上上空链接。大傻。 

错开峰值，就是抢票刚开始时，其实库里奖品数量是0，全部返回“没抢到”，过了高峰期再放出来抢。（小米这次20分钟抢完，估计也是这样的） 

分布部署，我们直接用于前端响应的server大概有20台，直接挂在F5上的，修改配置，让其中的n台程序就不访问数据库，直接返回“没抢到”。 

现状：编辑可以自由的控制奖池中奖品的数量，设置“阀值”大小改变抢中的概率，分不同时段放票，来维持活动的热度。