秒杀系统设计
可参考技术文档：
压力挑战：
短暂的高流量，对现有网站业务造成冲击
秒杀是一个网站营销的一个附加活动，时间短，并发量大。
如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。
高并发,数据库高负载
用户秒杀开始前，通过不断刷新浏览器来保证不会错过秒杀活动。
频繁的访问程序、数据库会对应用服务器和数据库服务器造成负载压力
网络及服务器带宽增长压力,网络带宽的问题比超过平时好多倍
如果秒杀页面的大小为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的读写，到返回抢购结果
相关推荐
yaodilu 2020-05-10
SXIAOYI 2020-09-16
有心就有方向 2012-09-03
zfyaixue 2013-06-14
pigsmall 2020-11-19
Ladyseven 2020-07-25
whileinsist 2020-06-24
gufudhn 2020-06-12
冰蝶 2020-06-05
LinuxAndroidAI 2020-06-04
supperme 2020-05-28
e度空间 2020-04-27
云端漂移 2020-04-09
peterwzc 2020-03-17
ebuild 2013-05-14
donghedonghe 2013-05-31
tdeclipse 2011-02-28
linuxprobe0 2013-04-15