《小米网抢购系统开发实践》阅读笔记
一、背景
2014年4月9日凌晨,小米网的抢购系统做了最后的检查与演练。几个小时后,小米网今年开年来最重要的一次大型活动“米粉节”就要开始了。这次米粉节活动,是小米电商的成人礼,是一次重要的考试。小米网从网站前端、后台系统、仓储物流、售后等各个环节,都将接受一次全面的压力测试。
10点整,一波流量高峰即将到来,几百万用户将准点挤入小米网的服务器。
而首先迎接压力冲击的,就是挡在最前面的抢购系统。这个抢购系统是重新开发、刚刚上线不久的,这是它第一次接受这样严峻的考验。
系统能不能顶住压力?能不能顺畅正确地执行业务逻辑?这些问题不到抢购高峰那一刻,谁都不能百分百确定。
9点50分,流量已经爬升得很高了;10点整,抢购系统自动开启,购物车中已经顺利加入了抢购商品。
一两分钟后,热门的抢购商品已经售罄自动停止抢购。抢购系统抗住了压力。
二、第一版抢购系统基本原理
在PHP服务器上,通过一个文件来表示商品是否售罄。如果文件存在即表示已经售罄。
PHP程序接收用户抢购请求后,查看用户是否预约以及是否抢购过,然后检查售罄标志文件是否存在。对预约用户,如果未售罄并且用户未抢购成功过,即返回抢购成功的结果,并记录一条日志。
日志通过异步的方式传输到中心控制节点,完成记数等操作。
最后,抢购成功用户的列表异步导入商场系统,抢购成功的用户在接下来的几个小时内下单即可。
这样,流量高峰完全被抢购系统挡住,商城系统不需要面对高流量。
在这个分布式系统的设计中,对持久化数据的处理是影响性能的重要因素。
三、选用Redis服务器理由:
1、首先需要保存的数据是典型的Key/Value对形式,每个UID对应一个字符串数据。
传统数据库的复杂功能用不上,用KV库正合适。
2、Redis的数据是in-memory的,可以极大提高查询效率。
3、Redis具有足够用的主从复制机制,以及灵活设定的持久化操作配置。
四、第二版抢购系统基本原理
使用Go语言开发了部分模块,积累了一定的经验。
让Go程序常驻内存运行,各种配置以及状态信息都可以保存在内存中,减少I/O操作开销。对于商品数量信息,可以在进程内进行操作。
不同商品可以分别保存到不同的服务器的Go进程中,以此来分散压力,提升处理速度。
系统服务端主要分为两层架构:即HTTP服务层和业务处理层。
HTTP服务层用于维持用户的访问请求,业务处理层则用于进行具体的逻辑判断。两层之间的数据交互通过消息队列来实现。
HTTP服务层主要功能如下:
1、进行基本的URL正确性校验;
2、对恶意访问的用户进行过滤,拦截黄牛;
3、提供用户验证码;
4、将正常访问用户数据放入相应商品队列中;
5、等待业务处理层返回的处理结果。
业务处理层主要功能如下:
1、接收商品队列中的数据;
2、对用户请求进行处理;
3、将请求结果放入相应的返回队列中。
用户的抢购请求通过消息队列,依次进入业务处理层的Go进程里,然后顺序地处理请求,将抢购结果返回给前面的HTTP服务层。
商品剩余数量等信息,根据商品编号分别保存在业务层特定的服务器进程中。
我们选择保证商品数据的一致性,放弃了数据的分区容忍性。
原文链接: