什么是秒杀？通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动
比如说京东秒杀，就是一种定时定量秒杀，在规定的时间内，无论商品是否秒杀完毕，该场次的秒杀活动都会结束。这种秒杀，对时间不是特别严格，只要下手快点，秒中的概率还是比较大的。
淘宝以前就做过一元抢购，一般都是限量 1 件商品，同时价格低到「令人发齿」，这种秒杀一般都在开始时间 1 到3 秒内就已经抢光了，参与这个秒杀一般都是看运气的，不必太强求。
业务特点：
瞬时并发量大
秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。
库存量少
一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。
业务简单
流程比较简单，一般都是下订单、扣库存、支付订单。
技术难点：
现有业务的冲击
秒杀是营销活动中的一种，如果和其他营销活动应用部署在同一服务器上，肯定会对现有其他活动造成冲击，极端情况下可能导致整个电商系统服务宕机。
直接下订单
下单页面是一个正常的 URL 地址，需要控制在秒杀开始前，不能下订单，只能浏览对应活动商品的信息。简单来说，需要 Disable 订单按钮。
页面流量突增
秒杀活动开始前后，会有很多用户请求对应商品页面，会造成后台服务器的流量突增，同时对应的网络带宽增加，需要控制商品页面的流量不会对后台服务器、DB、Redis 等组件的造成过大的压力
架构设计思想：
限流
由于活动库存量一般都是很少，对应的只有少部分用户才能秒杀成功。所以我们需要限制大部分用户流量，只准少量用户流量进入后端服务器。
削峰
秒杀开始的那一瞬间，会有大量用户冲击进来，所以在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓，是能否成功设计好秒杀系统的关键因素。实现流量削峰填谷，一般的采用缓存和 MQ 中间件来解决。
异步
秒杀其实可以当做高并发系统来处理，在这个时候，可以考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的整体可用性。
缓存
秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。
由于数据库底层采用 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。如果我们把部分业务逻辑迁移到内存的缓存或者 Redis 中，会极大的提高并发效率。
一：秒杀应该考虑哪些问题
1.1：超卖问题
分析秒杀的业务场景,最重要的有一点就是超卖问题，假如备货只有100个，但是最终超卖了200，一般来讲秒杀系统的价格都比较低，如果超卖将严重影响公司的财产利益，因此首当其冲的就是解决商品的超卖问题。
1.2：高并发
秒杀具有时间短、并发量大的特点，秒杀持续时间只有几分钟，而一般公司都为了制造轰动效应，会以极低的价格来吸引用户，因此参与抢购的用户会非常的多。短时间内会有大量请求涌进来，后端如何防止并发过高造成缓存击穿或者失效，击垮数据库都是需要考虑的问题。
1.3：接口防刷
现在的秒杀大多都会出来针对秒杀对应的软件，这类软件会模拟不断向后台服务器发起请求，一秒几百次都是很常见的，如何防止这类软件的重复无效请求，防止不断发起的请求也是需要我们针对性考虑的
1.4：秒杀url
对于普通用户来讲，看到的只是一个比较简单的秒杀页面，在未达到规定时间，秒杀按钮是灰色的，一旦到达规定时间，灰色按钮变成可点击状态。这部分是针对小白用户的，如果是稍微有点电脑功底的用户，会通过F12看浏览器的network看到秒杀的url，通过特定软件去请求也可以实现秒杀。或者提前知道秒杀url的人，一请求就直接实现秒杀了。这个问题我们需要考虑解决
1.5：数据库设计
秒杀有把我们服务器击垮的风险，如果让它与我们的其他业务使用在同一个数据库中，耦合在一起，就很有可能牵连和影响其他的业务。如何防止这类问题发生，就算秒杀发生了宕机、服务器卡死问题，也应该让他尽量不影响线上正常进行的业务
1.6:大量请求问题
按照1.2的考虑，就算使用缓存还是不足以应对短时间的高并发的流量的冲击。如何承载这样巨大的访问量，同时提供稳定低时延的服务保证，是需要面对的一大挑战。我们来算一笔账，假如使用的是redis缓存，单台redis服务器可承受的QPS大概是4W左右，如果一个秒杀吸引的用户量足够多的话，单QPS可能达到几十万，单体redis还是不足以支撑如此巨大的请求量。缓存会被击穿，直接渗透到DB,从而击垮mysql.后台会将会大量报错
二：秒杀系统的设计和技术方案
2.1：秒杀系统数据库设计
针对1.5提出的秒杀数据库的问题，因此应该单独设计一个秒杀数据库，防止因为秒杀活动的高并发访问拖垮整个网站。
这里只需要两张表，一张是秒杀订单表，一张是秒杀货品表
其实应该还有几张表，商品表：可以关联goods_id查到具体的商品信息，商品图像、名称、平时价格、秒杀价格等，还有用户表：根据用户user_id可以查询到用户暱称、用户手机号，收货地址等其他额外信息，这个具体就不给出实例了。
2.2：秒杀url的设计
为了避免有程序访问经验的人通过下单页面url直接访问后台接口来秒杀货品，我们需要将秒杀的url实现动态化，即使是开发整个系统的人都无法在秒杀开始前知道秒杀的url。具体的做法就是通过md5加密一串随机字符作为秒杀的url，然后前端访问后台获取具体的url，后台校验通过之后才可以继续秒杀。
2.3：秒杀页面静态化
将商品的描述、参数、成交记录、图像、评价等全部写入到一个静态页面，用户请求不需要通过访问后端服务器，不需要经过数据库，直接在前台客户端生成，这样可以最大可能的减少服务器的压力。具体的方法可以使用freemarker模板技术，建立网页模板，填充数据，然后渲染网页
2.4:单体redis升级为集群redis
秒杀是一个读多写少的场景，使用redis做缓存再合适不过。不过考虑到缓存击穿问题，我们应该构建redis集群，采用哨兵模式，可以提升redis的性能和可用性。
2.5:使用nginx
nginx是一个高性能web服务器，它的并发能力可以达到几万，而tomcat只有几百。通过nginx映射客户端请求，再分发到后台tomcat服务器集群中可以大大提升并发能力。
2.6:精简sql
典型的一个场景是在进行扣减库存的时候，传统的做法是先查询库存，再去update。这样的话需要两个sql，而实际上一个sql我们就可以完成的。可以用这样的做法：update miaosha_goods set stock =stock-1 where goos_id ={#goods_id} and version = #{version} and sock>0;这样的话，就可以保证库存不会超卖并且一次更新库存,还有注意一点这里使用了版本号的乐观锁，相比较悲观锁，它的性能较好。
2.7：redis预减库存
很多请求进来，都需要后台查询库存,这是一个频繁读的场景。可以使用redis来预减库存，在秒杀开始前可以在redis设值，比如redis.set(goodsId,100),这里预放的库存为100可以设值为常量),每次下单成功之后,Integer stock = (Integer)redis.get(goosId); 然后判断sock的值，如果小于常量值就减去1;不过注意当取消的时候,需要增加库存，增加库存的时候也得注意不能大于之间设定的总库存数(查询库存和扣减库存需要原子操作，此时可以借助lua脚本)下次下单再获取库存的时候,直接从redis里面查就可以了。
2.8:接口限流
秒杀最终的本质是数据库的更新，但是有很多大量无效的请求，我们最终要做的就是如何把这些无效的请求过滤掉，防止渗透到数据库。限流的话，需要入手的方面很多：
2.8.1：前端限流
首先第一步就是通过前端限流，用户在秒杀按钮点击以后发起请求，那么在接下来的5秒是无法点击(通过设置按钮为disable)。这一小举措开发起来成本很小，但是很有效。
2.8.2：同一个用户xx秒内重复请求直接拒绝
具体多少秒需要根据实际业务和秒杀的人数而定，一般限定为10秒。具体的做法就是通过redis的键过期策略，首先对每个请求都从String value = redis.get(userId);如果获取到这个
value为空或者为null，表示它是有效的请求，然后放行这个请求。如果不为空表示它是重复性请求，直接丢掉这个请求。如果有效,采用redis.setexpire(userId,value,10).value可以是任意值，一般放业务属性比较好,这个是设置以userId为key，10秒的过期时间(10秒后,key对应的值自动为null)
2.8.3：令牌桶算法限流
接口限流的策略有很多，我们这里采用令牌桶算法。令牌桶算法的基本思路是每个请求尝试获取一个令牌，后端只处理持有令牌的请求，生产令牌的速度和效率我们都可以自己限定，guava提供了RateLimter的api供我们使用。以下做一个简单的例子,注意需要引入guava
public class TestRateLimiter {
public static void main(String[] args) {
//1秒产生1个令牌
final RateLimiter rateLimiter = RateLimiter.create(1);
for (int i = 0; i < 10; i++) {
//该方法会阻塞线程，直到令牌桶中能取到令牌为止才继续向下执行。
double waitTime= rateLimiter.acquire();
System.out.println("任务执行" + i + "等待时间" + waitTime);
}
System.out.println("执行结束");
}
}
上面代码的思路就是通过RateLimiter来限定我们的令牌桶每秒产生1个令牌(生产的效率比较低)，循环10次去执行任务。acquire会阻塞当前线程直到获取到令牌，也就是如果任务没有获取到令牌，会一直等待。那么请求就会卡在我们限定的时间内才可以继续往下走，这个方法返回的是线程具体等待的时间。执行如下;
可以看到任务执行的过程中，第1个是无需等待的，因为已经在开始的第1秒生产出了令牌。接下来的任务请求就必须等到令牌桶产生了令牌才可以继续往下执行。如果没有获取到就会阻塞(有一个停顿的过程)。不过这个方式不太好，因为用户如果在客户端请求，如果较多的话,直接后台在生产token就会卡顿(用户体验较差)，它是不会抛弃任务的，我们需要一个更优秀的策略:如果超过某个时间没有获取到，直接拒绝该任务。接下来再来个案例：
public class TestRateLimiter2 {
public static void main(String[] args) {
final RateLimiter rateLimiter = RateLimiter.create(1);
for (int i = 0; i < 10; i++) {
long timeOut = (long) 0.5;
boolean isValid = rateLimiter.tryAcquire(timeOut, TimeUnit.SECONDS);
System.out.println("任务" + i + "执行是否有效:" + isValid);
if (!isValid) {
continue;
}
System.out.println("任务" + i + "在执行");
}
System.out.println("结束");
}
}
其中用到了tryAcquire方法，这个方法的主要作用是设定一个超时的时间，如果在指定的时间内预估(注意是预估并不会真实的等待)，如果能拿到令牌就返回true，如果拿不到就返回false.然后我们让无效的直接跳过，这里设定每秒生产1个令牌，让每个任务尝试在
0.5秒获取令牌，如果获取不到,就直接跳过这个任务(放在秒杀环境里就是直接抛弃这个请求)；程序实际运行如下：
只有第1个获取到了令牌，顺利执行了，下面的基本都直接抛弃了，因为0.5秒内，令牌桶(1秒1个)来不及生产就肯定获取不到返回false了。
这个限流策略的效率有多高呢？假如我们的并发请求是400万瞬间的请求,将令牌产生的效率设为每秒20个，每次尝试获取令牌的时间是0.05秒，那么最终测试下来的结果是，每次只会放行4个左右的请求,大量的请求会被拒绝,这就是令牌桶算法的优秀之处。
2.9:异步下单
为了提升下单的效率，并且防止下单服务的失败。需要将下单这一操作进行异步处理。最常采用的办法是使用队列，队列最显著的三个优点：异步、削峰、解耦。这里可以采用rabbitmq，在后台经过了限流、库存校验之后，流入到这一步骤的就是有效请求。然后发送到队列里，队列接受消息，异步下单。下完单，入库没有问题可以用短信通知用户秒杀成功。假如失败的话,可以采用补偿机制，重试。
3.0：服务降级
假如在秒杀过程中出现了某个服务器宕机，或者服务不可用，应该做好后备工作。之前的博客里有介绍通过Hystrix进行服务熔断和降级，可以开发一个备用服务，假如服务器真的宕机了，直接给用户一个友好的提示返回，而不是直接卡死，服务器错误等生硬的反馈。
三、秒杀系统详细设计
3.1 创建秒杀活动
3.2 查看秒杀活动
3.3 参与秒杀活动
四、秒杀系统的背景与特点
秒杀特点：短时间内，大量用户涌入，集中读和写有限的库存。
解决方案：层层拦截，将请求尽量拦截在系统上游，避免将锁冲落到数据库上。
4.1客户端优化
产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求； JS层面，限制用户在x秒之内只能提交一次请求，比如微信摇一摇抢红包。 基本可以拦截80%的请求。
4.2 站点层面的请求拦截（nginx层，写流控模块）
怎么防止程序员写for循环调用，有去重依据么? IP? cookie-id? …想复杂了，这类业务都需要登录，用uid即可。在站点层面，对uid进行请求计数和去重，甚至不需要统一存储计数，直接站点层内存存储（这样计数会不准，但最简单，比如guava本地缓存）。一个uid，5秒只准透过1个请求，这样又能拦住99%的for循环请求。 对于5s内的无效请求，统一返回错误提示或错误页面。
这个方式拦住了写for循环发HTTP请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照uid限流拦不住了。
4.3 服务拦截层
方案一：写请求放到队列中，每次只透有限的写请求到数据层，如果成功了再放下一批，直到库存不够，队列里的写请求全部返回“已售完”。
方案二：或采用漏斗机制，只放一倍的流量进来，多余的返回“已售完”，把写压力转换成读压力。 读请求，用cache，redis单机可以抗10W QPS,用异步线程定时更新缓存里的库存值。
还有提示“模糊化”，比如火车余票查询，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票。
4.4 数据库层
浏览器拦截了80%，站点层拦截了99.9%并做了页面缓存，服务层又做了写请求队列与数据缓存，每次透到数据库层的请求都是可控的。 db基本就没什么压力了，通过自身锁机制来控制，避免出现超卖。
4.5 总结：
尽量将请求拦截在系统上游（越上游越好）；
读多写少的多使用缓存（缓存抗读压力）；
五、秒杀系统可能存在的问题
对于一个日常平稳的业务系统，如果直接开通秒杀功能的话，往往会出现很多问题
秒杀本质是要求一个瞬时高发下的承压系统，这也是其区别于其他业务的核心场景。对日常系统秒杀产生的问题逐一进行拆解分类，秒杀对应到架构设计，其实就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考
高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开。
一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。如何做到既不多又不少？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑。
高可用。 大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定、应用自身的瓶颈、物理资源的损坏等方方面面都会对系统的运行带来大大小小的的冲击。如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题，系统设计时应该从哪些方面着手？
六、秒杀系统设计策略
6.1 高性能设计
6.1.1 动静分离策略
大家可能会注意到，秒杀过程中你是不需要刷新整个页面的，只有时间在不停跳动。这是因为一般都会对大流量的秒杀系统做系统的静态化改造，即数据意义上的动静分离。动静分离三步走：
数据拆分
静态缓存
数据整合
6.1.1.1 数据拆分
动静分离的首要目的是将动态页面改造成适合缓存的静态页面。因此第一步就是分离出动态数据，主要从以下 2 个方面进行：
用户。用户身份信息包括登录状态以及登录画像等，相关要素可以单独拆分出来，通过动态请求进行获取；与之相关的广平推荐，如用户偏好、地域偏好等，同样可以通过异步方式进行加载。
时间。秒杀时间是由服务端统一管控的，可以通过动态请求进行获取。
这里你可以打开电商平台的一个秒杀页面，看看这个页面里都有哪些动静数据。
6.1.1.2 静态缓存
分离出动静态数据之后，第二步就是将静态数据进行合理的缓存，由此衍生出两个问题：
1、怎么缓存；
静态化改造的一个特点是直接缓存整个 HTTP 连接而不是仅仅缓存静态数据，如此一来，Web 代理服务器根据请求 URL，可以直接取出对应的响应体然后直接返回，响应过程无需重组 HTTP 协议，也无需解析 HTTP 请求头。而作为缓存键，URL唯一化是必不可少的，只是对于商品系统，URL 天然是可以基于商品 ID 来进行唯一标识的，比如淘宝的 https://item.taobao.com/item...
2、哪里缓存。
静态数据缓存到哪里呢？可以有三种方式：1、浏览器；2、CDN ；3、服务端。
浏览器当然是第一选择，但用户的浏览器是不可控的，主要体现在如果用户不主动刷新，系统很难主动地把消息推送给用户（注意，当讨论静态数据时，潜台词是 “相对不变”，言外之意是 “可能会变”），如此可能会导致用户端在很长一段时间内看到的信息都是错误的。对于秒杀系统，保证缓存可以在秒级时间内失效是不可或缺的。
服务端主要进行动态逻辑计算及加载，本身并不擅长处理大量连接，每个连接消耗内存较多，同时 Servlet 容器解析 HTTP 较慢，容易侵占逻辑计算资源；另外，静态数据下沉至此也会拉长请求路径。
因此通常将静态数据缓存在 CDN，其本身更擅长处理大并发的静态文件请求，既可以做到主动失效，又离用户尽可能近，同时规避 Java 语言层面的弱点。需要注意的是，上 CDN 有以下几个问题需要解决：
失效问题。任何一个缓存都应该是有时效的，尤其对于一个秒杀场景。所以，系统需要保证全国各地的 CDN 在秒级时间内失效掉缓存信息，这实际对 CDN 的失效系统要求是很高的
命中率问题。高命中是缓存系统最为核心的性能要求，不然缓存就失去了意义。如果将数据放到全国各地的 CDN ，势必会导致请求命中同一个缓存的可能性降低，那么命中率就成为一个问题
因此，将数据放到全国所有的 CDN 节点是不太现实的，失效问题、命中率问题都会面临比较大的挑战。更为可行的做法是选择若干 CDN 节点进行静态化改造，节点的选取通常需要满足以下几个条件：
临近访问量集中的地区
距离主站较远的地区
节点与主站间网络质量良好的地区
基于以上因素，选择 CDN 的二级缓存比较合适，因为二级缓存数量偏少，容量也更大，访问量相对集中，这样就可以较好解决缓存的失效问题以及命中率问题，是当前比较理想的一种 CDN 化方案。部署方式如下图所示：
6.1.1.3 数据整合
分离出动静态数据之后，前端如何组织数据页就是一个新的问题，主要在于动态数据的加载处理，通常有两种方案：ESI（Edge Side Includes）方案和 CSI（Client Side Include）方案。
ESI 方案：Web 代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已经是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好
CSI 方案：Web 代理服务器上只返回静态页面，前端单独发起一个异步 JS 请求动态数据。这种方式对服务端性能友好，但用户体验稍差
6.1.1.4 动静分离策略
动静分离对于性能的提升，抽象起来只有两点，一是数据要尽量少，以便减少没必要的请求，二是路径要尽量短，以便提高单次请求的效率。具体方法其实就是基于这个大方向进行的。
6.1.2 热点优化策略
热点分为热点操作和热点数据，以下分开进行讨论。零点刷新、零点下单、零点添加购物车等都属于热点操作。热点操作是用户的行为，不好改变，但可以做一些限制保护，比如用户频繁刷新页面时进行提示阻断。热点数据的处理三步走，一是热点识别，二是热点隔离，三是热点优化。
6.1.2.1 热点识别
热点数据分为静态热点和动态热点，具体如下：
静态热点：能够提前预测的热点数据。大促前夕，可以根据大促的行业特点、活动商家等纬度信息分析出热点商品，或者通过卖家报名的方式提前筛选；另外，还可以通过技术手段提前预测，例如对买家每天访问的商品进行大数据计算，然后统计出 TOP N 的商品，即可视为热点商品
动态热点：无法提前预测的热点数据。冷热数据往往是随实际业务场景发生交替变化的，尤其是如今直播卖货模式的兴起——带货商临时做一个广告，就有可能导致一件商品在短时间内被大量购买。由于此类商品日常访问较少，即使在缓存系统中一段时间后也会被逐出或过期掉，甚至在db中也是冷数据。瞬时流量的涌入，往往导致缓存被击穿，请求直接到达DB，引发DB压力过大。
因此秒杀系统需要实现热点数据的动态发现能力，一个常见的实现思路是：
异步采集交易链路各个环节的热点 Key 信息，如 Nginx采集访问URL或 Agent 采集热点日志（一些中间件本身已具备热点发现能力），提前识别潜在的热点数据
聚合分析热点数据，达到一定规则的热点数据，通过订阅分发推送到链路系统，各系统根据自身需求决定如何处理热点数据，或限流或缓存，从而实现热点保护。
需要注意的是：
热点数据采集最好采用异步方式，一方面不会影响业务的核心交易链路，一方面可以保证采集方式的通用性
热点发现最好做到秒级实时，这样动态发现才有意义，实际上也是对核心节点的数据采集和分析能力提出了较高的要求
6.1.2.2 热点隔离
热点数据识别出来之后，第一原则就是将热点数据隔离出来，不要让 1% 影响到另外的 99%，可以基于以下几个层次实现热点隔离：
业务隔离。秒杀作为一种营销活动，卖家需要单独报名，从技术上来说，系统可以提前对已知热点做缓存预热
系统隔离。系统隔离是运行时隔离，通过分组部署和另外 99% 进行分离，另外秒杀也可以申请单独的域名，入口层就让请求落到不同的集群中
数据隔离。秒杀数据作为热点数据，可以启用单独的缓存集群或者DB服务组，从而更好的实现横向或纵向能力扩展
当然，实现隔离还有很多种办法。比如，可以按照用户来区分，为不同的用户分配不同的 Cookie，入口层路由到不同的服务接口中；再比如，域名保持一致，但后端调用不同的服务接口；又或者在数据层给数据打标进行区分等等，这些措施的目的都是把已经识别的热点请求和普通请求区分开来。
6.1.2.3 热点优化
热点数据隔离之后，也就方便对这 1% 的请求做针对性的优化，方式无外乎两种：
缓存：热点缓存是最为有效的办法。如果热点数据做了动静分离，那么可以长期缓存静态数据
限流：流量限制更多是一种保护机制。需要注意的是，各服务要时刻关注请求是否触发限流并及时进行review
6.1.2.4 热点优化总结
数据的热点优化与动静分离是不一样的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性地处理。热点识别和隔离不仅对“秒杀”这个场景有意义，对其他的高性能分布式系统也非常有参考价值。
6.1.3 系统优化
对于一个软件系统，提高性能可以有很多种手段，如提升硬件水平、调优JVM 性能，这里主要关注代码层面的性能优化——
减少序列化：减少 Java 中的序列化操作可以很好的提升系统性能。序列化大部分是在 RPC 阶段发生，因此应该尽量减少 RPC 调用，一种可行的方案是将多个关联性较强的应用进行 “合并部署”，从而减少不同应用之间的 RPC 调用（微服务设计规范）
直接输出流数据：只要涉及字符串的I/O操作，无论是磁盘 I/O 还是网络 I/O，都比较耗费 CPU 资源，因为字符需要转换成字节，而这个转换又必须查表编码。所以对于常用数据，比如静态字符串，推荐提前编码成字节并缓存，具体到代码层面就是通过 OutputStream() 类函数从而减少数据的编码转换；另外，热点方法toString()不要直接调用ReflectionToString实现，推荐直接硬编码，并且只打印DO的基础要素和核心要素
裁剪日志异常堆栈：无论是外部系统异常还是应用本身异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会加剧系统当前负载。可以通过日志配置文件控制异常堆栈输出的深度
去组件框架：极致优化要求下，可以去掉一些组件框架，比如去掉传统的 MVC 框架，直接使用 Servlet 处理请求。这样可以绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，当然，需要合理评估你对框架的依赖程度
6.1.4 系统高性能设计总结
性能优化需要一个基准值，所以系统还需要做好应用基线，比如性能基线（何时性能突然下降）、成本基线（去年大促用了多少机器）、链路基线（核心流程发生了哪些变化），通过基线持续关注系统性能，促使系统在代码层面持续提升编码质量、业务层面及时下掉不合理调用、架构层面不断优化改进。
6.2 一致性设计
秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。
6.2.1 减库存的方式
电商场景下的购买过程一般分为两步：下单和付款。“提交订单”即为下单，“支付订单”即为付款。基于此设定，减库存一般有以下几个方式：
下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种
付款减库存。买家下单后，并不立即扣减库存，而是等到付款后才真正扣减库存。但因为付款时才减库存，如果并发比较高，可能出现买家下单后付不了款的情况，因为商品已经被其他人买走了
预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其他买家可以购买
6.2.2 减库存的问题
6.2.2.1 下单减库存
优势：用户体验最好。下单减库存是最简单的减库存方式，也是控制最精确的一种。下单时可以直接通过数据库事务机制控制商品库存，所以一定不会出现已下单却付不了款的情况。
劣势：可能卖不出去。正常情况下，买家下单后付款概率很高，所以不会有太大问题。但有一种场景例外，就是当卖家参加某个促销活动时，竞争对手通过恶意下单的方式将该商品全部下单，导致库存清零，那么这就不能正常售卖了——要知道，恶意下单的人是不会真正付款的，这正是 “下单减库存” 的不足之处。
6.2.2.2 付款减库存
优势：一定实际售卖。“下单减库存” 可能导致恶意下单，从而影响卖家的商品销售， “付款减库存” 由于需要付出真金白银，可以有效避免。
劣势：用户体验较差。用户下单后，不一定会实际付款，假设有 100 件商品，就可能出现 200 人下单成功的情况，因为下单时不会减库存，所以也就可能出现下单成功数远远超过真正库存数的情况，这尤其会发生在大促的热门商品上。如此一来就会导致很多买家下单成功后却付不了款，购物体验自然是比较差的。
6.2.2.3 预扣库存
优势：缓解了以上两种方式的问题。预扣库存实际就是“下单减库存”和 “付款减库存”两种方式的结合，将两次操作进行了前后关联，下单时预扣库存，付款时释放库存。
劣势：并没有彻底解决以上问题。比如针对恶意下单的场景，虽然可以把有效付款时间设置为 10 分钟，但恶意买家完全可以在 10 分钟之后再次下单。
6.2.3 实际如何减库存
业界最为常见的是预扣库存。无论是外卖点餐还是电商购物，下单后一般都有个 “有效付款时间”，超过该时间订单自动释放，这就是典型的预扣库存方案。但如上所述，预扣库存还需要解决恶意下单的问题，保证商品卖的出去；另一方面，如何避免超卖，也是一个痛点。
卖的出去：恶意下单的解决方案主要还是结合安全和反作弊措施来制止。比如，识别频繁下单不付款的买家并进行打标，这样可以在打标买家下单时不减库存；再比如为大促商品设置单人最大购买件数，一人最多只能买 N 件商品；又或者对重复下单不付款的行为进行次数限制阻断等
避免超卖：库存超卖的情况实际分为两种。对于普通商品，秒杀只是一种大促手段，即使库存超卖，商家也可以通过补货来解决；而对于一些商品，秒杀作为一种营销手段，完全不允许库存为负，也就是在数据一致性上，需要保证大并发请求时数据库中的库存字段值不能为负，一般有多种方案：一是在通过事务来判断，即保证减后库存不能为负，否则就回滚；二是直接设置数据库字段类型为无符号整数，这样一旦库存为负就会在执行 SQL 时报错；三是使用 CASE WHEN 判断语句——
UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END
业务手段保证商品卖的出去，技术手段保证商品不会超卖，库存问题从来就不是简单的技术难题，解决问题的视角是多种多样的。
6.2.4 一致性性能的优化
库存是个关键数据，更是个热点数据。对系统来说，热点的实际影响就是 “高读” 和 “高写”，也是秒杀场景下最为核心的一个技术难题。
6.2.4.1 高并发读
秒杀场景解决高并发读问题，关键词是“分层校验”。即在读链路时，只进行不影响性能的检查操作，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求等，而不做一致性校验等容易引发瓶颈的检查操作；直到写链路时，才对库存做一致性检查，在数据层保证最终准确性。
因此，在分层校验设定下，系统可以采用分布式缓存甚至LocalCache来抵抗高并发读。即允许读场景下一定的脏数据，这样只会导致少量原本无库存的下单请求被误认为是有库存的，等到真正写数据时再保证最终一致性，由此做到高可用和一致性之间的平衡。
实际上，分层校验的核心思想是：不同层次尽可能过滤掉无效请求，只在“漏斗” 最末端进行有效处理，从而缩短系统瓶颈的影响路径。
6.2.4.2 高并发写
高并发写的优化方式，一种是更换DB选型，一种是优化DB性能，以下分别进行讨论。
6.2.4.3 更换DB选型
秒杀商品和普通商品的减库存是有差异的，核心区别在数据量级小、交易时间短，因此能否把秒杀减库存直接放到缓存系统中实现呢，也就是直接在一个带有持久化功能的缓存中进行减库存操作，比如 Redis？
如果减库存逻辑非常单一的话，比如没有复杂的 SKU 库存和总库存这种联动关系的话，个人认为是完全可以的。但如果有比较复杂的减库存逻辑，或者需要使用到事务，那就必须在数据库中完成减库存操作。
6.2.4.4 优化DB性能
库存数据落地到数据库实现其实是一行存储（MySQL），因此会有大量线程来竞争 InnoDB 行锁。但并发越高，等待线程就会越多，TPS 下降，RT 上升，吞吐量会受到严重影响——注意，这里假设数据库已基于上文【性能优化】完成数据隔离，以便于讨论聚焦 。
解决并发锁的问题，有两种办法：
应用层排队。通过缓存加入集群分布式锁，从而控制集群对数据库同一行记录进行操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用过多的数据库连接
数据层排队。应用层排队是有损性能的，数据层排队是最为理想的。业界中，阿里的数据库团队开发了针对InnoDB 层上的补丁程序（patch），可以基于DB层对单行记录做并发排队，从而实现秒杀场景下的定制优化——注意，排队和锁竞争是有区别的，如果熟悉 MySQL 的话，就会知道 InnoDB 内部的死锁检测，以及 MySQL Server 和 InnoDB 的切换都是比较消耗性能的。另外阿里的数据库团队还做了很多其他方面的优化，如 COMMIT_ON_SUCCESS 和 ROLLBACK_ON_FAIL 的补丁程序，通过在 SQL 里加入提示（hint），实现事务不需要等待实时提交，而是在数据执行完最后一条 SQL 后，直接根据 TARGET_AFFECT_ROW 的结果进行提交或回滚，减少网络等待的时间（毫秒级）。目前阿里已将包含这些补丁程序的 MySQL 开源：AliSQL
6.3 高可用设计
盯过秒杀流量监控的话，会发现它不是一条蜿蜒而起的曲线，而是一条挺拔的直线，这是因为秒杀请求高度集中于某一特定的时间点。这样一来就会造成一个特别高的零点峰值，而对资源的消耗也几乎是瞬时的。所以秒杀系统的可用性保护是不可或缺的。
6.3.1 流量削峰
对于秒杀的目标场景，最终能够抢到商品的人数是固定的，无论 100 人和 10000 人参加结果都是一样的，即有效请求额度是有限的。并发度越高，无效请求也就越多。但秒杀作为一种商业营销手段，活动开始之前是希望有更多的人来刷页面，只是真正开始后，秒杀请求不是越多越好。因此系统可以设计一些规则，人为的延缓秒杀请求，甚至可以过滤掉一些无效请求。
答题
早期秒杀只是简单的点击秒杀按钮，后来才增加了答题。为什么要增加答题呢？主要是通过提升购买的复杂度，达到两个目的：
防止作弊。早期秒杀器比较猖獗，存在恶意买家或竞争对手使用秒杀器扫货的情况，商家没有达到营销的目的，所以增加答题来进行限制
延缓请求。零点流量的起效时间是毫秒级的，答题可以人为拉长峰值下单的时长，由之前的 <1s 延长到 <10s。这个时间对于服务端非常重要，会大大减轻高峰期并发压力；另外，由于请求具有先后顺序，答题后置的请求到来时可能已经没有库存了，因此根本无法下单，此阶段落到数据层真正的写也就非常有限了
需要注意的是，答题除了做正确性验证，还需要对提交时间做验证，比如<1s 人为操作的可能性就很小，可以进一步防止机器答题的情况。答题目前已经使用的非常普遍了，本质是通过在入口层削减流量，从而让系统更好地支撑瞬时峰值。
排队
最为常见的削峰方案是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。除了消息队列，类似的排队方案还有很多，例如：
线程池加锁等待
本地内存蓄洪等待
本地文件序列化写，再顺序读
排队方式的弊端也是显而易见的，主要有两点：
请求积压。流量高峰如果长时间持续，达到了队列的水位上限，队列同样会被压垮，这样虽然保护了下游系统，但是和请求直接丢弃也没多大区别
用户体验。异步推送的实时性和有序性自然是比不上同步调用的，由此可能出现请求先发后至的情况，影响部分敏感用户的购物体验
排队本质是在业务层将一步操作转变成两步操作，从而起到缓冲的作用，但鉴于此种方式的弊端，最终还是要基于业务量级和秒杀场景做出妥协和平衡。
过滤
过滤的核心结构在于分层，通过在不同层次过滤掉无效请求，达到数据读写的精准触发。常见的过滤主要有以下几层：
1、读限流：对读请求做限流保护，将超出系统承载能力的请求过滤掉
2、读缓存：对读请求做数据缓存，将重复的请求过滤掉
3、写限流：对写请求做限流保护，将超出系统承载能力的请求过滤掉
4、写校验：对写请求做一致性校验，只保留最终的有效数据
过滤的核心目的是通过减少无效请求的数据IO保障有效请求的IO性能。
系统可以通过入口层的答题、业务层的排队、数据层的过滤达到流量削峰的目的，本质是在寻求商业诉求与架构性能之间的平衡。另外，新的削峰手段也层出不穷，以业务切入居多，比如零点大促时同步发放优惠券或发起抽奖活动，将一部分流量分散到其他系统，这样也能起到削峰的作用。
6.3.2 Plan B
当一个系统面临持续的高峰流量时，其实是很难单靠自身调整来恢复状态的，日常运维没有人能够预估所有情况，意外总是无法避免。尤其在秒杀这一场景下，为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底。高可用建设，其实是一个系统工程，贯穿在系统建设的整个生命周期。
具体来说，系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段，以及故障发生时，逐一进行分析：
架构阶段：考虑系统的可扩展性和容错性，避免出现单点问题。例如多地单元化部署，即使某个IDC甚至地市出现故障，仍不会影响系统运转
编码阶段：保证代码的健壮性，例如RPC调用时，设置合理的超时退出机制，防止被其他系统拖垮，同时也要对无法预料的返回错误进行默认的处理
测试阶段：保证CI的覆盖度以及Sonar的容错率，对基础质量进行二次校验，并定期产出整体质量的趋势报告
发布阶段：系统部署最容易暴露错误，因此要有前置的checklist模版、中置的上下游周知机制以及后置的回滚机制
运行阶段：系统多数时间处于运行态，最重要的是运行时的实时监控，及时发现问题、准确报警并能提供详细数据，以便排查问题
故障发生：首要目标是及时止损，防止影响面扩大，然后定位原因、解决问题，最后恢复服务
对于日常运维而言，高可用更多是针对运行阶段而言的，此阶段需要额外进行加强建设，主要有以下几种手段：
预防：建立常态压测体系，定期对服务进行单点压测以及全链路压测，摸排水位
管控：做好线上运行的降级、限流和熔断保护。需要注意的是，无论是限流、降级还是熔断，对业务都是有损的，所以在进行操作前，一定要和上下游业务确认好再进行。就拿限流来说，哪些业务可以限、什么情况下限、限流时间多长、什么情况下进行恢复，都要和业务方反复确认
监控：建立性能基线，记录性能的变化趋势；建立报警体系，发现问题及时预警
恢复：遇到故障能够及时止损，并提供快速的数据订正工具，不一定要好，但一定要有
在系统建设的整个生命周期中，每个环节中都可能犯错，甚至有些环节犯的错，后面是无法弥补的或者成本极高的。所以高可用是一个系统工程，必须放到整个生命周期中进行全面考虑。同时，考虑到服务的增长性，高可用更需要长期规划并进行体系化建设。
6.3.3 高可用设计总结
高可用其实是在说 “稳定性”，稳定性是一个平时不重要，但出了问题就要命的事情，然而它的落地又是一个问题——平时业务发展良好，稳定性建设就会降级给业务让路。解决这个问题必须在组织上有所保障，比如让业务负责人背上稳定性绩效指标，同时在部门中建立稳定性建设小组，小组成员由每条线的核心力量兼任，绩效由稳定性负责人来打分，这样就可以把体系化的建设任务落实到具体的业务系统中了。
七：E-R关系图
用于指导如何建立领域模型。从E-R图上我们能看出，几个比较重要的领域模型：如活动、活动商品，系统真正编码落地的时候，紧紧围绕这些领域模型去建模，做到代码和领域模型的表达一致的。
八：产品边界
概要设计的目的是为了明确产品功能和系统边界，通过领域驱动的界限上下文图，能清晰地看出完成当前需求需要参与协作的团队，以及团队与团队之间任务划分边界。活动上下文是我们关注的重点，同时也应该看到，我们需要商品团队、交易团队的协作。
九：秒杀流程图：
不同的秒杀体量针对的技术选型都不一样，这个流程可以支撑起百万的流量，如果是成千万破亿那就得重新设计了。比如数据库的分库分表、队列改成用kafka、redis增加集群数量等手段。
十：秒杀架构总结
