你好，我是陈浩，我名做耳朵耗子。
这节课呢我们要讲的内容是秒杀一说起秒杀呢，大家都觉得这个事儿很有技术含量，其实呢并不是这个样子的。
秒杀这种互联网的交易方式呢，其实并没有我们想象中的那么复杂。
我们现在系统的看一下秒杀是怎么做的。
秒杀呢其实是商家为了促销使用非常低的价格来销售商品。
比如说一元卖iphone一百台，于是呢就来了一百万人来抢购。
我们把技术挑战先放在一边，先从用户或者产品的角度来看一下，秒杀的流程是什么样的。
呃，首先呢你需要一个秒杀的learning page,在这个秒杀页上呢有一个倒计时按钮。
。那一旦这个倒计时的时间到了按钮呢就被点亮，让你可以点击按钮来下单。
那一般来说在下单的时候呢，需要你填写一个校验码啊，以防止是机器来抢。
那从技术上来说呢，这个倒计时按钮上的时间和按钮可以被点击的时间是需要后台服务器来做校准的那这个就意味着前端页面啊要不断的向后端发请求开没开始开没开始，而且每次询问的时候呢，后端都会给前端一个时间，以校准前端的时间。
那一旦后端服务器表示OK可以开始，那后端服务呢就会返回一个UL.然后这个UIL呢会被安置在那个按钮上，然后呢就可以点击了。
点击之后，如果抢到了库存，就进入支付页面。
那如果没有呢，则返回秒杀已结束。
那这个不断轮询的过程，就好像是大家在等着抢。
你想一想有一百万人来不停的询问，有没有开始了这个事儿，那估计后端啊也扛不住。
那接下来呢我们需要看一下秒杀的技术挑战。
面对上面我们要解决的技术问题呢，我们技术上的挑战就是怎么应对这一百万人同时下单，请求一百万的同时并发会导致我们的网站瞬间就崩溃了。
那一方面是一百万人，同时请求啊，我们的网络带宽是不够的那另一方面理论上来说啊，要扛一百万的TPS需要非常多的机器。
但最恐怖的是所有的请求啊都会集中在同一条数据库记录上。
无论是怎么分库分表，还使用分布式数据库啊，都无济于事。
因为你面对的是单条的热点数据，这几乎是一件无法解决的技术问题。
很明显啊，要让一百万的用户能够在同一时间打开一个页面。
那这个时候呢我们就需要用到CDN了，数据中心啊是肯定扛不住的。
所以呢我们要引入CDN,在CDN上面呢，这一百万个用户就会被几十个，甚至上百个CDN的边缘节点给分担了，于是就能够扛得住了。
然后呢我们还需要在这些CDN节点上做一点小文章。
那一方面呢，我们需要把小服务部署到CDN节点上去。
那这样当前端页面来问开没开始的时候，这个小服务除了告诉前端开没开始之外，它还可以统计一下有多少人在线。
每隔一段时间啊，每个小服务都会把当前在线等待秒杀的人数回传给我们的数据中心。
于是呢我们就知道全网总共在线的人数有多少。
那假设我们知道大约有一百万的人在线等着抢。
那么在我们快要开始的时候，由数据中心向各个部署在CDN节点上的小服务上传递一个概率值，比如说是百分之零点零二。
于是当秒杀开始的时候呢，这一百万个用户都在点下单按钮。
那首先他们请求到的是CEN上的这些服务。
那这些小付按照百分之零点零二的量，把用户放到后面的数据中心啊，也就是一万个人放过去两个。
那剩下的九千九百九十八个呢都直接返回秒杀已结束。
于是呢一百万个用户被放过了百分之零点零二个用户啊，也就是两百个左右。
而这两百个人在数据中心那儿抢一百个iphone啊，也就是两百KPS.那这个并发量怎么都应该能扛住了。
那这个就是整个秒杀的技术细节，是不是有点不敢相信呢？那说到这里呢，我相信你一定会问我幺二三零六和奥运会抢票的问题。
我觉得二零零八年奥运会抢票把服务器抢挂了，那其实呢是可以使用秒杀这个解决方案的。
但是幺二三零六则不行，因为他们完全不知道用户上来是要买哪张火车票的那不知道这个信息很不好过滤用户。
而且呢用户在买票之前啊，需要有很多的查询操作，然后在查询中啊选择自己的车票。
对此呢幺二三零六最好的应对方式，一个是不要一次把所有的票都放出来啊，而是分批的在不同的时间段把票放出来。
那这样就可以让人们不要集中在一个时间点来抢票，所以说人肉分流就可以降低一点并发度。
那另外啊我一直觉得幺二三零六最好啊是用预售的方式，让大家呢把自己的购票先输入到系统中。
系统呢并不真正放票，而是把大家的需求都收集好，然后做整体的统筹安排，该增加车次的增加车次，该加车厢呢加车厢，那这样呢可以确保大家都能走。
那实在不行啊，那就抽签了。
我们可以看到解决秒杀这种特定的业务场景，可以使用CDN的边缘节点来扛流量，然后呢过滤用户请求来保护数据中心的系统。
那这样呢才能让整个秒杀得以顺利的进行。
但是呢如果我们像双十一那样想尽可能的多卖出商品，那就不像秒杀了。
这是要尽可能多的收订单，但呢又不能超过库存。
那其中呢还有大量的银行支付，还有各大仓库的库存查询和分配。
那这些啊都是非常慢的操作。
那为了保证一致性，还要能扛得住双十一这样的大规模并发访问，那应该怎么做呢？使用秒杀这样的解决方案，基本上来说就不太科学了。
那这个时候啊就需要认认真真的做高并发的架构和测试了，需要各个系统把自己的性能调整上去，还有小心的做性能规划，更是要把分布式的弹力设计做好。
那最后呢是要不停的做性能测试啊，找到整个架构的系统瓶颈，然后呢不断的做水平扩展，以解决大规模的并发。
但是从另一方面来说，像我们用边缘节点来解决秒杀这样的场景的玩法，是否也有一定的普适性呢？在这里呢我想说啊一定是有的。
有些时候呢我们总是在想数据中心的解决方案。
那其实我们有时候啊也需要换一换思路。
也许在数据中心解决呢并不一定是最好的方式放在边缘来解决啊，可能会更好一些。
尤其是针对一些有地域特征的业务，比如像外卖啊、共享单车，还有打车这样的业务。
那其实把一些简单的业务逻辑放在边缘比放在数据中心，不但能够有更好的性能，还有更便宜的成本。
我觉得啊随着请求量越来越大，数据呢也越来越多，数据中心啊是有点到瓶颈了，需要边缘节点来帮忙了。
而且这个边缘化解决方案的趋势啊也会越来越有优势。
那在这里呢我先暂且不说啊，因为这是我的创业方向，我会在下一节课中啊，也是本系列的最后一篇文章向你介绍一下边缘计算。
还有啊我想用边缘计算干些什么事儿。
好了，我们来总结一下今天分享的主要内容。
首先呢我介绍了秒杀，先是分析了他的业务流程，并列举了他所面临的技术挑战。
那随后呢我介绍了他的解决方案。
那接着我又分析了相关的奥运会和幺二三零六抢票问题，还有双十一购物节的问题，他们各自有不同的解决思路。
那其中双十一啊要求我们必须认认真真的用高并发架构来应对。
那最后呢从秒杀解决方案中的CDN边缘节点计算啊，我引出了普世的边缘节点计算。
在下节课啊，我们会详细的讲述边缘计算，希望能对你有帮助。
也欢迎你分享一下你参与过秒杀系统的构建吗？那双十一呢解决方案是怎样的呢？文末呢我给出了分布式系统设计模式系列文章的目录啊，希望你能在这个列表里啊找到自己感兴趣的内容。
扫一扫
74
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
