我写过很多亿级流量的文章，中间也讲过各种处理思路。在这里，我将这些想法与业务结合起来。第一种情况是秒杀。说到秒杀，很多人都会认为这是一个技术要求很高的事情，因为涉及到大量的访问（可能瞬间用户访问产品数千万次），以及保持数据的一致性（不是overselling），前者对性能要求极高，后者只是降低了性能。本文讲述了秒杀的设计思路，最后给出了秒杀设计的简单模型图。01秒杀场景生活中有很多秒杀场景，比如商家促销，比如一块钱抢茅台，50毛钱抢宝马（这里只是举个例子），如果一百万人来抢十瓶茅台，他们这个时候一定不能多卖，就是不能超过10个人抢到，一般最后时间会有一个倒计时按钮，30...29...28...3...2...1开始！之后，跃跃欲试的人们开始掠夺。这时候需要考虑以下几个问题：首先是如何让多个客户端的时间保持同步，也就是让大家看到时间是一致的，你不能显示3，我这里还是显示30。二是如何保证黄牛不被机器人抢走。三是如何保证后端服务器能够支撑这个巨大的流量。......02秒杀的解决思路有了上面的场景和提出的问题，我们来看看秒杀的解决方案的设计思路。我们的服务器是怎么处理这个百万TPS的呢？首先想到的是扩容。具体可以参考服务器扩容思路和问题分析，但这不现实，因为扩容需要很多很多的机器，TPS提升10000倍需要远远超过物理服务器10000倍的性能。另外，对于一个企业来说，为了这个促销活动购买服务器并不划算，而且平时闲置的机器肯定有很多。如果无法扩展，则意味着必须使用其他方法。如果所有的请求都访问一台物理机，肯定不行。不管百万数据怎么访问，分库分表都无济于事，因为每一条数据都是热点数据，所以应该使用分布式架构的思想。03秒杀的技术方案是分布式的，可以减轻服务器的压力。下面开始描述秒杀的设计思路。解决方案1很明显。要让百万用户同时打开网页抢货，就要用到CDN（内容分发网络，如果对这个概念不清楚，可以参考：全局负载均衡与CDN内容分发），CDN主要有两个作用，一个是把一些不会变化的静态资源放在离客户端比较近的边缘服务器上，这样当客户端请求数据的时候，可以直接从边缘服务器上获取，减少了对中央服务器的压力；另一方面是一方面可以将小服务部署到CDN节点上。这样，当前端页面来询问是否开始营业时，这个小服务不仅可以告诉前端是否开始营业，还可以统计有多少人在线。每个小服务每隔一段时间就会把当前在线等待闪杀的人数发回我们的数据中心，这样我们就知道全网有多少人在线了。假设我们知道大约有100万人在线等待抓取，那么，在我们即将开始的时候，数据中心会向部署在CDN节点上的每一个小服务传递一个概率值。这个概率值是CDN节点数量乘以中奖概率的权重，比如e，所以闪购开始的时候，这100万用户都在点击下单按钮。首先，他们在CDN上请求这些服务。这些小服务按照e的量把数据中心的用户放在后面，也就是把人数*e放过去，剩下的直接返回秒杀结束。方案二利用我们的分布式中限流、网关等知识，对请求进行层层过滤，减少最终请求连接数据库。首先，CDN用于在边缘服务器上分发静态资源。提出服务请求时，首先进行身份验证。鉴权主要是筛选机器人等非人工抢购。根据实践经验，认证可以筛选大量用户，比如是否登录。认证确认为真实有效用户后，通过负载均衡（详见LVS负载均衡理论与算法）总结），也就是LVS+Keepalived，将请求分配到不同的Nginx，通常是建立一个Nginx集群，然后通过网关集群，即使是这种方式，还是需要一些限流措施。如果此时还有很多请求压向数据库，势必难以为继，那么可以采取服务限流、服务降级等措施进行调峰处理。理论上，这里的流量并不高。如果还是很高，我们会把热数据放到缓存集群后面预热，同时设置定时任务。一方面要注意数据库和缓存的一致性，另一方面要关闭超时。支付订单在提交订单时交给任务队列，生成订单，修改数据库，做持久化工作。架构图：这就是整个《秒杀》的技术细节，是不是有点不可思议？与这种秒杀业务类似的是12306抢票，同样是瞬间流量很高，但是上述架构不适合，因为12306不知道用户要买哪张火车票。在不知道这些信息的情况下，过滤用户是非常困难的，用户需要在购票前做大量的查询操作，然后在查询中选择自己的票。这意味着无法从一开始就过滤用户。12306最好的处理方式不是一次性全部放票，而是分批次放票，不至于集中在一个时间点抢票，从而分散人从彼此。可以减少一些并发。另外，12306最好采用预售的方式，这样大家可以先把自己的购票信息输入系统。系统实际上不发车票，而是收集大家的需求，然后统筹安排，该加就加车，该加就加车，让大家去。如果不行，就抽签。04总结我们可以看到，解决秒杀的具体业务场景，可以利用CDN的边缘节点来承载流量，然后过滤用户请求（有限用户请求）来保护数据中心系统，这样整个秒杀就可以进展顺利。也可以像方案二那样逐层过滤请求，这个业务场景是不是和双11一样？如果你想像双11一样尽可能多的卖产品，那就不像秒杀了。这是为了尽可能多地接到订单，但不要超过库存。还有大量的银行付款，以及各大仓库的库存查询和调拨。这些操作非常缓慢。为了保证一致性，还需要能够承受像双十一这样的大规模并发访问，那么应该怎么做呢？使用秒杀这样的方案基本上是不科学的。这个时候就需要认真的去做高并发的架构和测试了。需要调整各个系统的性能，精心规划性能，做好分布式弹性设计。不断做性能测试，找出整个架构的系统瓶颈，然后继续横向扩展，解决大规模并发。有时，我们总是考虑数据中心解决方案。其实有时候我们需要换个思路。或许，在数据中心解决不一定是最好的方式，在边缘解决可能会更好。尤其是一些具有地域特色的业务，比如外卖、共享单车、打车等。事实上，将一些简单的业务逻辑放在边缘，不仅可以比放在数据中心有更好的性能，而且成本更低。我觉得随着请求量的增加，数据量的增加，数据中心有点瓶颈了，需要边缘节点来帮忙。而且，这种边缘化解决方案的趋势将变得越来越有利。本文作者：等不及口琴原文链接：https://www.cnblogs.com/Courage129/p/14493931.html会议推荐：随着云原生技术的广泛应用和业务的不断丰富要求，企业更关注系统架构，要求越来越高。如何根据不同的业务特点进行系统架构设计和技术选择，成为架构师最关心的问题。在本次WOT全球技术创新大会的“架构设计与架构实践”主题中，我们邀请了来自不同公司的数字化技术专家，与大家分享架构设计与实现的最佳实践，希望能为大家提供一些不一样的思路。想法和程序参考。☆WOT全球科技创新大会2022☆2022/4/9-4/10WOT全球科技创新大会2022是中国科技社区为科技从业者精心打造的WOT2.0升级版。大会议题涉及人工智能、数据安全、音视频、大数据、架构、开源、云原生、前端、研发管理、算法、金融科技、微服务等多个方向。本届WOT大会预计参会人数1500人，合作企业100余家，专家分享60人。大会不仅邀请了腾讯、阿里、百度、58、大搜车等一线互联网公司的技术专家，为大家分享独家技术干货。还特邀多位国内顶尖技术科学家，对国内重点科技创新战略及相关政策进行了详细解读。
