秒杀系统设计思路笔记
设计原因：
为什么要针对秒杀设计一个完善的方案？因为系统可能会因为1%的秒杀业务影响其余99%正常业务的运行，所以需要将秒杀系统独立出来。
待解决问题：
主要解决两个问题：并发读、并发写。
整体架构要求：
概括为："稳、准、快"，即对应"高可用、一致性、高性能"，其介绍分别如下：
高可用：保证系统的高可用和正确性，设计PlanB进行兜底。
一致性：保证秒杀减库存中的数据一致性。
高性能：涉及大量并发读写，所以需要支持高并发，从动静分离、热点发现与隔离、请求削峰与分层过滤、服务端极致优化来介绍。
五个架构原则（4要1不要）：
数据尽量少：包含请求和响应的数据，因为网络传输需要时间。可简化秒杀页面、减少数据库打交道。
请求数尽量少：浏览器渲染页面包含额外请求，比如以来了css、js、图片等定义为额外请求，这些请求尽可能少，若请求域名不一致，还涉及DNS解析，耗时更久，可采用合并方法如：http://xxx.com/tm/modes??module-preview/index.xtpl.js,module-jhs/index.xtpl.js ，这个在服务器依旧是单独存放，只是提供了一个组件解析这个url。比如以下是淘宝的一个静态资源链接：
路径尽量短：这里的路径表示节点。每个节点都会产生新的socket连接，一个节点的可用性是99.9%，经过五个节点后就是五次方为99.5%。方法可以是服务内部RPC调用变为jvm内部调用。
依赖尽量少：将服务分级，比如将支付服务作为0级，优惠券是1级，要避免0级系统被1级系统拖垮。
不要有单点：单点意味着没有备份。将服务无状态化，即避免服务与机器绑定。可设置配置中心映射。
注：数据、请求数、路径、依赖、单点。但是其实这些原则会产生冲突，如请求数量少中的合并请求会使单次请求的数据量变大，这与数据尽量少违背。所以需要我们做一个平衡。
秒杀系统的大体涉及结构：
1 页面彻底动静分离，使得用户秒杀时不需要刷新整个页面，降低刷新请求数。
2 服务器缓存秒杀商品，直接调用缓存层，无需穿透到数据库层找数据。
3 增加流量限流保护，防止最g坏情况。
如何动静分离：
把用户请求数据(如HTML)分为"动态数据"和"静态数据"。
动态数据与静态数据区别：确定输出的数据是否含访问者个性化数据如 个人信息、cookie等私密数据。
区别动静数据的作用：区分了动静数据，就可以将静态数据缓存，提高效率。
如何对静态数据做缓存：
1. 将静态数据放在离用户最近的地方，如CDN、用户浏览器、服务端的Cache。
2. 做静态化改造，直接缓存HTTP连接。Web服务器根据请求URL直接取出HTTP响应头、响应体直接返回。
3. 选择谁来缓存静态数据，如可在web服务器层做缓存，屏蔽java层的弱点，不在java层做缓存。
如何做动静分离改造：
1. URL唯一化。如每个商品链接为：http://item.xxx/xxxx?id=xxx 来作为缓存的key，用于缓存整个HTTP连接。
2. 分离请求，含用户信息相关、时间、地狱相关，这些都可以通过异步请求独立获取。
3. 服务器返回的信息可去掉cookie。如Vanish可用unset req.http.cookie去掉cookie。
动态内容处理方案：
ESI：web代理服务器做动态请求时，将动态内容插入静态页面，然后全部返回。
CSI：异步js请求，性能最佳，但是有一定时延，可能对用户体验不好。
动静分离的几种架构方案：
1. 实体机单机部署：将虚拟机运行的Java应用换成实体机
优点：无网络瓶颈、可使用大内存。
提升命中率，减少Gzip压缩。
减少cache失效压力，因为采用定时失效，如3分钟失效。
2 统一Cache层：即抽离cache出来作为一个独立的集群。可设置二级Cache，放置回原(原服务器)
3. 上CDN：可增加二级Cache防止回原(原服务器)。
二八原则(针对性处理热点数据)：
为什么要针对性处理：热点数据会大量占用服务资源，0.1%业务会抢占系统90%以上的资源。
什么是热点：
热点分为热点操作和热点数据，其中热点操作是一种优化的方式，将会在秒杀的操作优化讲解。
热点数据分为动态、静态热点数据如下：
-静态热点数据即可提前预测数据如数据分析出哪种更热门、一个商品做活动等。
-动态热点数据不可预测，如抖音广告然后突然火了。
如何发现热点数据：
发现静态热点数据：强制让卖家通过报名方式提前把热点数据筛选出来缓存，但是增加了卖家的工作量，也不够实时。也可以根据每日访问数进行统计，然后缓存TOP N的商品。
发现动态热点数据：抽离出一个中间件用于收集搜索、商品详情、购物车等关键热点业务的点击数据，然后异步记录到日志，然后根据规则判断是否热点数据后缓存在队列中(因为热点数据一般是临时的，所以可采用LRU算法淘汰)。
流量削峰怎么做：
为什么要削峰：稳定服务端，节省资源，本质是延缓用户请求发出，减少和过滤无用请求(遵循请求书尽量少原则)。
削峰思路：排队、答题、分层过滤
排队：消息队列缓存大量并发，把原来的一步操作变成两步。虽然违背了增加访问路径原则，但是防止了系统崩溃。
答题：可防止爬虫等的自动抢购的脚本。延缓请求从之前的1s内延缓到2-10s，对事件进行了分片，减缓服务器压力，如微信的摇一摇、支付宝休一休。也可限制答题时间间隔。
分层过滤：分层为：CDN->前台读系统(商品详情系统)->后台写系统(交易系统)->DB
大部分数据和流量都在CDN获取，拦截了大部分读的数据。
经过第二层(前台读系统)尽量走Cache。
到第三层(后台写系统)，做数据校验、限流，进一步减少数据量和请求。
最后在数据层完成强一致性校验。
分层过滤核心思想：各层过滤无效请求，所以必须对数据做分层校验，其校验原则如下：
将动态请求的读数据缓存在浏览器本地，过滤无效数据读。
对读数据不做强一致性校验，较少一致性校验带来的性能问题。
对写数据基于时间的合理分片，过滤过期失效请求。
对写数据做强一致性校验，只保留有效数据。
影响性能的因素及其可优化处：
影响服务端性能的因素：QPS、响应时间(RT)
计算公式：QPS = (1000ms / 响应时间) * 线程数量，真正影响性能的是CPU执行时间。
再来分析下线程数是否对QPS的影响：不是线程数越多，QPS越高，因为线程上下文切换有消耗。所以需要合理的设置线程数，一般的计算公式为：线程数 = [(线程等待时间 + 线程CPU时间) / 线程CPU时间] * CPU数量，当然最好的方式是性能测试来确认。
如何发现瓶颈：就缓存系统而言，制约的是内存。存储系统的瓶颈是I/O。
秒杀系统的大部分瓶颈在CPU(使用JProfiler、YourKit)，但不一定是CPU，有可能是其他部分，比如QPS达到极限时，CPU使用率是否超过95%,如果不是则可能是锁限制或过多本地I/O等待发生。
如何优化系统：
减少编码：java编码速度慢，涉及字符串操作(输入输出操作、I/O操作)比较消耗CPU资源。原因是磁盘、网络IO都需要将字符串转为字节，这个转换必须查表编码。可通过(OutputStream()直接进行流输出)，可提高30%.
减少序列化：序列化与编码同时发生，所以需要减少。尽量减少RPC，将关联性强的应用服务合并。
Java极致优化：对大流量Web系统做静态化改造；直接使用Servlet，绕过框架多余处理逻辑；直接输出流数据。
并发读优化：秒杀系统单机缓存。不要求读一致性，但是写数据的时候要求强一致性。
秒杀系统设计的核心逻辑：
秒杀系统最重要要求是 "不要超卖"，关键在于减库存。
减库存方式(三种)：
下单减库存：一定不会出现超卖情况，但是有些人下单完不付款会影响其他人。
付款减库款：付款减库存，可能会因为并发高导致付款时已经卖光，付不了款。
预扣库存：最常用，如下单后扣库存，保留十分钟，在十分钟内未付款就不保留。如果付款时发现库存不足则不允许付款。
减库存存在的问题：在下单减库存、预扣库存的情况下，有竞争对手恶意多账号下单导致库存降为0，那商品就无法正常卖。
解决办法：指定反作弊措施，如给经常下单不买的用户打标识、设置最大购买书、设置重复下单不付款操作数。
秒杀减库存极致优化：
秒杀商品减库存放缓存如redis。给热点商品提供独立的缓存层、DB层集群。使用排队如应用层排队、数据库层排队(阿里针对mysql的innodb做了补丁程序patch可对单行记录做并发排队)解决数据库并发锁问题。
设计Plan B兜底方案：
再牛逼的系统也会问题，比如超大流量导致宕机，出现最坏情况，所以需要设计Plan对应高可用性。
各阶段处理操作：
架构阶段：考虑拓展性和容错性，避免系统出现单点问题。
编码阶段：保证代码健壮性，合理设置超时退出机制，对于异常捕获后需要一个默认处理。
测试阶段：保证最坏情况下，也有相应处理流程。
发布阶段：需要有备份用于回滚。
运行阶段：系统监控和报警，如cat监控系统。
故障发生：及时止损，如下架标错价商品。
运行阶段详细处理：
降级：限制或关闭某些非核心功能，留给核心功能。如展示成功记录由30条变成5条。
限流：设置一个QPS阈值，达到则排队或丢弃。
拒绝：当连接数过大，cpu负载达到90%，就拒绝请求。
读自：许令波-《如何设计一个秒杀系统》
秒杀系统设计思路笔记相关推荐
- 秒杀系统设计思路与实战（含源码实现）
一.限流与降级 客户端限流 按钮置灰 js控制每秒只能发送一个请求 站点层限流 1. Nginx限流 Nginx官方版本限制IP的连接和并发分别有两个模块: limit_req_zone: 用来限制单 ...
- 转载和积累系列 - 秒杀系统设计思路
目录 前言 一:秒杀应该考虑哪些问题 1.1:超卖问题 1.2:高并发 1.3:接口防刷 1.4:秒杀url 1.5:数据库设计 1.6:大量请求问题 二:秒杀系统的设计和技术方案 2.1:秒杀系统数 ...
- 电商秒杀系统设计思路和实现方法
1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一 ...
- java信用分秒杀系统设计思路,秒杀系统设计思路
秒杀特性: 1. 商品个数有限 2. 时间分布集中 3. 流量超级大 整体方案: 1. 产品策略 a. 分离核心流程与其他可以延后处理的流程 b. 针对异常情况进行文案引导 2. 技术策略 a. 客户 ...
- 淘宝秒杀系统设计的几个注意点
转载自 淘宝秒杀系统设计的几个注意点 还记得2013年的小米秒杀吗?三款小米手机各11万台开卖,走的都是大秒系统,3分钟后成为双十一第一家也是最快破亿的旗舰店.经过日志统计,前端系统双11峰值有效请 ...
- 秒杀系统设计中的业务性思考
秒杀不是一个新鲜事物,特别是过去几年电商和互金业务的蓬勃发展,各种电商节的兴起,促使秒杀已经变成了非常重要的业务功能.我这几年也没少和"秒杀"打交道,和团队共同经历了各种挣扎后,积 ...
- 架构师之路(18)讲解秒杀系统设计
1 秒杀场景 秒杀场景 登陆12306进行火车票抢座 1599元购入飞天茅台 周董演唱会的门票 双十一秒杀活动 秒杀场景关注点 严格防止超卖:库存1000件卖了1020件,要杀个码农祭天了!防止超卖是 ...
- 你了解淘宝大秒杀系统设计详解吗？
1. 一些数据 2. 热点隔离 3. 动静分离 4. 基于时间分片削峰 5. 数据分层校验 6. 实时热点发现 7. 关键技术优化点 7.1 Java处理大并发动态请求优化 7.2 同一商品大并发读问 ...
- 淘宝大秒杀系统设计详解
摘要:最初的秒杀系统的原型是淘宝详情上的定时上架功能,由于有些卖家为了吸引眼球,把价格压得很低.但这给的详情系统带来了很大压力,为了将这种突发流量隔离,才设计了秒杀系统,文章主要介绍大秒系统以及这种典 ...
- Java程序员，你了解淘宝大秒杀系统设计详解吗？
1. 一些数据 大家还记得2013年的小米秒杀吗?三款小米手机各11万台开卖,走的都是大秒系统,3分钟后成为双十一第一家也是最快破亿的旗舰店.经过日志统计,前端系统双11峰值有效请求约60w以上的QP ...
最新文章
- Linux系统管理必备知识之查看系统用户和用户组
- bzoj1095: [ZJOI2007]Hide 捉迷藏 线段树维护括号序列 点分治 链分治
- 理解 angular2 基础概念和结构 ----angular2系列（二)
- .net core mysql CodeFirst
- npm包的上传npm包的步骤，与更新和下载步骤
- 京东自动评论脚本_京东时光机python脚本 自动完成任务
- centos6.5卸载java_删除CentOS6.5系统自带的jdk
- linux 导出 excel文件名乱码,excel导出，文件名称中文乱码问题 · 大腿的博客
- ui曲线谁是横坐标_【鼎阳硬件智库原创 | 测试测量】关于示波器的幅频特性曲线...
- SQL Server2008的数据导入到SQL Server2005
- 利用kd树实现最近邻搜索
- Taro小程序 Input组件focus属性失效解决方案
- Theory: If statement（理论：如果语句）
- “云边+端”三管齐下，“有蓉”数据库助力四川气象进入天擎时代
- DTOJ#5208. 蓝buff一吃就起飞
- 内网使用 IPV6 之Teredo篇
- 日了。这个竟然还不让发
- Kotlin-Android世界的一股清流-流程控制
- AnyProxy抓包实践
- 如何将PDF文件转换成PPT