一个秒杀系统的设计

系统功能

• 鉴权登录
• 展示简单用户基本信息
• 秒杀
• 记录用户停留点击轨迹

业务数据

• 用户量：1000万+
• 估计参与秒杀总用户量：100万以内
• 估计每次秒杀参与用户量：10万以内
• 秒杀对象：红包、免费电子券

系统特点

• 功能非常简单（可看作完全没什么业务）
• 重点支撑高并发，应用不能崩垮
• 秒杀的数据完整性必须保证，放第一位
• 登录放第二位、用户触点放最后。用户信息查询不涉及增删改

设计要点

• 作为独立系统，不影响其他系统
• 登录需支持微信公众号（或微信小程序）、APP、手机浏览器
• 不考虑PC端

设计

技术选择设计

• 采用内存数据库redis（集群），实现登录、用户信息、秒杀
• 采用消息队列kafka（集群），记录用户触点
• 采用nginx（集群），负载用户访问
• 采用前后端分离开发，前端Vue2.5，后端springboot
• 应用使用docker和tomcat部署

redis设计

• 用户量大，key采用短缩写命名，节省内存
• 用户信息用google的protobuf序列化，节省内存，提供读取效率
• 随机短信验证码采用list存储，pop读取后不继续保留占用内存
• 部署40台redis集群，每台给redis分配32G内存左右
• 主从备份，也有600G内存可用，每个用户基本信息和业务信息如果为10K，总共也就100G，应完全足够

kafka设计

• 4台kafka集群，每台好像100个分区（具体忘了，时间太久了）
• 写一个后台应用程序，读取kafka到mysql或oracle，进行用户触点分析与管理

nginx设计

• 域名买阿里云的，https证书也买阿里云的，在上面配置好指向F5
• F5配置指向4台nginx负载，ssl证书在nginx上配置
• 同时预留4台nginx，配置同前面4台，但不启动（如果负载不够再启动）
• 按照每台nginx支撑3万的并发，4台应该足够，但是一般保守估计为1万，所以预留
• 优化linux配置，优化nginx配置，支撑高并发（详见我写的另一篇blog）

限流设计

• 限流，防止系统雪崩
• 通过nginx配置实现
• nginx支持简单的限流配置，共三种
  • 按ip限
  • 按主机限
  • 按流量限
• 三种全用上，每ip限10个连接，每主机1万连接，流量每秒1兆（千兆带宽）
• 熔断先不弄

应用开发设计

• 用户基础信息一次读取，放内存，不多次读取

应用部署设计

• 40台主机部署tomcat，每台用docker启动2个，共80个
• vue用webpack前端工程化，编译成少量的css和js文件，尽量少占用http连接

安全设计

• https
• 登录验证（不用落后的加密算法，如DES和3DES）
• 尽量用nginx和vue挡在前面，RESTful不让访问
• 特别秒杀的应用要保护好，代码采用多重判断验证

系统效果

• 最终用户量没预计的大
• 出现了一次短时间的503错误（估计当时访问量很大）
• 没有故障，没有投诉
• 但其实很多地方都做的不好，下次再做的话要改进

2019.3.3记录（共用时45分钟，中间喝了一杯牛奶）。