电商秒杀系统设计

　　【业务背景】
　　你作为一个电商创业公司的架构师，负责设计6。18大促秒杀系统的设计，你们的业务模式如下：
　　1。你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过20个商品，目前做了10个品类；
　　2。本次6。18秒杀选择了1000个充电宝，10台iPhone12作为秒杀商品；
　　3。正常的日活大约100万用户；
　　4。老板要求万无一失。
　　【技术背景】
　　1。技术团队以Java为主，已经落地了微服务架构；
　　2。主要渠道是自有的App（包括iOS和Android）和微信小程序，为了促进用户转化为App用户，只有下载App才能参加秒杀活动；
　　3。目前只有单机房。
　　业务基本场景
　　对前面的业务背景描述，进行核心业务场景假设，秒杀系统核心系统包括：秒杀商品详情系统，秒杀交易系统商品库存系统支付系统存储架构设计存储性能估算用户信息
　　日活100W的系统，假设日活用户占10，注册用户有100101000W商品信息
　　正常售卖商品数：10个品类，每个品类不超过20个商品，总商品数目为：1020200个商品，假设定期会对这些热销和好评的商品进行更新，更新评率为每周更新所有200个商品，为满足未来2年的增长，20052220000商品
　　由于秒杀系统仅618使用，因此无需隔离热点商品信息，如后续需要演进为每日秒杀的系统，则可以做单独的热点商品存储和正常商品隔离库存信息
　　假设每个上架的商品都是有库存的，库存记录数大致20000
　　秒杀库存，是否需要设计隔离的热点商品库存也看是否会演进每日秒杀的系统订单信息
　　假设该电商系统100W日活用户，实际每日下单的用户占50，每日产生50W订单，满足未来2年增长3652503。65亿订单数据支付信息
　　假设下单的用户都进行了支付，少量因为订单因为各种填写错误等原因未支付的订单，因此支付账单约3。65亿
　　存储架构设计
　　数据特点分析：商品信息相对固定，包含商品介绍，图片等静态资源信息，读多写少，适合通过读写分离的方式，提高读性能的支撑，库存数据，频繁读写，对应秒杀场景，单库无法支撑写请求时，可通过库存拆分的方式分担写压力订单数据，支付数据未来可能持续增长，且数据量较大（上亿记录），存在明显的冷热特性，因此考虑对数据进行分片，按月拆分，先做水平分表，后续再考虑分库
　　根据上面的分析，存储架构设计包括分为商品、库存数据库、订单库、支付账单库，可先采用MySQL主从架构商品详情页动静资源分离，静态资源通过引入CDN存储进行加速用户信息、一些动态缓存的内容，以及秒杀过程中排队，可以考虑引入Redis，采用多机的Cluster架构计算架构设计
　　计算性能估算查看商品详情：假设100W用户全部参与秒杀，查看商品的QPS为100W下单秒杀：比如增加答题等设计拦截下单请求，下单过程分散到13秒，下单TPS大致到30W支付：支付过程由于一般较长，假设一般要10秒完成，支付TPS为10W计算架构负载均衡设计
　　采用多级负载均衡架构第一级DNS采用专门的秒杀域名，和主站分离第二级采用LVS集群，第三级采用nginx集群计算架构缓存设计
　　采用多级缓存架构设计
　　1。CDN缓存静态商品信息，拦截大部分商品QPS
　　2。APP端缓存，秒杀预告预先放出了商品信息，可缓存部分资源到APP内部缓存
　　3。应用程序本地缓存，可存商品信息等
　　4。分布式缓存RedisCluster集群，存储用户信息，商品信息，秒杀限流任务队列