双 11 技术专题 | 探秘电商秒杀抢购背后的 IT 架构

[liuyq]

双 11 技术专题 | 探秘电商秒杀抢购背后的 IT 架构

一年一度的双 11 购物节又要来了，剁手党们是否已经做好了准备？除了每年造就无数的败家买家外，双 11 也对各大各大电商平台的服务支撑提出了更高挑战。如何保证买家在购物过程中的流畅体验十分重要，再具性价比的商品在碰到网站无法响应时也会失去吸引力。因此，在各位买家开启买买买血拼模式的同时，各大电商平台也严阵以待，为一年中最繁忙的一天提供更强有力的 IT 技术保障。

我们注意到，虽然京东、淘宝、苏宁等大型电商已经凭借自身过硬的技术实力解决了高峰期间的 IT 压力，但是更多的中小型电商面对如此大的业务波动时还显得无能为力。在本次双 11 期间，我们将从技术角度出发，推出一系列专题文章，为大家解密电商平台的 IT 技术架构在面临秒杀抢购、消费者人物画像、商品推荐及搜索、业务高可用和多地访问、非结构化数据处理等业务场景的具体应对之策和技术实现。

今天的内容主要集中在秒杀及抢购背后的 IT 架构及实现。

电商秒杀活动的业务特点

1 、活动波峰波谷状态明显

电商通过秒杀活动为其经营产品造势，秒杀活动一般时间较为固定，活动通常需要经历产品发布、秒杀倒计时、到点秒杀、用户付款等一系列流程，在秒杀点前后服务器负载成峰值状态，服务器负载随着活动退却而减少。

2 、秒杀通常涉及不止一个业务

电商秒杀活动，用户在等待秒杀的过程中也为电商网站带来了流量，当秒杀活动进行过程中，用户身份认证、支付业务、积分业务也会同时发生。

3 、时间短、瞬时并发量高

秒杀活动是一个特别考验后台数据库、缓存服务的业务，对于数据库、缓存的性能要求特别严格。一旦后台数据服务没有跟上，秒杀活动将成为空谈。

秒杀背后的技术挑战

1 、突增的服务器及网络需求

双 11 这个万众狂欢的节日，对于电商员工来说，每个环节都面临前所未有的考验。

对 IT 运维部门来讲，需要备足充分的服务器和网络带宽资源来应付这一挑战。通常情况下，双 11 的服务器使用是平时的 3-5 倍，网络带宽是平时 2-4 倍，如何在短时间应付这些问题，如何让 IT 投资利用最大化，是摆在电商 IT 们面前一大难题。

2 、业务高并发，服务负载重

我们通常衡量一个 Web 系统的吞吐率的指标是 QPS （ Query Per Second ，每秒处理请求数），解决每秒数万次的高并发场景，这个指标非常关键。

假设处理一个业务请求平均响应时间为 100 ms ，同时，系统内有 20 台 Web 服务器，配置最大连接数为 500 个， Web 系统的理论峰值 QPS 为（理想化的计算方式）： 100000 （ 10 万 QPS ）意味着 1 秒钟可以处理完 10 万的请求，而“秒杀”的那 5w/s 的秒杀似乎是“纸老虎”。

实际情况，在高并发的实际场景下，服务器处于高负载的状态，网络带宽被挤满，在这个时候平均响应时间会被大大增加。随着用户数量的增加，数据库连接进程增加，需要处理的上下文切换也越多，服务器造成负载压力越来越重。

3 、业务耦合度高，引起系统“雪崩”

更可怕的问题是，当系统上某个应用因为延迟而变得不可用，用户的点击越频繁，恶性循环最终导致“雪崩”，因为其中一台服务器挂了，导致流量分散到其他正常工作的机器上，再导致正常的机器也挂，然后恶性循环，将整个系统拖垮。

电商秒杀活动应对策略

1 、弹性资源伸缩，快速响应

不像传统 IT 模式，企业 IT 部门需要预先先采购大量的服务器及网络带宽资源，用户在青云 QingCloud 上可即点即用服务器资源，随时满足电商用户的计算、网络、存储需求。通过灵活的公网 IP 策略，用户可以按照带宽和流量策略调整计费模式，随时扩缩资源情况。

