图片来自Pexels。前者对性能要求极高，后者只是降低了性能。这篇文章讲了秒杀的设计思路，最后给出了一个秒杀设计的简单模型图。闪杀的场景生活中闪杀的场景有很多，比如商家促销，比如一元抢茅台，五十块抢宝马（这里只是举个例子）。如果一百万人来抢十瓶茅台，这个时候一定不能多卖，也就是抢不到10个人以上。一般最后时间会有一个倒计时按钮，30、29、28、3、2、1、GO！之后，跃跃欲试的人们开始抢夺。这时候需要考虑以下几个问题：首先是如何让多个客户端的时间保持同步，也就是让大家看到时间是一致的。你不能显示3，我还是显示30。二是如何保证没有黄牛被机器人抢走。三是如何保证后端服务器能够支撑这个巨大的流量。......秒杀方案思路有了上面的场景和提出的问题，我们来看看秒杀方案的设计思路。我们的服务器是怎么处理这个百万TPS的呢？首先想到的就是扩容，但是这是不现实的，因为扩容需要很多很多的机器，而TPS提升10000倍，需要的性能远远超过物理服务器的10000倍。另外，对于商家来说，为了这次促销活动购买服务器并不划算，而且很多机器平时肯定是闲置的。不能扩展，就是用其他方法。如果所有的请求都访问一台物理机，肯定不行。百万数据访问再怎么访问，分库分表也于事无补，因为每一条数据都是热点数据，所以应该使用分布式架构的思想。秒杀的技术方案是分布式的，可以减轻服务器的压力。下面开始描述秒杀的设计思路。方案一很明显，要让一百万用户同时打开抓货网页，就必须要用到CDN。CDN主要有两个作用：一方面是把一些不会变化的静态资源放在离客户端较近的边缘服务器上。这样，当客户端请求数据时，可以直接从边缘服务器获取，减轻中心服务器的压力。另一方面可以把小服务部署到CDN节点，这样当前端页面来询问开通是否开始时，这个小服务不仅可以告诉前端开通是否开始，还要统计有多少人在线。每个小服务每隔一段时间就会把当前在线等待闪杀的人数发回我们的数据中心，这样我们就知道全网有多少人在线了。假设我们知道大约有100万人在线等着抢，那么，当我们要开始的时候，数据中心会向每个部署在CDN节点上的小服务传递一个概率值。这个概率值是CDN节点人数的权重乘以获胜的概率，例如e。因此，当秒杀开始时，这100万用户正在点击订购按钮。首先，他们在CDN上请求这些服务。这些小服务根据e的多少，也就是过去的人数*e，把用户放在后面的数据中心，剩下的直接返回秒杀结束。方案二利用我们对分布式中限流和网关的了解，对请求进行层层过滤，减少最终请求连接数据库。首先，CDN用于在边缘服务器上分发静态资源。提出服务请求时，首先进行身份验证。鉴权主要是筛选机器人等非人工抢购。根据实际经验，认证可以筛选大量的用户，比如是否登录。认证确定为真实有效用户后，通过负载均衡，即LVS+Keepalived，将请求分发到不同的Nginx。一般会建立一个Nginx集群，然后通过gateway集群。即便如此，也必须增加一些限流措施。如果此时还有很多请求压向数据库，势必难以为继，那么可以采取限流、降级等措施进行调峰处理。理论上，这里的流量并不高。如果还高，后面会把热数据放到缓存集群中预热，同时设置一个定时任务。一方面注意数据库和缓存的一致性，另一方面关闭超时未支付的订单。订单提交时，会交给任务队列生成订单，修改数据库，做好持久化工作。架构图如下：这就是整个“秒杀”的技术细节，是不是有点不可思议？和这个秒杀业务类似的是12306抢票，也是瞬间大流量，但是上面的架构不适合，因为12306不知道用户要买哪张火车票。在不知道这些信息的情况下，过滤用户是非常困难的，用户需要在购票前做大量的查询操作，然后在查询中选择自己的票。这意味着无法从一开始就过滤用户。12306最好的处理方式不是一次放完所有票，而是分批次放出不同时间段的票。这样人就不会集中在一个时间点抢票，实现人的分离，可以降低一些并发度。另外，12306最好采用预售的方式，这样大家可以先把自己的购票信息输入系统。系统实际上不发车票，而是收集大家的需求，然后统筹安排，该加就加车，该加就加车，让大家去。如果不行，就抽签。综上所述，我们可以看到，解决秒杀的具体业务场景，可以利用CDN的边缘节点来承载流量，然后过滤用户请求（限制用户请求）来保护数据中心系统，让整个秒杀可以顺利进行。也可以像方案二那样逐层过滤请求，这个业务场景和双十一一样吗？如果你想像双十一一样尽可能多的卖产品，那就不像秒杀了。这是为了尽可能多地接到订单，但不要超过库存。还有大量的银行付款，以及各大仓库的库存查询和调拨。这些操作非常缓慢。为了保证一致性，还需要能够承受像双11这样的大规模并发访问。那么，我们应该怎么做呢？使用秒杀这样的方案基本上是不科学的。这个时候就需要认真的去做高并发的架构和测试了。每个系统都需要调整自身的性能，精心规划性能，做好分布式弹性设计。最后还需要不断进行性能测试，找到整个架构的系统瓶颈，然后不断横向扩展，解决大规模并发。有时，我们总是考虑数据中心解决方案。其实有时候我们需要换个思路。或许，在数据中心解决不一定是最好的方式，在边缘解决可能会更好。尤其是一些具有地域特色的业务，比如外卖、共享单车、打车等。事实上，将一些简单的业务逻辑放在边缘，不仅可以比放在数据中心有更好的性能，而且成本更低。我觉得随着请求量的增加，数据量的增加，数据中心有点瓶颈了，需要边缘节点来帮忙。而且，这种边缘化解决方案的趋势将变得越来越有利。作者：等不及口琴编辑：陶家龙来源：cnblogs.com/Courage129/p/14493931.html
