logo

笔者的电商秒杀真实经验

笔者在工作中曾经成功地用 Nginx 改造了一个高并发的电商秒杀系统,保证了业务的正常开展,下面是笔者的真实故事。

新冠时期的机遇

在新冠疫情初期,住范儿的私域电商业务迅速发展。尽管 3 月中旬才复工,3 月份半个月的 GMV 就超过了前一年的总和,并在 4 月就完成了全年目标。然而,这也导致电商系统的性能压力急剧增加。

当时,我们的电商系统和第一版淘宝一样是购买的一个 PHP 单体系统,天生不具备扩展性。再加上我们采用团购秒杀的业务模式,这给系统带来了巨大的挑战。客户端主要使用微信小程序,而服务端则提供两种主要服务:开团瞬间的海量 HTTP API 请求以及每个页面都非常消耗资源的订单管理后台。

笔者面临的第一个问题是数据库无法承受如此巨大的压力。经过分析,笔者发现请求数最高的接口是商品详情,于是为该接口增加了一层保持时长为一分钟的 Redis 缓存,这个动作显著降低了开团瞬间的数据库压力。

而且幸运的是,当时阿里云刚刚商用 PolarDB 几个月。笔者利用 PolarDB 成功应对了开团三分钟内涌入的大约 4000 名用户带来的巨大的数据库压力。然而,当笔者将后端云主机升级到 16 核 32G 内存时,出现了一个非常奇怪的现象:

  1. CPU 和内存占用率分别仅为 8% 和 6%。
  2. 大量新用户无法建立 TCP 连接,客户端表现为长时间的等待。
  3. 如果运气好,在等待一段时间后成功进入系统,那么访问将会非常丝滑,每个接口的响应时间都非常短。

为什么会出现这种现象呢?原因是新用户无法与服务器建立 TCP 连接!

默认情况下,CentOS 7.9 单个进程的最大文件打开数(ulimit)为 1024。由于一切皆文件,每个 TCP 连接也是一个文件,因此也被锁定在了 1024 个。通常情况下,我们会将这个数字设置为 65535。然而,笔者观察到这台虚拟机最大 TCP 连接数只能达到 5-6K 之间,远远无法满足用户需求。无论是采用 prefork、worker 还是 event 模式都是如此。而原因正是我们之前实测过的:此时 Apache 已经忙不过来,花费了一颗 CPU 核心的全部时间片来进行数据包和线程的匹配。

怎么解决的?

为了解决这个问题,笔者在同一台机器上安装了 Nginx 作为反向代理服务器,将所有用户请求转发给 Apache 处理。这个操作立即缓解了请求压力,而且 Nginx 使用的最大活跃 TCP 连接数量也只有 1K,完全满足了三分钟 4000 用户的需求。此时,系统架构和第一章的图 1-1 一样。

阅读数:3671      字数:893 最后更新:2023-10-25 16:31:38