【另类见解】秒杀并非高不可攀

“一提到秒杀很简单这个话题，我知道要被别人鄙视了：你不懂高并发... 这年头开头不画个思维导图都觉得掉价

谈到秒杀，网络上不少于几千片文章，但是大多大同小异。如果你的微信当中关注了几个编程技术类的公众号，我敢说，每个公众号几乎都发过秒杀的文章

秒杀这种场景在流量这个维度很有独特性，大起大落的流量冲击对系统是个考验。为什么这么说呢？大的流量或者说高并发请求，考验的不仅仅是数据库的最大承受压力，而且对于带宽也有很大的考验，入口流量之后就是对整个系统的承受能力的考验。

其实我觉得这里大多数人有一个误解：秒杀对整个系统的考验，最终会落到数据库上。正是这个误解，导致了大多数人会对DB优化花费很大的精力。

现实的世界存在矛盾，只要找到矛盾就能解决问题，对应到编程也一样。

秒杀之所以被神化，是因为流量大，但是很多系统最后崩塌的却是数据库，很少有团队因为应用系统崩溃而导致秒杀失败。因为对于整个系统来说，数据库是数据最后的持久化，是存在状态的，而应用系统一般都是无状态的，都是可以横向扩展的。

其实说到底，流量还是要削峰或者分流，我想如果把流量削到数据库的可承受范围之内，秒杀可能和其他业务场景无异。

过多的中间件

说出来你们肯定见过，网络一大堆秒杀的解决方案，又是XXMQ，又是XX缓存，又是XX负载均衡，又是XX中间件。虽然架构图很完美，但是落地呢？

落地是有难度的，而且还有很大风险。难道各种中间件不用维护吗？中间件不会出故障吗？每个中间件不用做高可用吗？这么多中间件搭配起来，运维成本是很高的，最主要的是出问题排查问题的成本会很高。

我们需要的是架构师，不是框架师。把复杂问题用简单的解决方案解决，才不会给自己挖坑，我一直是这么认为。

那中间件需要吗？肯定是需要的，那么多成熟的东西真的能解决你很多问题，但是前提是正确的用。比如Redis，做缓存用途很正确，但是你把它当做高速数据库我就不认同了，虽然它可以持久化，但是大并发的情况下，Redis做数据库是不合适的。

吃掉所有流量

秒杀业务具体能到多大流量谁也不能确定，虽然可以根据以往经验预估，但是往往还是会超出想象。要想把这些流量全部流入服务器进行处理，需要付出很多资源。最坏的情况是，把流量全部吃掉之后，还要吐出90%，这就让人恼火了。

所以，能不能只吃能够吃饱的流量呢？比如说：库存有1000件商品，如果我们只放进来1000个请求（虽然很牵强），那整个系统是不是很容易构建。就像吃饭一样：本来一碗米饭就能吃饱，非要吃下10碗，然后吐出9碗吗？

SO，是不是只要在系统边缘加一个限流就ok了？值得思考

客户端UI

无论业务怎么样，客户端用户体验总要给人一种还有希望的感觉。

其实秒杀这种场景是最能发挥忽悠人才能的了，你前面有多少人排队，天王老子也别想知道。就算真的要给用户反馈前面还有多少人，其实完全可以返回一个不太离谱的随机数，反正用户又不会电话投诉。

多说一句，甚至把限流算法放到客户端都行，反正不懂行的又看不懂代码，这种骚操作我确实见过。

如果非要返回真实的排队人数的话，可以引入一个线程安全的中心化队列即可，比如用神器Redis，每成功穿过限流窗口一个请求，就把对应的UserId插入这个队列，这个队列理论上不会太大，因为有程序一直在消费。

静态资源

所谓的静态资源就是指那些不会变动或者很少变动的资源，比如商品的图片就属于这种。在秒杀这种场景下，静态资源的访问一定要分离出业务服务器，最好的解决方案是利用CDN来加速。

CDN是个好东西，谁用谁知道。不但可以降低自己服务器的压力，而且还可以给全国各地的用户请求加速，具体原理咱们之后有机会可以唠唠。如果技术允许的情况下，甚至一些边缘计算的能力都可以放置在CDN。

写在最后

如果不是阿里，腾讯这种量级的公司，一般中小公司搞秒杀活动并不是想象中那么恐怖。大家可以放平心态。做技术一定不要乱了阵脚，技术的选择固然重要，但是更重要的是有全局掌控的能力，哪个环节最容易出问题，要做好全面监控，出了问题第一时间能解决问题才是后期最重要的。