秒杀系统设计

可参考技术文档：

https://blog.csdn.net/he90227/article/details/77931706

压力挑战：

    短暂的高流量，对现有网站业务造成冲击

         秒杀是一个网站营销的一个附加活动，时间短，并发量大。

         如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。

    高并发,数据库高负载

         用户秒杀开始前，通过不断刷新浏览器来保证不会错过秒杀活动。

         频繁的访问程序、数据库会对应用服务器和数据库服务器造成负载压力

    网络及服务器带宽增长压力,网络带宽的问题比超过平时好多倍

         如果秒杀页面的大小为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的读写，到返回抢购结果

相关推荐