秒杀系统架构优化思路

/ 默认分类 / 没有评论 / 344浏览
-----------------来自小马哥的故事

一、为什么难

秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据。 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万。 又例如12306抢票,亦与秒杀类似,瞬时流量更甚。

二、常见架构

流量到了亿级别,常见站点架构如上:

三、优化方向

四、优化细节

浏览器层请求拦截

点击了“查询”按钮之后,系统那个卡呀,进度条涨的慢呀,作为用户,会不自觉的再去点击“查询”,继续点,继续点,点点点。。。有用么?平白无故的增加了系统负载(一个用户点5次,80%的请求是这么多出来的),怎么整?

站点层请求拦截与页面缓存

浏览器层的请求拦截,只能拦住小白用户(不过这是99%的用户哟),高端的程序员根本不吃这一套,写个for循环,直接调用你后端的http请求,怎么整?

服务层请求拦截与数据缓存

站点层的请求拦截,只能拦住普通程序员,高级黑客,假设他控制了10w台肉鸡(并且假设买票不需要实名认证),这下uid的限制不行了吧?怎么整?

数据层闲庭信步

到了数据这一层,几乎就没有什么请求了,单机也能扛得住,还是那句话,库存是有限的,小米的产能有限,透过过多请求来数据库没有意义。

五、总结

没什么总结了,上文应该描述的非常清楚了,对于秒杀系统,再次重复下笔者的两个架构优化思路: