坑爹的技术竞赛

几年前，公司组织了一次技术竞赛。自由组队，每组4人，36小时之内按要求完成设计、代码实现和文档。第一名奖金3万元。

一开始不是很想参加，因为要通宵熬夜（现在想想，不参加竞赛是个明智之举）！不过后来还是接收了其他部门的邀请，参赛了。但是，在比赛前一天，其他三个人放我鸽子！！！放我鸽子！！！放我鸽子！！！没办法，只能重新组队，最终两个后端、两个前端！但是，比赛当天，另一个后端去参加歌唱比赛了！！！参加歌唱比赛了！！！参加歌唱比赛了！！！所以变成了一个后端+两个前端。我们成了当时参赛小组里唯一的三人小组，唯一的有前端的小组，还是两个前端！！！

然后比赛的题目是：实现一个秒杀系统！！！

• 不能使用Java和Spring技术体系外的技术（因为除了我们组，其他组都是Java后端，所以只对Java技术做了限制），如果使用要扣分
• 吞吐量越高越好
• 不能出现超卖或少卖的情况
• 要有完善的文档
• ......

当时我们三个就想直接弃权了！但是转念一想，都走到这一步了，还是试试吧！

最终的结果是，我们没完成（意不意外？惊不惊喜？）！！！前端在最后时间点才开发完成，测试的时间都没有！后来测试的时候，修复了几个bug，为了公平起见，就没有参与最后的比赛！

不过，在所有的参赛队伍中，我们的吞吐量是最高的，其他队伍的TPS基本在三四千左右！我们的TPS基本在一万七左右！如果一开始就完成了，基本秒杀其他组！

我们的吞吐量是其它组的四倍，究其原因是因为我们的人员组成与其他组不同，导致我们的设计思路与其他组的设计思路也不同。

在之前的什么是软件架构一文中，我对软件架构做了一个定义：「架构是特定约束下决策的结果」！

这次技术竞赛的经历，正好可以验证这一观点：即使是在技术不对口、人数不足等劣势条件下，只要做出合适的决策，依然能做出超出预期的架构设计！

有时候，对于合适的架构设计，劣势有时候会成为优势！

我们先来看下，对于秒杀系统来说，一般的设计思路。

秒杀系统一般设计思路

秒杀系统的特点是：

• 瞬时请求量很高
• 持续时间较短

所以秒杀系统需要解决的是「在高并发情况下，用户请求及数据更新的问题」！

一般的设计思路：

• （变相）扩容
• 提高性能

具体方式有：

动静分离

对于一般的应用来说，请求流程大致如下：

• 服务端接收到请求，从数据库中查询相应数据
• 选择对应的展示模板
• 通过模板和数据渲染出最终页面
• 将页面返回给客户端

当访问量很大的时候，服务器压力会非常的大！解决方案就是动静分离！

做软件开发的都知道要「将变化的内容和不变的内容隔离开」，以便于独立进化。这里其实也是一样的思路。

模板是个静态的内容，部署后一般是不会变化的；而数据是个相对动态的内容，根据请求参数的不同，数据可能不同。所以我们需要将模板与数据分离。

以前的做法是后端事先生成渲染后的页面，缓存起来或直接部署到静态服务器或CDN，请求时直接从缓存（静态服务器/CDN）中获取页面，而动态数据通过AJAX请求的方式获取。服务器不再需要渲染页面，只需要返回少量的数据即可。既降低了服务器压力，又减少了服务端数据的传输。

而现在很流行的前后端分离就能很容易的解决这个问题。页面独立部署，数据异步获取，页面渲染由浏览器负责。这里和普通的前后端分离还有些差异，需要将相对静态的数据都静态化，以减少动态数据量。

分离后，静态内容和动态内容就可以独立进化。例如静态内容可以部署到CDN上，用户可以从最近的服务器获取到数据。相对热点的动态数据可以做缓存，降低数据库压力，进一步提高服务端响应。

独立部署

「独立部署」其实也可以看成是一种「动静分离」。将秒杀系统这个相对动态的系统，和相对静态的业务系统分开部署。

原因很好理解，秒杀系统的请求量很大，可能会由于预估不足或系统问题，导致了秒杀系统的负载过高、响应变慢。如果秒杀系统是业务系统的一部分，则会导致业务系统响应变慢，甚至导致系统没有响应。且秒杀是个短期活动也不是核心业务，而业务系统是需要长期稳定运行的。不能因为一个短期非核心的活动，而影响了核心的业务系统。

所以秒杀系统最好和业务系统分开独立部署。即使秒杀系统挂了，也不会影响业务系统的正常对外服务。

同样的道理，秒杀系统的数据库也需要和业务系统的数据库独立开。

限流削峰

动静分离，独立部署能提高系统的响应能力和容量。但是可提供的访问量是一定的，当超过了系统所能承受的容量，该怎么办呢？你可能会说，可以扩容啊。的确是可以，但是扩容也是有限度的。假设单机能承受10万的请求量，预计有1亿的请求量，你要扩容1000台服务器？！这会导致严重的浪费。

首先，上面提到了，秒杀是短期活动，为了秒杀多部署1000台服务器，秒杀结束后这些服务器再销毁？既浪费硬件资源、又浪费人力资源。

其次，秒杀的商品数量其实并不多，可能秒杀赚的那点钱还不够付服务器和带宽的费用。真·花钱赚吆喝！

我们该如何处理呢？

上面说了，秒杀的商品数量不多，也就是说，其实最后的真实成交量并不大。再进一步讲，很多的请求都是没用的。

其次，在秒杀前，买家会频繁的刷页面，这又额外增加了无用请求的数量。

我们只要把这些无用的请求提前都过滤掉，最终到达服务端的请求就会少很多，也就不需要这么多的服务器了。这就是限流削峰。具体做法有很多：

