秒杀产品分析

背景:

在企业应用方面,靠部分产品的低价来吸引用户,达到引流的目的.在京东/小米有品商城的实际项目中的系统设计常常是在原有平台的基础上来建立分支的.若是在原有平台上直接对该业务进行实现,会面对以下的挑战:

1. 瞬时流量比较大,秒杀产品一般是以某个整点开始,那一时刻的流量会非常大,服务器所承受的并发压力很大.
2. 由于是在原有平台下直接实现,一时间大量的请求,系统处理不过来,处理能力不足以支撑这么大的并发请求.
3. 同时可能导致整个系统的宕机.

而在原有平台基础上建立分支有两个优点:

1. 独立设计(作为一个独立的服务)
2. 故障隔离,当该业务所属服务器宕机时不会影响到整个平台的稳定运行.

核心问题:

1.业务问题

• 抢购的流程

1. 商品列表
2. 点击抢购按钮
3. 进入商品详情
4. 选择商品规格
5. 添加到购物车或直接购买
6. 生成订单
7. 跳转到支付页面
8. 发消息给配送系统

• 商品超卖现象

1. 为什么会出现超卖?  因为线程的并发操作,导致同一时刻出现了销售量大于库存量的情况.
2. 假如出现超卖责任方归属? 属于平台方的错
3. 如何防止超卖?

• 扣减库存时机

1. 创建订单后扣减库存    合理.
2. 支付完成扣扣减库存    不合理,支付完成后再扣减库存一样会出现超卖的现象

2.技术问题

• 架构如何设计

1. 如何让系统支持高并发
2. 如何让系统支持高可用
3. 如何让系统支持高性能

• 技术栈如何选型

1. JAVA
2. GO

需求分析

1.角色及职责

• 用户端(使用系统的用户)
  • 花较少的钱买到更好的东西(性价比)
  • 系统界面要呈现更好的用户体验
    • 页面的布局
    • 系统的响应速度
    • 系统的稳定性好
• 产品端(设计产品的产品经理及专员)
  • 登记需求
  • 业务分析与建模
    • 业务边界
    • 业务流程设计
  • 系统分析与建模
    • 用户规模
    • 每天的访问量
  • 产品规划与设计
    • 产品原型
      • 画图
      • 静态页面
    • 需求确认
• 开发端(基于需求进行产品落地的程序员)
• 测试段(基于需求进行功能测试的人员)
• 运维端(将开发好的项目部署到服务器上或云端)

2.功能性需求

• 前端功能(用户端/客户端)
  • 浏览商品
    • 活动场次
      • 场次时间(0:00-8:00,8:00-12:00,12:00-16:00,16:00-20:00,20:00-0:00)
      • 场次状态(开始,秒杀中,结束)
  • 购买商品
  • 用户认证
    • 会员注册
    • 会员登录
• 后端功能(管理端)
  • 主题管理
    • 案例:双11,618,五一,春节,十一,日常活动.
    • 属性设计:
      
      id,标题,开始日期,结束日期,状态,备注,创建时间,创建用户
  • 场次管理
    • 案例:(0:00-8:00,8:00-12:00,12:00-16:00,16:00-20:00,20:00-0:00)
    • 属性设计:
      
      id,场次名称,所属主体,开始时间,结束时间,状态,创建时间,创建用户
  • 商品管理
    • 属性设计:
      
      id,商品id,主题id,场次id,标题,图片,原价,秒杀价,商家id,状态,库存数量,备注,创建时间,创建用户
  • 订单管理
    • 属性设计:
      
      id,商品id,订单金额,会员id,支付时间,状态,收货地址,联系电话,收货人,交易流水id,创建时间
  • 用户管理
    • 属性设计:
      
      id,用户名,密码,昵称,头像,等级id,手机号,邮箱,出生日期,城市,职业,签名,用户来源(手机端/电脑端),积分(登录积分/购买积分/分享积分),创建时间,修改时间,登陆次数,最后登录ip,最后登录时间

3.非功能性需求

• 高可用
  • 高可用指标
  1. 4个9 (99.99%)
  2. 5个9 (99.999%) 一年停机时间不会超过5分钟
  • 高可用手段
    • 服务冗余
    1. 服务冗余:一个服务器部署多份
    2. 目的:高并发,高可用
    • 服务拆分
    1. 一个大而全的系统按业务拆分成多个小系统(服务)，例如电商系统可以拆分为商品服务、订单服务、支付服务、库存服务.
    2. 目的:减少资源竞争(CPU,内存),更好的实现故障隔离提高敏捷性(开发效率,迭代效率)
    • 限流降级
    1. 限流
       
       限流指的是限制了单位时间内的请求次数.由于平台的处理能力不足因此限流,生活中常见的限流有(车辆限号,购房摇号,电影售票).在程序中,经常能遇见一种现象您访问的频次过高,限流的方案一般采用:令牌桶(类似于电影票),漏斗,计时器,时间窗口等.
    2. 熔断/降级
       
       熔断指的是在某个时间段停止服务,由于服务不稳定(经常会出现异常,响应速度非常慢)或是平台自身原因(处理能力不足),为保证核心业务的流畅运行.生活中常见的熔断/降级现象有(跳闸,美股熔断,电脑的过热保护).在程序中,则是服务暂时不可用,有些服务消失了看不见了.
    • 超时重试
      • 概念:系统没有设置超时或设置不当，都会造成系统故障。不设置超时，可能会导致请求累积导致连锁反应，甚至造成应用雪崩。重试设置不当会导致多倍请求流量，形成模拟DDOS攻击。因此设置合理超时时间和重试机制，并和熔断、快速失败等机制配合。
      • 场景:连接数据库/服务调用超时
      • 超时解决方案:1)一定时间后的再次重试(需要设置超时时间,重试次数等).2)服务熔断
    • 压力测试
      • 概念:压测用来评估系统稳定性和性能，通过压测决定是否扩容或缩容。压测要有压测方案，如压测接口、并发量、压测策略（突发、逐步加压、并发量）、压测指标（机器负载、QPS/TPS、响应时间）。之后产出压测报告，内容包括压测方案、机器负载、 QPS/TPS、响应时间(平均、最大、最小)、成功率、JVM参数（内存占用、GC次数）等。
      • 时间:系统上线之前
      • 内容:QPS 和并发线程数
    • 应急预案
      • 概念:通过压测发现一些系统瓶颈，要有相应的措施来应对。梳理系统全链路关键路径，包括网络接入层、应用接入层、WEB应用层、服务层、数据层等，并按照这些路径上的具体问题制定应急预案。
      • 具体方案:
      1. 主/备服务器
      2. 集群
      3. 限流熔断
      4. 缓存(本地缓存和分布式缓存)

