联系
Knight's Blog » 架构

【Knight技术分享】秒杀架构考虑

2020-04-06 17:36

前沿

来vmate的第一件事情就是做秒杀,秒杀对于高并发的处理非常突出,是比较能体现技术能力的一个业务场景。

问题

用户秒杀(定时领)或者随时领的行为可能由于 太热门,导致请求量过大,担心 引起系统的各种问题

目标

通过技术手段,解决

  • 当前:高并发秒杀问题
  • 未来:构建良好架构,可以适应高并发;通用性,为其它场景做准备

秒杀特点

  • 瞬时并发量大。 大量用户会在同一时间点进行抢购; ○ 网站瞬时访问量激增
  • 库存少
    • 访问请求量远远大于库存数量
    • 只有少数部分用户能够秒杀成功
  • 业务流程比较简单

技术难点

  • 对现在业务的影响
    • 可能造成其它功能模块的当机。秒杀是营销活动的一种,如果和其它营销活动应用部署在同一服务器上,肯定会对现有其它活动造成冲击,极端情况下可能导致整个电商系统服务宕机。
  • 功能难点
    • 流量过大,不够使用,无法访问服务。秒杀活动开始前后,会有很多用户请求对应商品页面,会造成后台服务器的流量突增,同时对应的网络带宽增加,需要控制商品页面的流量不会对后台服务器、DB、redis等组件造成过大的压力 。
    • 读操作过大。不停的刷页面
    • 写操作过大。疯狂点击按钮,如果订单涉及较重业务逻辑,则会响应很慢。

第一版本架构

第一版的逻辑是前端同学做的,这段的问题在于:

  • 业务逻辑不容易维护。由于是前端同学,因此逻辑放在nodejs层,只是把后台服务当成各种api进行调用。
  • 大库存大流量风险问题。没有异步化架构。虽然采用redis进行扛流量,但是一旦库存量和流量变大,则由于同时满足购物条件的人过多,导致后台处理不过来。
  • 一致性问题。秒杀过程涉及到订单、积分、商品等多表的操作。nodejs操作不方便有事务的控制。

改进策略

  • 公平性
    • 防刷机制。限制n秒内,用户访问次数。
    • 倒计时前后端同步
    • 僵尸帐户防刷,在业务侧做实例制。
  • 隔离
    • 业务隔离:秒杀系统,属于短时间内高并发处理,防止影响其它正常业务,应该需要独立 部署
    • 动静隔离:秒杀页面尽可能减少对后台依赖,绝大部分走CDN,只有少部署动态数据请求服务
  • 网络及带宽增长压力
    • 尽可能越在靠近用户侧拦截越多无效请求越好。
    • 减少冗余数据的返回
  • 保证秒杀接口快
    • 秒杀接口足够简化
    • 复杂逻辑异步处理
    • 尽可能越在靠近用户侧拦截越多无效请求越好。
    • 读走缓存
  • 数据一致性
    • 将大量无效请求拦截在数据层之前,有效请求(少量)通过redis/db等中间数据层保证数据一致性。
  • 可扩展性
    • 多级缓存,各个层级,尽可能多的做缓存,以拦截无效请求。 我们的解法