秒杀系统设计

呼呼ozZ 2019-01-01

可参考技术文档:
 
压力挑战:
    短暂的高流量,对现有网站业务造成冲击
         秒杀是一个网站营销的一个附加活动,时间短,并发量大。
         如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪。
 
    高并发,数据库高负载
         用户秒杀开始前,通过不断刷新浏览器来保证不会错过秒杀活动。
         频繁的访问程序、数据库会对应用服务器和数据库服务器造成负载压力
 
    网络及服务器带宽增长压力,网络带宽的问题比超过平时好多倍
         如果秒杀页面的大小为200K,如果最大并发数为10000次,那么需要的网络和服务器带宽是2G(200K×10000)。
         这些网络带宽是因为秒杀活动新增的,超过网站平时使用的带宽
 
    业务逻辑的简化
 
    避免直接下单
         秒杀的游戏规则是到了秒杀才能开始对商品下单购买,在此时间点之前,只能浏览信息不可下单。
         而下单页面也是一个普通的URL,如果得到这个URL,不用等到秒杀开始就可以下单了
 
 
解决策略:
    1.公平保证:
         秒杀用户筛选策略:一般是先到先得,10个商品放100个人进来
         防秒杀器和机器人:验证码等手段
    2.系统压力:
         秒杀系统独立部署,避免对主站造成压力和堵死
                如果需要还可以使用独立域名,使其与网站完全隔离,即使秒杀系统崩溃了,也不会对网站造成影响
 
         秒杀商品页面静态化和缓存化,减少后端请求
                将商品描述、参数、详情,全部写到一个静态页面,不用进行程序的逻辑处理,不需访问数据库,不用部署动态的服务器和数据库服务器
 
         租借秒杀活动网络带宽
                为了减轻服务器的压力,需要将秒杀商品页面缓存在CDN,同样CDN服务器也需要临时租借带宽
 
         动态生成随机下单页面的URL
                为了避免用户直接访问下单URL,需要将URL动态化,用随机数作为参数,只能秒杀开始的时候才生成
 
       关键点
           业务拆分,独立并发访问
           高并发控制,请求量拦截。
           读写分离(查询库存和下订单拆分独立)
           请求队列控制接受数,从而控制并发量
           订单和支付的一致性
 
    3.系统层级的划分:     前端 -> web层 -> 业务服务 -> DB持久层
 
            前端
                   A:扩容,加机器,这是最简单的方法,通过增加前端池的整体承载量来抗峰值。
                   B:静态化,将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素。通过CDN来抗峰值。
                   C:限流一般都会采用IP级别的限流,即针对某一个IP,限制单位时间内发起请求数量。
 
            web层
                  A:   集群负载均衡,节点能线性扩展。
                  B:采用短连接,连接池。
 
            业务服务
                      A:查询模块(查询库存)并发查询,库存数存在缓存中,(商品信息和图片信息等等)静态化处理和库存剩余数量缓存化处理。
                      B: 下订单模块(秒杀关键部分),队列控制异步化处理,首先判断这个队列是否已满, 如果没满就将请求放入队列中排队,队列满以后的所有请求直接返回秒杀失败。
                      C: 支付模块,异步付款,等待付款成功结果。(付款成功更新库存,也可下单的时候扣库存)。
 
            DB持久层
 
            A: 各个系统的业务数据分库存储,主从读写分离,单个子系统的数据,可以通过分库/分表的方法。
            B: 构建合理数据库索引,如对购买记录添加唯一索引,数据更新检测库存,如update number set x=x-1 where (x -1 ) >= 0。
 
    4.监控系统
          A: 操作系统的cpu, memory,i/o 。
          B: 各个系统的log:访问次数,warning, error log的条数。
          C: dba对数据库的监控。
          D: 业务层面的监控:每分钟各个子系统的交易量(DB查询)。
          E: 核心路径监控,非常重要的部分,单笔请求在交易系统中的流程,一笔实时交易,从接收到http请求,到各个子系统之间的互相访问,到DB的读写,到返回抢购结果

相关推荐

ganyouxianjava / 0评论 2012-05-31