领域建模

• 概念:DDD（Domain Drive Design，领域驱动设计）是一种软件设计方法，是指在软件设计的过程中始终围绕领域来构建模型、构建领域模型的过程就叫“领域建模”。这里的领域，我们可以理解成业务对象。例如。一个订单中心的业务逻辑总是围绕订单数据来实现的，比如下单、取消订单、订单退款、订单履约等业务逻辑。而订单数据在面向对象编程中的实体是订单对象，也就是订单中心的业务对象。
  这里的领域模型就是业务对象模型，是描述业务功能实现的对象模型，它是对业务对象协作关系和业务执行逻辑的一种抽象提炼。

1.战略建模

• 领域模型通常分成四层:
  • 用户界面层(Interfaces),比如前端或者客户端;
    • 面向用户的界面
    • 面向管理员的界面
  • 应用层负责(Application)给用户界面层提供业务应用的业务逻辑，如商城接口服务；
    • 用户接口(此处的接口不仅仅指狭义的java中的接口，而是包括这个界面的所有内容)
    • 商品接口
    • 订单接口
  • 领域模型层(Domain)负责某个核心领域的具体业务逻辑，如电商的订单中心；
    • 用户中心
    • 商品中心
    • 订单中心
  • 基础设施层(Infrastructure)如 MQ、MySQL、Redis 等。
    • MySQL
    • MQ
    • Redis
• 划分核心域和非核心域：划分是相对的而不是绝对的
  • 核心域 ：核心业务逻辑，指的是所设计的系统的核心功能部分
    • 主题管理
    • 场次管理
  • 非核心域：除了核心域之外的，则被划分为非核心域
    • 商品管理
    • 库存管理
    • 用户管理
• 确定各领域业务边界以及上下文
  • 核心域的上下文
    • 主题
    • 场次
  • 支撑子域：是与当前业务有关联的非核心域且在业务中起到了具体的支撑作用的。
    • 商品上下文
      • 基本属性
      • 销售属性
    • 库存上下文
      • 实际库存
      • 实际销量
  • 通用域上下文：指与当前核心业务的关联不大的但在业务中不得不要的非核心域
    • 用户账号信息

2.战术建模

从细节上来构建领域模型是对战略建模中限界上下文的具体实现。秒杀系统的战术建模就是分析活动领域中各个对象的类型，针对类型特点做抽象设计。

• 实体：能通过像id或名称唯一确定的出来的对象
  • 主题
  • 场次
  • 商品
  • 账号
  • 订单
• 值对象：不能被唯一确定或标识出来的对象，是一个具体的值
  • 实际库存
  • 销售库存
  • 原价
  • 活动价
• 聚合根：将其他对象聚合过来的对象
  • 场次
  • 活动商品
• 领域事件：领域对象所触发的某个事件
  • 活动未开始
  • 活动进行中
  • 库存已售罄
  • 活动已结束

架构设计

架构设计的原则：

• 尽量将请求拦截在上游
  • 就近从CDN服务器中取
• 尽量减少网络中数据的传递
  • 减少请求次数
  • 减少数据量
• 充分利用缓存技术
  • 本地缓存
  • 分布式缓存
• 热点隔离(便于维护，便于故障隔离)
  • 业务隔离：将秒杀系统独立作为一个系统
  • 系统隔离：通过独立部署来实现
  • 数据库：不同数据库以及不同的表来实现

架构设计的方法(五视图)：

• 逻辑视图：主要关注功能需求，以及系统职责和行为的划分
  • 着重考虑功能需求
  • 系统应该向用户提供的服务
• 开发视图：主要关注系统开发过程中的质量属性
  • 开发质量：
    • 可扩展
    • 可重用
    • 可移植
    • 易读性
    • 易测试
  • 组织方式：
    • 源代码：JAVA或GO
    • 配置文件
    • 第三方类库
• 运行视图：主要关注软件运行过程中的质量属性
  • 非功能属性：
    • 高可用
    • 高性能
    • 高安全
    • 高扩展
  • 各单元交互问题
    • 协议
    • 线程并发及通讯
• 数据视图：主要关注数据需求，它包括数据的格式、属性、关系等。
  • 数据需求
  • 数据关系：如E-R图
• 物理视图：对应物理架构，主要关注安装和部署需求
  • 软件的安装和部署