除此之外，利用青云自动伸缩（ AutoScaling ）功能可以帮助用户基于资源的监控告警规则动态调节配置或集群规模，比如调整带宽上限，扩容关系型数据库的存储空间，增加或减少负载均衡器后端数量。

2 、系统模块有效切分

为了防止系统应用过于耦合，我们一般建议用户在系统架构上做到有效切分，以防业务之间因为资源的争抢带来的相互影响：

• 用户请求分发模块： 通过青云的负载均衡器集群（ Load Balancer Cluster ）可以将一个公网 IP 的流量，分散到多个负载均衡器节点做并发处理，突破单负载均衡器节点的能力瓶颈，提供可扩展的转发带宽和 HTTPS 卸载能力。

• 用户请求预处理模块： 在内网开通多台主机，主机上尽量使用无状态服务器，主机上可以预处理用户请求，通过后端 IO 监控，随时增减主机数量。

• 用户请求处理模块： 把通过预处理的请求封装成事务提交给数据库，并返回是否成功。

• 数据库接口模块： 该模块是数据库的唯一接口，负责与数据库交互，提供 RPC 接口供查询是否秒杀结束、剩余数量等信息。另外 QingCloud 提供关系型数据库服务， 包括主从节点、高可用服务、读写分离、自动备份、在线扩容以及监控告警等各种管理功能。

3 、充分利用缓存服务

缓存 (Cache) 可以提供高性能的缓存集群。一个集群包含多个缓存节点，支持主从、一主多从和多主多从架构，确保高可用。

另外， QingCloud 提供在线扩容，自动备份，监控告警和图形化操作等功能来管理集群；集群将运行于私有网络内，结合 QingCloud 提供的高性能硬盘，在保障高性能的同时兼顾您的数据安全。青云目前支持 Redis standalone 、 Redis cluster 和 Memcached 缓存。

电商秒杀活动架构部署

1 、电商活动常见架构：

2 、电商电商用户在青云上的架构展示： 3 、重构经验

• 尽量将请求拦截在系统上游 传统秒杀系统之所以宕机，是因为服务请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。所以用户在做系统重构时候，根据业务特点首先在前端对数据进行请求拦截，以减少数据层面压力。
• 数据层扩展 构建数据库 Slave 集群，从单节点 MySQL 数据库转变为一主多从的数据库集群；创建内网 LB ，对 Slave 集群做负载均衡，将数据库读请求分散到多个 Slave 节点上；根据功能做数据库读写分离。
• 读多写少的常用多使用缓存处理（推荐使用 Redis ） Redis 是一个 key-value 存储系统。和 Memcached 类似，它支持存储的 Value 类型相对更多，包括 String (字符串)、 List(链表)、 Set (集合)和 Zset (有序集合)。这些数据类型都支持 Push/Pop 、 Add/Remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上， Redis 支持各种不同方式的排序。

下面是 Redis 官方的 Bench-Mark 数据：

The test was done with 50 simultaneous clients performing 100000 requests.
The value SET and GET is a 256 bytes string.
 (127.0.0.1).Results: about 110000 SETs per second, about 81000 GETs per second.

PS ：更多详细数据请见官方 Bench-Mark  Page ： http://code.google.com/p/redis/wiki/Benchmarks

总结

随着互联网正在高速发展，使用电子商务服务的用户越多，高并发的场景也变得越来越多。电商秒杀活动是个比较典型的互联网高并发场景。我们一直坚信，优秀的业务架构需要不断结合实际生产需求进行设计，好的业务架构会一直进化。

青云 QingCloud 作为企业级云服务提供商，也会不断的为用户提供简洁高效的架构经验，以满足用户业务环境的复杂多变。

本篇文章为『双 11 电商平台技术架构揭秘』的第一期，后续我们还将从消费者人物画像、商品推荐及搜索、业务高可用和多地访问、非结构化数据处理等方面给大家带来一系列的技术文章，敬请期待！