这几天分析小米抢购机制的帖子网文很多。我也来浅析一下,小米具体的没看,但原理相通。
鄙人曾在某知名网站做技术。做了一个很复杂的抢票系统,至今在用。
需求是这样的,网站会跟商业公司合作做一些推广,送出一些演出门票,数码产品什么的让网友来抢。
第一次上线抢票,只放了一张门票,送个数码相机,再送飞机票。数据库里只放一条记录,第一个网友进来了就立即删除。其他网友全部提示“没抢到”,但也让网友留信息。第一次成功了。 客户很满意,尤其看到了很多热心网友留的信息。
第二次放20张门票,还沿用第一次的系统设计,放20条记录,在网友抢走了几张票后,后台数据混乱了,票超发了(放出去了不到30张),客户也认了。(这种故障12年的淘宝双十一也出现过) 。
后来分析,不能在一开始就让所有请求都操作数据库,直接连库MySQL扛不住,主从就超发,加缓存超发估计会更严重。
解决办法:
1.让用户分流,让部分用户直接返回“没抢到”,不请求数据库 。
2.如果还不行就,错开峰值 ,高峰期全部用户都不请求数据库,全部返回“没抢到”。
分流我们的办法比小米高明,网友猜测不到,每一个请求分配一个随机数,跟编辑设置的“阀值”比较,比阀值大就请求数据库,再判断奖品还有没有。小米傻到直接在页面上上空链接。大傻。
错开峰值,就是抢票刚开始时,其实库里奖品数量是0,全部返回“没抢到”,过了高峰期再放出来抢。(小米这次20分钟抢完,估计也是这样的)
分布部署,我们直接用于前端响应的server大概有20台,直接挂在F5上的,修改配置,让其中的n台程序就不访问数据库,直接返回“没抢到”。
现状:编辑可以自由的控制奖池中奖品的数量,设置“阀值”大小改变抢中的概率,分不同时段放票,来维持活动的热度。
本文由:李慎洲厂 [url=http://www.shenzhoustone.com]五莲花路沿石[/url]推荐
鄙人曾在某知名网站做技术。做了一个很复杂的抢票系统,至今在用。
需求是这样的,网站会跟商业公司合作做一些推广,送出一些演出门票,数码产品什么的让网友来抢。
第一次上线抢票,只放了一张门票,送个数码相机,再送飞机票。数据库里只放一条记录,第一个网友进来了就立即删除。其他网友全部提示“没抢到”,但也让网友留信息。第一次成功了。 客户很满意,尤其看到了很多热心网友留的信息。
第二次放20张门票,还沿用第一次的系统设计,放20条记录,在网友抢走了几张票后,后台数据混乱了,票超发了(放出去了不到30张),客户也认了。(这种故障12年的淘宝双十一也出现过) 。
后来分析,不能在一开始就让所有请求都操作数据库,直接连库MySQL扛不住,主从就超发,加缓存超发估计会更严重。
解决办法:
1.让用户分流,让部分用户直接返回“没抢到”,不请求数据库 。
2.如果还不行就,错开峰值 ,高峰期全部用户都不请求数据库,全部返回“没抢到”。
分流我们的办法比小米高明,网友猜测不到,每一个请求分配一个随机数,跟编辑设置的“阀值”比较,比阀值大就请求数据库,再判断奖品还有没有。小米傻到直接在页面上上空链接。大傻。
错开峰值,就是抢票刚开始时,其实库里奖品数量是0,全部返回“没抢到”,过了高峰期再放出来抢。(小米这次20分钟抢完,估计也是这样的)
分布部署,我们直接用于前端响应的server大概有20台,直接挂在F5上的,修改配置,让其中的n台程序就不访问数据库,直接返回“没抢到”。
现状:编辑可以自由的控制奖池中奖品的数量,设置“阀值”大小改变抢中的概率,分不同时段放票,来维持活动的热度。
本文由:李慎洲厂 [url=http://www.shenzhoustone.com]五莲花路沿石[/url]推荐