• 秒杀时间未到时，秒杀按钮置灰：也就是说在秒杀未到时间时，不可发送下单请求。前面我们已经将页面静态化，分发到了CDN，所以用户的刷新操作只会到CDN。这就削除了刷新操作导致的请求。
• 秒杀按钮点击后置灰：即避免double-click，一个用户只能点击一次。限制用户点击次数，避免秒杀工具带来过量无效请求。
• 秒杀前先做题：即在秒杀前需要先做题目，类似验证码功能，其实是降低了用户的点击频率，也限制了秒杀工具的使用。不过体验不好，不推荐使用。
• 限制请求次数：可以用js判定，限制用户多少时间间隔内，只能请求多少次。在代理层也可以基于ip做次数限制，限制单ip的请求数量。
• 直接跳转：假设秒杀已结束或秒杀队列已满，对后续的请求，直接跳转到秒杀结束页面。请求不再到达服务端。
• 请求排队：通过消息队列、内存排队等手段，对请求进行排队。类似EDA、Reactor。当队列满了以后，可拒绝后续请求。

服务端优化

上面的「请求排队」，可以做在web服务层，也可以在服务端处理，亦可以两处都处理。除了排队，服务端的优化的核心手段就是缓存，尽量减少到数据库的数据访问，将热点数据缓存起来。

更极致的优化可能还涉及到：

• 减少序列化：大家都知道Java序列化和反序列化都是比较耗时的操作，即使使用第三方的序列化工具，也是需要消耗时间的，尽量减少序列化操作，能减少这部分的时间消耗
• 不要使用框架：现在一般开发都会使用框架开发，例如SpringMVC。SpringMVC使用了前端控制器，还包括很多的Filter，拦截器等，额外的增加了请求时间。使用纯Servlet，能降低此部分的时间消耗。因为毕竟秒杀逻辑简单，用不用框架，开发效率影响不大。
• 使用字节流：即使用InputStream、OutputStream，不要使用Writer,Reader。与「减少序列化」类似，编解码也会消耗时间。

另外还有扣库存逻辑处理：

• 拍下减库存：用户抢到后即扣除库存，但是如果用户抢到了不付款，最后秒杀的商品可能实际并没有卖出去。
• 付款减库存：到用户付款后才去扣库存。这可能导致下单数量远超商品数量。导致的问题是，要么后付款的买家被提示付款失败。要么就是超卖。
• 预扣库存：用户抢到即扣除库存。规定时间内没有付款则取消订单，恢复库存。这个是常用手段

上面说的秒杀系统的一般设计思路。下面来看看我们是怎么钻漏洞的！

竞赛漏洞

由于竞赛规定，只能使用Java和Spring来处理，对其他队来说，这就导致了一个比较棘手的问题，IO优化。

Java支持两种IO，BIO和NIO。对于秒杀这种场景来说，肯定不能使用BIO。但是，如果使用Java原生NIO的话，需要处理很多问题，例如半包问题。以最终结果来看，选用原生NIO自己手写异步IO框架的，全都以失败告终。

那就只有另外一条路，宁可扣分，也要使用第三方框架，例如Netty。这就是赌，赌使用JavaNIO的队伍无法完成系统了。

而对我们队来说，我们原先的劣势---前端、一下子就变成了优势。因为前端有node啊（如果没有node，我们妥妥的弃赛了）。当时node刚火起来，node天生就是个异步IO框架，竞赛规定里，可没有对前端技术做技术限制！这个漏洞，我们怎么能不钻？！

公平？公平！

最终竞赛评比时，我发现一个问题，其他队伍很看重公平！！！即先到先得原则，优先到达的请求，优先排队下单。这就导致，在秒杀结束前或请求被处理前，都需要等待，直到服务器处理后才有返回。

这明显增加了服务端的压力，这也是导致他们的吞吐量限制在4000左右的原因。但不是根本原因。

根本原因是这样做就真的公平吗？！这就要看每个人对公平的理解了！我认为这世上「没有绝对的公平，只有相对的公平」！

你在秒杀系统里排队，保证先到先得，这就是公平吗？

• 如果一个买家是1M带宽，另一个买家是100M光纤，他们同时秒杀，你能保证公平吗？
• 如果你的服务器在北京，北京的买家是不是比广州的买家更容易秒杀到？你能保证公平吗？
• 如果一个买家是万年死宅，手速奇快；另一个买家手不太灵活。你能保证公平吗？

既然不能，我为什么要在服务端保证公平呢？！

我们的设计

秒杀就是拼个运气，只要不暗箱操作，那就是公平的。所以我们不保证先到达的请求就能先买到商品！客户哪知道他是不是先到的呢（虽然这样说，看起来不公平，但实际确实是这样）。所以我们放弃了所谓的公平。

我们使用了两个队列：

• 前端node队列
• 后端下单队列

大致请求流程如下：

• 假设商品数量为100，那可以设定node队列长度为1000，下单队列长度为100
• 秒杀开始后，node队列接收前端请求，先到先进。当队列满了以后，直接响应后面的请求，秒杀失败/结束。
• node队列中的数据批量传递给后端的下单队列，由消费线程从下单队列中获取请求进行处理
• 如果100个商品全部处理完成（下单后，规定时间内没有付款，取消订单，恢复库存），则秒杀结束
• 如果100个商品没有处理结束，继续从node队列获取下一批数据处理
• 如果node队列有空余后，后续的请求继续进入队列
• node队列中的请求设置超时，规定时间内没有得到处理，直接返回秒杀失败/结束

总结

人员、技术、考量点的不同都会影响架构设计。一个符合当前人员、技术以及适合考量点的架构，可能能得到意想不到的效果。