|
一、概要： 每当电子商务平台搞活动，“秒杀”经常是提升网站活跃度的利器之一。比如活动日早上10点1元爱疯7秒杀7台，谁看到了估计都想去秒一把，万一秒中了呢。秒杀的典型特征就是在特定的短时间突然涌入大量请求，对系统造成洪峰冲击，如果系统设计得不好，很容易被直接打垮掉。 二、秒杀架构 按照“关注点分离”(SoC)的原则，秒杀业务跟普通的订单业务关注点显然是不一样的，秒杀强调的是高效率、高性能，普通订单强调的是业务流程的高一致性。所以我们首先应该将秒杀处理逻辑从普通的订单逻辑中分离出来，进行独立开发与部署。这样分离的好处就是非常灵活，可以在秒杀设计中采用完全不同的技术和架构，在秒杀活动结束后也方便下架部署。 既然按照分离的思路，我们就不需要再局限于传统的RMDBS和JavaEE了，因为二者本质上都是企业架构，单机每秒并发处理能力的量级也是在1000左右，如果加上复杂的业务逻辑的话，经常会下降到500以下了。我们将眼光放到Nginx和Redis上，二者的单机处理能力，最高都能达到每秒万级乃至10万级，轻松完爆RMDBS和JavaEE的处理能力。所以，我们希望在Nginx和Redis上做做文章，完全通过这两把利器来完成秒杀的用户行为部分。 如果我们只用Nginx和Redis来完成秒杀下单任务的话，加上秒杀本身具体的业务逻辑，那么即使达不到每秒10万并发，单机每秒达到1万应该也是可以达到的目标了。
针对秒杀方案的设计，我们最大化地简化业务流程，只需要用户在秒到之后提供一个手机号码即可成功完成秒杀。我们在Redis中来记录库存，通过减1操作来扣减库存。当库存减到0时，结束秒杀。秒杀成功后，在Redis中使用队列来记录用户的手机号码和相关秒杀信息，结束用户的秒杀动作，后续交由后端秒杀订单处理模块，按照其固定的处理效率，逐步消化处理之。编程语言直接使用Nginx（项目中实际使用的是OpenResty）中提供的LUA脚本来实现，我们用LUA来读写Redis，并且进行业务逻辑的操作。这样秒杀活动的实现，完全不需要经过WEB服务器、APP服务器和DB服务器，直接在高效率的Nginx和Redis中完成了。在实际的运用中，处理效率也基本达到了每秒万级的并发请求。
三、总结思考 看似使用双雄利器Nginx+Redis能实现单机每秒万级的秒杀了，你可能会有很多疑问，比如Redis还没有来得及写入持久化就宕机了怎么办？Redis中扣减库存，如果扣减成功但是后续却失败了，浪费库存了怎么办？还有用户手机号码填错了怎么办？这些问题，确实需要思考，但仔细想一下，其实不需要紧张。用阿里巴巴高级专家沈询的话说：世界上解决一个计算机问题最简单的方法，“恰好”不需要解决它！ 秒杀正热火的时候，偏偏Redis某个节点宕机了，那就算倒霉了，有什么大不了。Redis扣减库存浪费了1个，又不是超卖，有什么大不了。用户手机号码填错了，不管了吧。 虽然说恰好不需要解决它，但是在技术上，我们在Redis部署上，考虑使用集群，使用SSD可以加速Redis内存的持久化等。在业务上，浪费掉的秒杀库存，可以在下一次秒杀中加上。用户手机号码填错了，可以在业务上要求秒杀之前先校验手机号码或者先登录等等。 当然，不同的秒杀业务，差距也相当大，但是很多思想是一致的，比如简化业务流程，异步化订单处理，与常规业务进行分离部署，使用独立的更加适合秒杀场景的特定技术等等。 |
|
|
