点击“终码一生”，关注，置顶公众号
每日技术干货，第一时间送达！
京东秒杀是京东最大的营销频道，近年来随着业务的高速发展，频道商品数量和用户流量都呈现出迅猛增长的态势。
同时业务方规划未来频道商品数量会增加 5 至 10 倍，对商品池扩容诉求较为强烈，这对我们现有的系统架构提出了挑战。
为了应对商品数量激增引起的风险，秒杀后台组在年初成立了秒杀商品池扩容技术优化专项，在 618 前按计划完成了千万级商品池扩容的架构升级。本文主要介绍秒杀商品池扩容专项的优化经验。
京东秒杀频道业务主要包括两部分：
图 1：京东秒杀频道业务
秒杀系统是一个高并发大流量系统，使用缓存技术来提高系统性能。
在频道核心服务的历史业务迭代过程中，采用了在内存中全量缓存商品池数据的缓存方案。
这是因为频道业务中存在全量商品按照多维度排序的诉求，同时在频道发展初期商品数量不多，采用全量缓存的方式内存压力不大，开发成本较低。
由于秒杀商品存在时促销、库存有限的特点，对数据更新的实时性要求较高，我们通过 ZK 通知的方式实现商品数据更新。
原系统架构如图 2 所示：
图 2：京东秒杀原系统架构图
秒杀 CMS 系统在商品录入或更新时，以活动的维度将商品数据推动到 JIMDB(京东内部分布式缓存与高速键值存储服务，类似于 Redis)中，同时通过 ZooKeeper 发送通知。
秒杀 SOA 系统监听通知后从 JIMDB 中获取最新的数据，更新本地缓存，以提供频道核心服务和商品打标服务。
在以往大促期间，当商品池数量激增时，观察到系统的堆内存消耗过快，同时 Minor GC 垃圾回收效果有限，Minor GC 回收后堆内存低点不断抬高，堆内存呈持续增长的态势，并且会规律性地定期猛增。
Full GC 较为频繁，对 CPU 利用率的影响较大，接口性能毛刺现象严重。
图 3：系统异常监控
通过 JVM 堆内存变化图可以看到：
频繁 GC 对系统的稳定性和接口的性能造成严重的影响分析堆对象增长情况，通过 jmap -histo 指令在发生 Full GC 前后打印 JVM 堆中的对象，如图 4、图 5 所示：
图 4：发生 Full GC 前堆内存对象
图 5：发生 Full GC 后堆内存对象
从 Full GC 前后堆中对象分布情况分析，以品类秒杀为例，在 Full GC 后堆中不到 100 万商品对象，占内存 125M 左右，和品类秒杀实际有效商品数量大致相当， String 对象共占约 385M 左右。
而在发生 Full GC 前，堆中品类秒杀商品数量达到了接近 500 万，占用内存达到了 700M，另外 String 对象占用内存达到 1.2G。
结合系统架构分析，可以确定是在商品的覆盖更新过程中，旧对象未被回收而不断进入老年代，老年代内存占用越来越高，最终导致堆内存不足而产生 Full GC。
堆对象中的 String 对象也是这种更新方式的副产品，这是因为商品数据在 JIMDB 中以 String 方式存储，在更新时会从 JIMDB 中拉取到本地反序列化后得到对象列表。
可以从图 6 所示问题代码中看到产生大 String 对象的原因：
图 6：问题代码
对于上述的全量更新场景，旧对象和临时产生的 String 对象满足垃圾回收的条件，为什么没有在 Minor GC 阶段被回收?
我们知道大多数情况下，对象在新生代 Eden 区中分配，对象进入老年代有以下几种情况：
①大对象直接进入年老代：大对象即需要大量连续内存空间的 Java 对象，如长字符串及数组。
大对象会导致内存剩余空间足够时，就提前触发垃圾收集以获取足够的连续空间来安置，同时大对象的频繁复制也会影响性能。
虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，使大于该阈值的对象直接在老年代分配。为避免临时 String 对象直接进入老年代的情况，我们显式关闭了该功能。
②长期存活的对象将进入年老代：虚拟机给每个对象定义了一个对象年龄计数器，在对象在 Eden 创建并经过第一次 Minor GC 后仍然存活，并能被 Suivivor 容纳的话，将会被移动到 Survivor 空间，并对象年龄设置为 1。
每经历一次 Minor GC，年龄增加 1 岁，当到达阈值时(可以通过参数 -XX: MaxTenuringThreshold 设置，CMS 垃圾回收器默认值为 6)，将会晋升老年代。上述分析情况，临时 String 对象不会存活过 6 次 Minor GC。
③动态对象年龄判定：为了更好地适应不同程序内存状况，虚拟机并不硬性要求对象年龄达到 MaxTenuringThreshold 才能晋升老年代。
如果在 Survivor 空间中小于等于某个年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入年老代。
通过上述分析，我们发现临时 String 对象最有可能触发了动态对象年龄判定机制而进入老年代。
打印虚拟机 GC 信息，并添加-XX: +PrintTenuringDistribution参数来打印发生 GC 时新生代的对象年龄信息，得到图 7 所示 GC 日志信息：
图 7：GC 日志
从 GC 日志可以看到，Survivor 空间大小为 358M，Survivor 区的目标使用率默认是 50%，Desired Survivor size 是 179M，age <= 2 的对象大小总和为 269M。
因此虽然设定的晋升阈值是 6，虚拟机动态计算晋升阈值为 2，最终导致 age 大于等于 2 的对象都进入老年代。
我们尝试从优化 JVM 参数的方式解决问题，效果并不理想。做过的尝试有：
增大年轻代的空间来减少对象进入老年代，结果适得其反，STW 更加频繁，CPU 利用率波动也更大。
改用 G1 垃圾收集器，效果不明显，CPU 利用率波动也更大。
显式设置晋升老年代的阈值(MaxTenuringThreshold)，试图推迟对象进入老年代的速度，无任何效果。
上述问题分析的结论对我们的启示是：如果在新生代中频繁产生朝生夕死的大对象，会触发虚拟机的动态对象年龄判定机制，降低对象进入老年代的门槛，导致堆内存增长过快。
①双缓存区定时散列更新
通过上面的分析可以发现，为了防止堆内存增长过快，需要控制商品数据更新的粒度和频次。
原有的商品更新方案是商品数据按照活动的维度全量覆盖更新，每个商品的状态变化都会触发更新操作。
我们希望数据更新能控制在更小的范围，同时能够控制数据更新的频率，最终设计出双缓存区定时散列更新方案，如图 8 所示。
图 8：双缓存区定时散列更新示意图
该方案的实现是将活动下的商品以 SKU 维度散列到不同的桶中，更新的操作以桶的粒度进行。
同时为了控制数据更新的频率，我们在 SOA 端设计了双缓存区定时切量的方式。
在 CMS 商品数据更新时，会映射到需要更新的桶，并实时通知 SOA 端;在 SOA 端收到 ZK 通知后，会在读缓存区标记需要更新的桶，但不会实时的更新数据。
在达到定时时间后，会自动切换读写缓存区，此时会读取读缓存区中标记的待更新桶，从 JIMDB 中获取桶对应的商品列表，完成数据的细粒度分段更新。
该方案散列份数和定时时间可以根据具体业务情况进行调整，在性能和实时性上取得平衡，在上线后取得了较好的优化效果。
②引入本地 LRU 缓存
双缓存区定时散列更新的方案虽然在系统性能上得到了提升，但依然无法支持千万级商品的扩容。
为了彻底摆脱机器内存对商品池容量的限制，我们启动了秒杀架构的全面升级，核心思路是引入本地 LRU 缓存组件，实现冷数据淘汰，以控制内存中缓存商品的总数量在安全区间。
系统拆分：原系统存在的问题是，频道核心服务和商品打标服务共用相同的基础数据，存在系统耦合的问题。
从商品池角度分析，频道核心服务商品池是秒杀商品池的子集。从业务角度分析，频道核心服务业务逻辑复杂，调用链路长，响应时间长，商品打标服务逻辑简单，调用链路短，响应时间短。
将频道核心服务和商品打标服务进行拆分，独立部署，实现资源隔离，这样可以根据业务特点做针对性优化。
频道核心服务可以减少内存中商品缓存的数量，商品打标服务可以升级商品缓存方案，另外也可以规避架构升级过程中对频道核心服务的影响。
图 9：系统拆分
缓存方案优化：频道核心服务历史逻辑复杂，且直接面向终端用户，升级难度大。
在扩容专项一期中的主要优化点是拆分出频道核心服务商品池，去除非频道展示商品，以减少商品缓存数量。一期优化主要聚焦于秒杀打标服务的缓存方案升级。
在原有的系统架构中秒杀商品池全量缓存在内存中，这会导致商品数量激增时，JVM 堆内存资源紧张，商品池的容量受到限制，且无法水平扩容。
商品以活动的维度进行存储和更新，会导致大 key 的问题，在进行覆盖更新时会在内存中产生临时的大对象，不利于 JVM 垃圾回收表现。
图 10：缓存方案升级
对于拆封后的商品打标服务，缓存方案优化的总体思路是实现冷热数据的拆分。
升级后的商品打标服务不再使用本地全量缓存，而是使用 JIMDB 全量缓存+本地 LRU 缓存组件的方式。
对缓存组件的要求是在缓存数据达到预设商品数量上限时，实现冷数据的清退，同时具有较高的缓存命中率和读写性能。
在对比常用的缓存框架 Caffeine 和 Guava Cache 后最终采用 Caffeine 缓存。
其优势有：
-
性能更优。Caffeine 的读写性能显著优于 Guava， 这是由于 Guava 中读写操作夹杂着过期时间的处理，一次 put 操作中有可能会触发淘汰操作，所以其读写性能会受到一定影响。
-
而 Caffeine 对这些事件的操作是异步的，将事件提交至队列，通过默认的 ForkJoinPool.commonPool() 或自己配置的线程池，进行取队列操作，再进行异步淘汰、过期操作。
-
高命中率，低内存占用。Guava 使用分段 LRU 算法，而 Caffeine 使用了一种结合 LRU、LFU 优点的算法：W-TinyLFU，可以使用较少的资源来记录访问频次，同时能够解决稀疏突发访问元素的问题。
升级后的架构图如图 11 所示：
图 11：升级后架构图
频道核心服务和商品打标服务独立部署，资源隔离。秒杀 CMS 在商品录入和更新时，以 SKU 维度写入 JIMDB 中组成全量秒杀商品池。
商品打标服务通过 Caffeine 缓存的方式，设置写入写入 30s 过期，最大缓存 200w 商品数据，实现热数据缓存，过期数据和冷数据的淘汰。
③引入布隆过滤器
在非秒杀 SKU 查询处理上，为了避免缓存穿透问题(即单个无效商品的高频次查询，如果本地缓存中没有则每次请求都会访问到 JIMDB)，我们对于非秒杀商品的查询结果，在本地缓存中存储一个空值标识，避免无效 SKU 请求每次都访问到 JIMDB。
商详、购物车等渠道商品池数量比秒杀商品池高几个数量级，秒杀查询服务请求 SKU 中存在大量的非秒杀商品，这会导致本地缓存的命中率降低，同时带来缓存雪崩的风险。
为了拦截大量非秒杀 SKU 的请求，我们引入过滤器机制。在本地过滤器的选择上，我们尝试使用所有有效商品 SkuId 组成的 Set 集合来生成本地过滤器，上线后观察到本地过滤器数据更新时会产生性能波动。
简介：《秒杀系统架构优化思路》 上周参加Qcon，有个兄弟分享秒杀系统的优化，其观点有些赞同，大部分观点却并不同意，结合自己的经验，谈谈自己的一些看法。一、为什么难 秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。又例如12306抢票，亦与秒杀类似，瞬时流量更甚。
《秒杀系统架构优化思路》
上周参加Qcon，有个兄弟分享秒杀系统的优化，其观点有些赞同，大部分观点却并不同意，结合自己的经验，谈谈自己的一些看法。
一、为什么难
秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。
例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。
又例如12306抢票，亦与秒杀类似，瞬时流量更甚。
二、常见架构
流量到了亿级别，常见站点架构如上：
1）浏览器端，最上层，会执行到一些JS代码
2）站点层，这一层会访问后端数据，拼html页面返回给浏览器
3）服务层，向上游屏蔽底层数据细节
4）数据层，最终的库存是存在这里的，mysql是一个典型
三、优化方向
1）将请求尽量拦截在系统上游：传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小【一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0】
2）充分利用缓存：这是一个典型的读多写少的应用场景【一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%】，非常适合使用缓存
四、优化细节
4.1）浏览器层请求拦截
点击了“查询”按钮之后，系统那个卡呀，进度条涨的慢呀，作为用户，我会不自觉的再去点击“查询”，继续点，继续点，点点点。。。有用么？平白无故的增加了系统负载（一个用户点5次，80%的请求是这么多出来的），怎么整？
a）产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求
b）JS层面，限制用户在x秒之内只能提交一次请求
如此限流，80%流量已拦。
4.2）站点层请求拦截与页面缓存
浏览器层的请求拦截，只能拦住小白用户（不过这是99%的用户哟），高端的程序员根本不吃这一套，写个for循环，直接调用你后端的http请求，怎么整？
a）同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面
b）同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面
如此限流，又有99%的流量会被拦截在站点层
4.3）服务层请求拦截与数据缓存
站点层的请求拦截，只能拦住普通程序员，高级黑客，假设他控制了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧？怎么整？
a）大哥，我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？对于写请求，做请求队列，每次只透有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”
b）对于读请求，还要我说么？cache抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的
如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了
4.4）数据层闲庭信步
到了数据这一层，几乎就没有什么请求了，单机也能扛得住，还是那句话，库存是有限的，小米的产能有限，透这么多请求来数据库没有意义。
五、总结
没什么总结了，上文应该描述的非常清楚了，对于秒杀系统，再次重复下笔者的两个架构优化思路：
1）尽量将请求拦截在系统上游
2）读多写少的常用多使用缓存
你一听，完了呀，这我们的服务器哪里顶得住啊！说真的直接打DB肯定挂。
是吧，秒杀的特点就是这样时间极短、 瞬间用户量大。正常的店铺营销都是用极低的价格配合上短信、APP的精准推送，
吸引特别多的用户来参与这场秒杀，爽了商家苦了开发呀。秒杀大家都知道如果真的营销到位，价格诱人，几十万的流量我觉得完全不是问题，
那单机的Redis我感觉3-4W的QPS还是能顶得住的，但是再高了就没办法了，那这个数据随便搞个热销商品的秒杀可能都不止了。
大量的请求进来，我们需要考虑的点就很多了，缓存雪崩，缓存击穿，缓存穿透这些我之前提到的点都是有可能发生的，出现问题打挂DB那就很难受了，
活动失败用户体验差，活动人气没了，最后背锅的还是开发。
超卖：但凡是个秒杀，都怕超卖，我这里举例的只是尿不湿，要是换成100个华为MatePro3
0，商家的预算经费卖100个可以赚点还可以造势，结果你写错程序多卖出去200个，你不发货用户投诉你，平台封你店，你发货就血亏，你怎么办？（没事
看了敖丙的文章直接不怕）那最后只能杀个开发祭天解气了，秒杀的价格本来就低了，基本上都是不怎么赚钱的，超卖了就恐怖了呀，所以超卖也是很关键的
一个点。恶意请求：你这么低的价格，假如我抢到了，我转手卖掉我不是血赚？就算我不卖我也不亏啊，那用户知道，你知道，别的别有用心的人（黑客、黄牛…）肯定也知道的。那简单啊，我知道你什么时候抢，我搞个几十台机器搞点脚本，我也模拟出来十几万个人左右的请求，那我是不是意味着我基本上有80%的成功率了。真实情况可能远远不止，因为机器请求的速度比人的手速往往快太多了，在贵州的敖丙我每年回家抢高铁票都是秒光的，我也不知道有没有黄牛的功劳，我要Diss你，黄牛。杰伦演唱会门票抢不到，我也Diss你。Tip：科普下，小道消息了解到的，黄牛的抢票系统，比国内很多小公司的系统还吊很多，架构设计都是顶级的，我用顶配的服务加上顶配的架构设计，你还想看演唱会？还想回家？不过不用黄牛我回家都难，我们云贵川跟我一样要回家过年的仔太多了555！点我领取一线大厂面试资料和简历模板链接暴露：前面几个问题大家可能都很好理解，一看到这个有的小伙伴可能会比较疑惑，啥是链接暴露呀？相信是个开发同学都对这个画面一点都不陌生吧，懂点行的仔都可以打开谷歌的开发者模式，然后看看你的网页代码，有的就有URL，但是我写VUE的时候是事件触发然后去调用文件里面的接口看源码看不到，但是我可以点击一下查看你的请求地址啊，不过你好像可以对按钮在秒杀前置灰。不管怎么样子都有危险，撇开外面的所有的东西你都挡住了，你卖这个东西实在便宜得过分，有诱惑力，你能保证开发不动心？开发知道地址，在秒杀的时候自己提前请求。。。（开发：怎么TM又是我）数据库：每秒上万甚至十几万的QPS（每秒请求数）直接打到数据库，基本上都要把库打挂掉，而且你服务不单单是做秒杀的还涉及其他的业务，你没做降级、限流、熔断啥的，别的一起挂，小公司的话可能全站崩溃404。反正不管你秒杀怎么挂，你别把别的搞挂了对吧，搞挂了就不是杀一个程序员能搞定的。程序员：我TM好难啊！问题都列出来了，那怎么设计，怎么解决这些问题就是接下去要考虑的了，我们对症下药。服务单一职责：设计个能抗住高并发的系统，我觉得还是得单一职责。什么意思呢，大家都知道现在设计都是微服务的设计思想，然后再用分布式的部署方式也就是我们下单是有个订单服务，用户登录管理等有个用户服务等等，那为啥我们不给秒杀也开个服务，我们把秒杀的代码业务逻辑放一起。单独给他建立一个数据库，现在的互联网架构部署都是分库的，一样的就是订单服务对应订单库，秒杀我们也给他建立自己的秒杀库。至于表就看大家怎么设计了，该设置索引的地方还是要设置索引的，建完后记得用explain看看SQL的执行计划。（不了解的小伙伴也没事，MySQL章节我会说的）单一职责的好处就是就算秒杀没抗住，秒杀库崩了，服务挂了，也不会影响到其他的服务。（强行高可用）秒杀链接加盐：我们上面说了链接要是提前暴露出去可能有人直接访问url就提前秒杀了，那又有小伙伴要说了我做个时间的校验就好了呀，那我告诉你，知道链接的地址比起页面人工点击的还是有很大优势。我知道url了，那我通过程序不断获取最新的北京时间，可以达到毫秒级别的，我就在00毫秒的时候请求，我敢说绝对比你人工点的成功率大太多了，而且我可以一毫秒发送N次请求，搞不好你卖100个产品我全拿了。那这种情况怎么避免？简单，把URL动态化，就连写代码的人都不知道，你就通过MD5之类的加密算法加密随机的字符串去做url，然后通过前端代码获取url后台校验才能通过。暖男我呢，又准备了一个简单的url加密给大家尝尝鲜，还不点个赞？Redis集群：之前不是说单机的Redis顶不住嘛，那简单多找几个兄弟啊，秒杀本来就是读多写少，那你们是不是瞬间想起来我之前跟你们提到过的，Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接无敌高可用！Nginx：Nginx大家想必都不陌生了吧，这玩意是高性能的web服务器，并发也随便顶几万不是梦，但是我们的Tomcat只能顶几百的并发呀，那简单呀负载均衡嘛，一台服务几百，那就多搞点，在秒杀的时候多租点流量机。Tip：据我所知国内某大厂就是在去年春节活动期间租光了亚洲所有的服务器，小公司也很喜欢在双十一期间买流量机来顶住压力。这样一对比是不是觉得你的集群能顶很多了。恶意请求拦截也需要用到它，一般单个用户请求次数太夸张，不像人为的请求在网关那一层就得拦截掉了，不然请求多了他抢不抢得到是一回事，服务器压力上去了，可能占用网络带宽或者把服务器打崩、缓存击穿等等。资源静态化：秒杀一般都是特定的商品还有页面模板，现在一般都是前后端分离的，所以页面一般都是不会经过后端的，但是前端也要自己的服务器啊，那就把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力。点我领取一线大厂面试资料和简历模板按钮控制：大家有没有发现没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击。这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器，然后还没到秒杀的时候基本上服务器就挂了。这个时候就需要前端的配合，定时去请求你的后端服务器，获取最新的北京时间，到时间点再给按钮可用状态。按钮可以点击之后也得给他置灰几秒，不然他一样在开始之后一直点的。你敢说你们秒杀的时候不是这样的？限流：限流这里我觉得应该分为前端限流和后端限流。前端限流：这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。后端限流：秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等。我这里就不展开了，就说一下物理的限流。库存预热：秒杀的本质，就是对库存的抢夺，每个秒杀的用户来你都去数据库查询库存校验库存，然后扣减库存，撇开性能因数，你不觉得这样好繁琐，对业务开发人员都不友好，而且数据库顶不住啊。开发：你tm总算为我着想一次了。那怎么办？我们都知道数据库顶不住但是他的兄弟非关系型的数据库Redis能顶啊！那不简单了，我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了。但是用了Redis就有一个问题了，我们上面说了我们采用主从，就是我们会去读取库存然后再判断然后有库存才去减库存，正常情况没问题，但是高并发的情况问题就很大了。这里我就不画图了，我本来想画图的，想了半天我觉得语言可能更好表达一点。多品几遍！！！就比如现在库存只剩下1个了，我们高并发嘛，4个服务器一起查询了发现都是还有1个，那大家都觉得是自己抢到了，就都去扣库存，那结果就变成了-3，是的只有一个是真的抢到了，别的都是超卖的。咋办？Lua：之前的文章就简单的提到了他，我今天就多一定点篇幅说一下吧。Lua 脚本功能是 Reids在 2.6 版本的最大亮点， 通过内嵌对 Lua 环境的支持， Redis 解决了长久以来不能高效地处理 CAS （check-and-set）命令的缺点， 并且可以通过组合使用多个命令， 轻松实现以前很难实现或者不能高效实现的模式。Lua脚本是类似Redis事务，有一定的原子性，不会被其他命令插队，可以完成一些Redis事务性的操作。这点是关键。知道原理了，我们就写一个脚本把判断库存扣减库存的操作都写在一个脚本丢给Redis去做，那到0了后面的都Return False了是吧，一个失败了你修改一个开关，直接挡住所有的请求，然后再做后面的事情嘛。限流&降级&熔断&隔离：这个为啥要做呢，不怕一万就怕万一，万一你真的顶不住了，限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。<img src=”削峰填谷：一说到这个名词，很多小伙伴就知道了，对的MQ，你买东西少了你直接100个请求改库我觉得没问题，但是万一秒杀一万个，10万个呢？服务器挂了，程序员又要背锅的。Tip：可能小伙伴说我们业务达不到这个量级，没必要。但是我想说我们写代码，就不应该写出有逻辑漏洞的代码，至少以后公司体量上去了，别人一看居然不用改代码，一看代码作者是敖丙？有点东西！你可以把它放消息队列，然后一点点消费去改库存就好了嘛，不过单个商品其实一次修改就够了，我这里说的是某个点多个商品一起秒杀的场景，像极了双十一零点。点我领取一线大厂面试资料和简历模板总结到这里我想我已经基本上把该考虑的点还有对应的解决方案也都说了一下，不知道还有没有没考虑到的，但是就算没考虑到我想我这个设计，应该也能撑住一个完整的秒杀流程。最后我就画个完整的流程图给大家收个尾吧！Tip：这个链路还是比较简单的，很多细节的点全部画出来就太复杂了，我上面已经提到了所有的注意点了，大家都看看，真正的秒杀有比我这个简单的，也有比我这个复杂N倍的，之前的电商老东家就做的很高级，有机会也可以跟你们探讨，不过是面试嘛，我就给思路，让你理解比较关键的点。
针对电影院线实际业务需求，设计出一套功能完整、性能高效稳定的秒杀系统。根据目标业务需求，将分布式框架Dubbo、Redis内存数据库、分布式消息队列RocketMQ、Spring框架集成应用于秒杀系统，实现秒杀系统功能模块化，有效快速的利用闲置的硬件资源提高秒杀系统活动时系统的稳定性。秒杀活动上线时可以快速水平拓展秒杀系统的服务提供者，活动结束时易于收缩系统，不会造成不必要的硬件资源浪费。在高并发下系统负载超过系统处理极限时保证系统不宕机，有部分用户可以正常使用。故本文确立如下研究目标：
（1）业务功能完整的影票秒杀系统。
（2）秒杀系统所必须的非功能性需求。
根据以上两点研究目标确定相应的研究内容如下：
（1）研究如何使用Nginx和Dubbo分布式框架针对秒杀系统进行合理的限流。
（2）研究如何使用Redis内存数据库提升系统整体性能。
（3）研究如何使用分布式消息队列RocketMQ对秒杀请求进行削峰填谷保证系统的稳定性。
1.1.2 研究内容
本系统预计准备要实现的目标是开发一个功能相对完整的影票秒杀系统，让用户可以方便地使用公司APP进行“秒杀”活动，让后台管理人员可以自由发布想要的秒杀信息和产品，使管理员可方便地管理和监控网上秒杀现状。一个典型的秒杀系统分为前端秒杀系统和后台管理系统，两个子系统分工不同，功能明确，针对不同的服务对象，前台秒杀系统主要面向用户，后端管理系统主要面向管理员，其中管理员角色分为商品管理员和秒杀活动管理员。针对线上院线业务需要构建业务需要的秒杀交易功能，该功能具有可靠、易用、易拓展等特点。将Dubbo框架应用于秒杀系统，实现秒杀系统服务化；融合了Spring框架使得各个功能模块化，降低功能模块耦合度，提交了开发效率，降低了维护和修改业务逻辑的成本，有效快速的利用闲置资源提高秒杀系统活动时的稳定性。高并发下系统负载超过极限时保证系统不宕机。
1.2 论文组织结构
第一章：根据课题的内容研究了论文的背景和意义，并且着眼国内外系统的现状,进行了系统的说明以及背景和意义，针对业务需求内容提出了论文的系统目标主要需求功能点，根据需求整理出了论文的整体框架
第二章：系统相关技术的研究与介绍。介绍影票秒杀系统使用的相关技术，Dubbo分布式服务框架核心功能、Dubbo 分布式服务框架组成、Nginx工作原理进程解析、Redis数据类型等系统核心技术。
第三章：基于Dubbo框架的秒杀系统需求分析。此章根据影票秒杀的具体业务进行了分析，分析的内容包括：（1）功能性需求秒杀用户用例、商品管理员用例、秒杀活动管理员用例。（2）非功能性需求系统安全性需求、系统稳定性需求、系统的优化。针对系统角色对用户进行了划分：秒杀用户、商品管理员、秒杀活动管理员等角色和功能。
第四章：基于Duboo框架的秒杀系统整体设计。此章根据需求分析的结果，对系统进行了设计，具体分为影票秒杀业务流程设计、秒杀业务负载均衡设计、核心秒杀接口的设计，针对系统进行了模块划分，秒杀模块、查询活动信息模块、活动管理模块等几个部分。
第五章：影票秒杀系统的设计与实现。此章根据以上两章的分析和设计，具体的描述了核心功能的实现，并针对秒杀接口的缓存和异步、防刷过载保护,以及实际的nginx和rocketMQ优化等功能进行了详细的阐述。针对实际内容进行了业务分析，提供了各个功能模块的类图和流程图，并且针对非功能性需求防刷功能、过载保护、以及整体系统的优化进行了详细的阐述。
第六章：影票秒杀系统的测试。此章对实现的功能进行测试，详细的描述了测试环境的硬件软件和部署情况，根据业务进行了测试用例的编写，针对核心秒杀接口进行了功能测试和压力测试。
结论：本章概括全文，对本论文的研究成果及完成的工作进行总结，分析目前存在的问题，并对进一步的工作方向进行了展望。
第一章 系统相关技术的研究与介绍
本章节会介绍在“秒杀”系统中使用的相关技术，为了后面章节里的需求设计和功能实现阐述奠定了技术基础。影票秒杀系统基于Jave平台开发，使用SpringMVC、Dubbo框架、Redis内存数据库、RocktMQ分布式消息队列等技术进行的开发与实现。Dubbo框架使用了很简洁的模型，服务提供者（Provider）、消费者（Consumer）、注册中心（registry）、监控中心（monitor）。应对高并发访问需要系统采用负载均衡技术来分发网络请求，Nginx是一个很好的选择。负载均衡的优点是，分担请求到多台服务器，解决并发高的问题，提高系统拓展性。消息队列可以在秒杀系统中起到削峰填谷作用的作用。Redis是基于内存的存储数据缓存，确保了程序数据快速的读写速度。同时Redis提供了丰富的数据类型字符串（string）、哈希（hash）、双向链表（list）、不重复集合（set）等[12]。
1.1 常见互联网电商技术架构
普通的网站应用面对的主要问题是复杂的使用场景、不断变更需求有时还要面对历史数据问题，高并发系统主要面对的不单单是以上描述的问题，还要面对极高的用户并发量和快速的业务处理。按照常规的划分方法分为业务逻辑的功能性需求和性能数量、安全挑战的非功能性需求。
常见的互联网站点设计通常遵循MVC（Model View Controller），模型视图控制。各个模块单独处理自己负责的内容，相互独立。控制层负责根据业务场景进行业务处理，模型层负责持久化的访问和存储；视图层根据返回的业务数据展示给前端内容。通常这种模式可以满足大多数业务场景，但是在秒杀的业务场景下，这个模式需要更细节的抽象和替换，但是大致还是按照这种模式划分的，如图2所示。应用层提供可视化服务给秒杀用户、商品管理员、秒杀活动管理员。一般情况下都是已HTML、JSP等方式进行展示，主要负责显示秒杀商品信息，把前端操作人的信息发送给后边的服务层，然后接收由服务层返回的HTML、JSP等页面信息展现给前端操作员浏览。应用层整体架构上使用了Dubbo框架的消费者模块，具体实现使用了Spring框架中的SpringMVC的View模块实现，本系统内使用HTML静态页面和JSP动态页面组成。应用层和服务层、数据层是相互独立开的，应用层和只关心后端传输过来的数据如何进行展示，不关心具体服务层、数据层具体是如何存储和计算的，只展示后端信息给前端操作用户[13]。
服务层，秒杀系统的服务层主要负责接收展现层传输过来的用户请求，并且把相应的数据内容请求转发给对应的业务逻辑模块中去，根据不同业务模块的处理结果，然后再返回给展现层，最终已JSP的形式展示给前端用户浏览。服务层相当于Dubbo框架的服务提供者，具体功能也是使用了Spring框架实现。服务提供者收到展示层的用户请求，会对业务数据进行初步判断，并且调用相应的实现模块去执行具体的业务需求，最终接收实现功能模块的返回，并且把信息封装好返回给应用层显示出来。
数据层，经过消息队列削峰填谷后的数据，最终会持久化到Mysql数据库中，数据层使用Mybatis框架来提供数据库的访问服务。使用Mybatis提供的Bean和库表映射机制，使开发可以用Java面向对象的方式来操作Mysql关系型数据库。数据持久层采用DAO（Data Access Object）抽象和封装了一些对数据库中数据的基本操作，减少了业务逻辑代码和数据库之间的耦合度，如果数据源发生转换或者改变，只需要修改系统相应配置文件中的对象配置信息即可，而业务逻辑代码不需要改变。Mysql数据库进行了主从复制，可以实现读写分离等功能提高系统整体性能。
1.1 Dubbo分布式服务框架
Dubbo分布式框架是阿里巴巴开源分布式解决方案，该框架一大特色是按照不同角色来划分系统功能，系统采用这种方式可以使各个模块之间松耦合，但是功能模块之间还是高内聚，Dubbo框架是具有易拓展、性能高、易监控、服务化、模块化等优点的RPC框架。按照服务角色划分，Dubbo框架使用了很简洁的模型，服务提供者（Provider）、消费者（Consumer）、注册中心（registry）、监控中心（monitor）；服务提供者顾名思义给系统其它模块提供服务，消费者负责调用系统其他的服务，注册中心负责维护消费者和服务提供者的调用关系，监控中心负责监控服务提供者、消费者、注册中心等各个子模块的运行情况[14]。Dubbo经过实际线上测试，并且是纯Java开发支持多种协议。给开发者提供了成熟的远程调用框架其核心部分包含如表1所示Dubbo功能在系统中的应用表:
（1） RPC分布式调用:提供Socekt级别的调用框架，默认使用Netty进行远程通讯，还支持mima、grizzly等方式的实现，使用client-server模式进行数据的传输。
（2）负载均衡：提供了多种远程调用的方式可以选择，去中心化极大的提升了系统的健壮性；默认提供了随机、权重、Hash的负载均衡方式，后台可动态修改，也可以根据框架提供的接口自己实现和自己业务相关的负载均衡方案。
（3）注册中心：本身Dubbo框架是去中心化的，所有服务提供者和消费者都定时在注册中心注册，通过对注册中心的监控非常方便服务的具体调用关系，系统平行拓展收缩非常简便且不影响正常业务的运行[15]。
分析发现这种方式空间复杂度高，内存占用比较高。过滤器优化为布隆过滤器后，内存占用降低，性能得到进一步提升。
在完成架构升级后，经过单机压测、灰度验证、灰度上线、全量压测等过程严格验证了新系统的性能和结果准确性，在 618 大促前新系统全量平稳上线。
从近年来大促期间系统表现来看，优化效果显著，如图 12、图 13 所示，主要体现在以下几个方面。
图 12：大促性能表现对比
业务支撑：秒杀商品池数量持续增长，由于架构的调整全量商品缓存在 JIMDB，新系统支持水平扩容，后续可支持更高数量级的商品，满足业务的长期规划。
性能优化：大促期间打标服务的接口 tp999 持续下降，618 大促接口性能提升 90%，同时从接口性能对比上看，接口性能的毛刺现象得到解决。
稳定性提升：GC 频率持续下降，系统稳定性得到提高。
图 13：接口性能监控对比
本次秒杀商品池扩容优化专项通过优化商品更新方式、系统拆分、优化缓存方案等方式，实现了系统架构升级，提升了频道的商品容量和性能，达到了预设目标。
PS：防止找不到本篇文章，可以收藏点赞，方便翻阅查找哦。
