北京做网站建设比较好的公司,做网站一般使用什么算法,大连建设工程设计院有限公司网站,安 网站建设前言 很多小伙伴反馈说#xff0c;高并发专题学了那么久#xff0c;但是#xff0c;在真正做项目时#xff0c;仍然不知道如何下手处理高并发业务场景#xff01;甚至很多小伙伴仍然停留在只是简单的提供接口#xff08;CRUD#xff09;阶段#xff0c;不知道学习的并发…
前言 很多小伙伴反馈说高并发专题学了那么久但是在真正做项目时仍然不知道如何下手处理高并发业务场景甚至很多小伙伴仍然停留在只是简单的提供接口CRUD阶段不知道学习的并发知识如何运用到实际项目中就更别提如何构建高并发系统了 究竟什么样的系统算是高并发系统今天我们就一起解密高并发业务场景下典型的秒杀系统的架构结合高并发专题下的其他文章学以致用。
电商系统架构
在电商领域存在着典型的秒杀业务场景那何谓秒杀场景呢。简单的来说就是一件商品的购买人数远远大于这件商品的库存而且这件商品在很短的时间内就会被抢购一空。 比如每年的618、双11大促小米新品促销等业务场景就是典型的秒杀业务场景。
我们可以将电商系统的架构简化成下图所示。 由图所示我们可以简单的将电商系统的核心层分为负载均衡层、应用层和持久层。接下来我们就预估下每一层的并发量。 假如负载均衡层使用的是高性能的Nginx则我们可以预估Nginx最大的并发度为10W这里是以万为单位。 假设应用层我们使用的是Tomcat而Tomcat的最大并发度可以预估为800左右这里是以百为单位。 假设持久层的缓存使用的是Redis数据库使用的是MySQLMySQL的最大并发度可以预估为1000左右以千为单位。Redis的最大并发度可以预估为5W左右以万为单位。
所以负载均衡层、应用层和持久层各自的并发度是不同的那么为了提升系统的总体并发度和缓存我们通常可以采取哪些方案呢
1系统扩容
系统扩容包括垂直扩容和水平扩容增加设备和机器配置绝大多数的场景有效。
2缓存
本地缓存或者集中式缓存减少网络IO基于内存读取数据。大部分场景有效。
3读写分离
采用读写分离分而治之增加机器的并行处理能力。
秒杀系统的特点
对于秒杀系统来说我们可以从业务和技术两个角度来阐述其自身存在的一些特点。
秒杀系统的业务特点
这里我们可以使用12306网站来举例每年春运时12306网站的访问量是非常大的但是网站平时的访问量却是比较平缓的也就是说每年春运时节12306网站的访问量会出现瞬时突增的现象。
再比如小米秒杀系统在上午10点开售商品10点前的访问量比较平缓10点时同样会出现并发量瞬时突增的现象。
所以秒杀系统的流量和并发量我们可以使用下图来表示。 由图可以看出秒杀系统的并发量存在瞬时凸峰的特点也叫做流量突刺现象。
我们可以将秒杀系统的特点总结如下。 1限时、限量、限价
在规定的时间内进行秒杀活动中商品的数量有限商品的价格会远远低于原来的价格也就是说在秒杀活动中商品会以远远低于原来的价格出售。
例如秒杀活动的时间仅限于某天上午10点到10点半商品数量只有10万件售完为止而且商品的价格非常低例如1元购等业务场景。
限时、限量和限价可以单独存在也可以组合存在。
2活动预热
需要提前配置活动活动还未开始时用户可以查看活动的相关信息秒杀活动开始前对活动进行大力宣传。
3持续时间短
购买的人数数量庞大商品会迅速售完。
在系统流量呈现上就会出现一个突刺现象此时的并发访问量是非常高的大部分秒杀场景下商品会在极短的时间内售完。
秒杀系统的技术特点
我们可以将秒杀系统的技术特点总结如下。 1瞬时并发量非常高
大量用户会在同一时间抢购商品瞬间并发峰值非常高。
2读多写少
系统中商品页的访问量巨大商品的可购买数量非常少库存的查询访问数量远远大于商品的购买数量。
在商品页中往往会加入一些限流措施例如早期的秒杀系统商品页会加入验证码来平滑前端对系统的访问流量近期的秒杀系统商品详情页会在用户打开页面时提示用户登录系统。这都是对系统的访问进行限流的一些措施。
3流程简单
秒杀系统的业务流程一般比较简单总体上来说秒杀系统的业务流程可以概括为下单减库存。
针对这种短时间内大流量的系统来说就不太适合使用系统扩容了因为即使系统扩容了也就是在很短的时间内会使用到扩容后的系统大部分时间内系统无需扩容即可正常访问。 那么我们可以采取哪些方案来提升系统的秒杀性能呢
秒杀系统方案
针对秒杀系统的特点我们可以采取如下的措施来提升系统的性能。 1异步解耦
将整体流程进行拆解核心流程通过队列方式进行控制。
2限流防刷
控制网站整体流量提高请求的门槛避免系统资源耗尽。
3资源控制
将整体流程中的资源调度进行控制扬长避短。
由于应用层能够承载的并发量比缓存的并发量少很多。所以在高并发系统中我们可以直接使用OpenResty由负载均衡层访问缓存避免了调用应用层的性能损耗。大家可以到https://openresty.org/cn/来了解有关OpenResty更多的知识。同时由于秒杀系统中商品数量比较少我们也可以使用动态渲染技术CDN技术来加速网站的访问性能。
如果在秒杀活动开始时并发量太高时我们可以将用户的请求放入队列中进行处理并为用户弹出排队页面。 注图片来自魅族
秒杀系统时序图
网上很多的秒杀系统和对秒杀系统的解决方案并不是真正的秒杀系统他们采用的只是同步处理请求的方案一旦并发量真的上来了他们所谓的秒杀系统的性能会急剧下降。我们先来看一下秒杀系统在同步下单时的时序图。
同步下单流程 1.用户发起秒杀请求
在同步下单流程中首先用户发起秒杀请求。商城服务需要依次执行如下流程来处理秒杀请求的业务。
1识别验证码是否正确
商城服务判断用户发起秒杀请求时提交的验证码是否正确。
2判断活动是否已经结束
验证当前秒杀活动是否已经结束。
3验证访问请求是否处于黑名单
在电商领域中存在着很多的恶意竞争也就是说其他商家可能会通过不正当手段来恶意请求秒杀系统占用系统大量的带宽和其他系统资源。此时就需要使用风控系统等实现黑名单机制。为了简单也可以使用拦截器统计访问频次实现黑名单机制。
4验证真实库存是否足够
系统需要验证商品的真实库存是否足够是否能够支持本次秒杀活动的商品库存量。
5扣减缓存中的库存
在秒杀业务中往往会将商品库存等信息存放在缓存中此时还需要验证秒杀活动使用的商品库存是否足够并且需要扣减秒杀活动的商品库存数量。
6计算秒杀的价格
由于在秒杀活动中商品的秒杀价格和商品的真实价格存在差异所以需要计算商品的秒杀价格。
注意如果在秒杀场景中系统涉及的业务更加复杂的话会涉及更多的业务操作这里我只是列举出一些常见的业务操作。
2.提交订单
1订单入口
将用户提交的订单信息保存到数据库中。
2扣减真实库存
订单入库后需要在商品的真实库存中将本次成功下单的商品数量扣除。
如果我们使用上述流程开发了一个秒杀系统当用户发起秒杀请求时由于系统每个业务流程都是串行执行的整体上系统的性能不会太高当并发量太高时我们会为用户弹出下面的排队页面来提示用户进行等待。 注图片来自魅族
此时的排队时间可能是15秒也可能是30秒甚至是更长时间。这就存在一个问题在用户发起秒杀请求到服务器返回结果的这段时间内客户端和服务器之间的连接不会被释放这就会占大量占用服务器的资源。
网上很多介绍如何实现秒杀系统的文章都是采用的这种方式那么这种方式能做秒杀系统吗答案是可以做但是这种方式支撑的并发量并不是太高。此时有些网友可能会问我们公司就是这样做的秒杀系统啊上线后一直在用没啥问题啊我想说的是使用同步下单方式确实可以做秒杀系统但是同步下单的性能不会太高。之所以你们公司采用同步下单的方式做秒杀系统没出现大的问题那是因为你们的秒杀系统的并发量没达到一定的量级也就是说你们的秒杀系统的并发量其实并不高。
所以很多所谓的秒杀系统存在着秒杀的业务但是称不上真正的秒杀系统原因就在于他们使用的是同步的下单流程限制了系统的并发流量。之所以上线后没出现太大的问题是因为系统的并发量不高不足以压死整个系统。
如果12306、淘宝、天猫、京东、小米等大型商城的秒杀系统是这么玩的话那么他们的系统迟早会被玩死他们的系统工程师不被开除才怪所以在秒杀系统中这种同步处理下单的业务流程的方案是不可取的。
以上就是同步下单的整个流程操作如果下单流程更加复杂的话就会涉及到更多的业务操作。
异步下单流程
既然同步下单流程的秒杀系统称不上真正的秒杀系统那我们就需要采用异步的下单流程了。异步的下单流程不会限制系统的高并发流量。 1.用户发起秒杀请求
用户发起秒杀请求后商城服务会经过如下业务流程。
1检测验证码是否正确
用户发起秒杀请求时会将验证码一同发送过来系统会检验验证码是否有效并且是否正确。
2是否限流
系统会对用户的请求进行是否限流的判断这里我们可以通过判断消息队列的长度来进行判断。因为我们将用户的请求放在了消息队列中消息队列中堆积的是用户的请求我们可以根据当前消息队列中存在的待处理的请求数量来判断是否需要对用户的请求进行限流处理。
例如在秒杀活动中我们出售1000件商品此时在消息队列中存在1000个请求如果后续仍然有用户发起秒杀请求则后续的请求我们可以不再处理直接向用户返回商品已售完的提示。 所以使用限流后我们可以更快的处理用户的请求和释放连接的资源。
3发送MQ
用户的秒杀请求通过前面的验证后我们就可以将用户的请求参数等信息发送到MQ中进行异步处理同时向用户响应结果信息。在商城服务中会有专门的异步任务处理模块来消费消息队列中的请求并处理后续的异步流程。
在用户发起秒杀请求时异步下单流程比同步下单流程处理的业务操作更少它将后续的操作通过MQ发送给异步处理模块进行处理并迅速向用户返回响应结果释放请求连接。
2.异步处理
我们可以将下单流程的如下操作进行异步处理。
1判断活动是否已经结束
2判断本次请求是否处于系统黑名单为了防止电商领域同行的恶意竞争可以为系统增加黑名单机制将恶意的请求放入系统的黑名单中。可以使用拦截器统计访问频次来实现。
3扣减缓存中的秒杀商品的库存数量。
4生成秒杀Token这个Token是绑定当前用户和当前秒杀活动的只有生成了秒杀Token的请求才有资格进行秒杀活动。
这里我们引入了异步处理机制在异步处理中系统使用多少资源分配多少线程来处理相应的任务是可以进行控制的。
3.短轮询查询秒杀结果
这里可以采取客户端短轮询查询是否获得秒杀资格的方案。例如客户端可以每隔3秒钟轮询请求服务器查询是否获得秒杀资格这里我们在服务器的处理就是判断当前用户是否存在秒杀Token如果服务器为当前用户生成了秒杀Token则当前用户存在秒杀资格。否则继续轮询查询直到超时或者服务器返回商品已售完或者无秒杀资格等信息为止。
采用短轮询查询秒杀结果时在页面上我们同样可以提示用户排队处理中但是此时客户端会每隔几秒轮询服务器查询秒杀资格的状态相比于同步下单流程来说无需长时间占用请求连接。
此时可能会有网友会问采用短轮询查询的方式会不会存在直到超时也查询不到是否具有秒杀资格的状态呢答案是有可能 这里我们试想一下秒杀的真实场景商家参加秒杀活动本质上不是为了赚钱而是提升商品的销量和商家的知名度吸引更多的用户来买自己的商品。所以我们不必保证用户能够100%的查询到是否具有秒杀资格的状态。
4.秒杀结算
1验证下单Token
客户端提交秒杀结算时会将秒杀Token一同提交到服务器商城服务会验证当前的秒杀Token是否有效。
2加入秒杀购物车
商城服务在验证秒杀Token合法并有效后会将用户秒杀的商品添加到秒杀购物车。
5.提交订单
1订单入库
将用户提交的订单信息保存到数据库中。
2删除Token
秒杀商品订单入库成功后删除秒杀Token。
这里大家可以思考一个问题我们为什么只在异步下单流程的粉色部分采用异步处理而没有在其他部分采取异步削峰和填谷的措施呢
这是因为在异步下单流程的设计中无论是在产品设计上还是在接口设计上我们在用户发起秒杀请求阶段对用户的请求进行了限流操作可以说系统的限流操作是非常前置的。在用户发起秒杀请求时进行了限流系统的高峰流量已经被平滑解决了再往后走其实系统的并发量和系统流量并不是非常高了。
所以网上很多的文章和帖子中在介绍秒杀系统时说是在下单时使用异步削峰来进行一些限流操作那都是在扯淡 因为下单操作在整个秒杀系统的流程中属于比较靠后的操作了限流操作一定要前置处理在秒杀业务后面的流程中做限流操作是没啥卵用的。
高并发“黑科技”与致胜奇招
假设在秒杀系统中我们使用Redis实现缓存假设Redis的读写并发量在5万左右。我们的商城秒杀业务需要支持的并发量在100万左右。如果这100万的并发全部打入Redis中Redis很可能就会挂掉那么我们如何解决这个问题呢接下来我们就一起来探讨这个问题。 在高并发的秒杀系统中如果采用Redis缓存数据则Redis缓存的并发处理能力是关键因为很多的前缀操作都需要访问Redis。而异步削峰只是基本的操作关键还是要保证Redis的并发处理能力。 解决这个问题的关键思想就是分而治之将商品库存分开放。
暗度陈仓
我们在Redis中存储秒杀商品的库存数量时可以将秒杀商品的库存进行“分割”存储来提升Redis的读写并发量。
例如原来的秒杀商品的id为10001库存为1000件在Redis中的存储为(10001, 1000)我们将原有的库存分割为5份则每份的库存为200件此时我们在Redia中存储的信息为(10001_0, 200)(10001_1, 200)(10001_2, 200)(10001_3, 200)(10001_4, 200)。 此时我们将库存进行分割后每个分割后的库存使用商品id加上一个数字标识来存储这样在对存储商品库存的每个Key进行Hash运算时得出的Hash结果是不同的这就说明存储商品库存的Key有很大概率不在Redis的同一个槽位中这就能够提升Redis处理请求的性能和并发量。
分割库存后我们还需要在Redis中存储一份商品id和分割库存后的Key的映射关系此时映射关系的Key为商品的id也就是10001Value为分割库存后存储库存信息的Key也就是10001_010001_110001_210001_310001_4。在Redis中我们可以使用List来存储这些值。
在真正处理库存信息时我们可以先从Redis中查询出秒杀商品对应的分割库存后的所有Key同时使用AtomicLong来记录当前的请求数量使用请求数量对从Redia中查询出的秒杀商品对应的分割库存后的所有Key的长度进行求模运算得出的结果为01234。再在前面拼接上商品id就可以得出真正的库存缓存的Key。此时就可以根据这个Key直接到Redis中获取相应的库存信息。
移花接木
在高并发业务场景中我们可以直接使用Lua脚本库OpenResty从负载均衡层直接访问缓存。
这里我们思考一个场景如果在秒杀业务场景中秒杀的商品被瞬间抢购一空。此时用户再发起秒杀请求时如果系统由负载均衡层请求应用层的各个服务再由应用层的各个服务访问缓存和数据库其实本质上已经没有任何意义了因为商品已经卖完了再通过系统的应用层进行层层校验已经没有太多意义了而应用层的并发访问量是以百为单位的这又在一定程度上会降低系统的并发度。
为了解决这个问题此时我们可以在系统的负载均衡层取出用户发送请求时携带的用户id商品id和秒杀活动id等信息直接通过Lua脚本等技术来访问缓存中的库存信息。如果秒杀商品的库存小于或者等于0则直接返回用户商品已售完的提示信息而不用再经过应用层的层层校验了。 针对这个架构我们可以参见本文中的电商系统的架构图正文开始的第一张图。
写在最后 如果觉得文章对你有点帮助请微信搜索并关注「 冰河技术 」微信公众号跟冰河学习高并发编程技术。 最后附上并发编程需要掌握的核心技能知识图祝大家在学习并发编程时少走弯路。 --------------------- 作者冰 河 来源CSDN 原文https://blog.csdn.net/l1028386804/article/details/105393751?utm_mediumdistribute.pc_feed.none-task-blog-alirecmd-13.nonecasedepth_1-utm_sourcedistribute.pc_feed.none-task-blog-alirecmd-13.nonecaserequest_id 版权声明本文为作者原创文章转载请附上博文链接 内容解析ByCSDN,CNBLOG博客文章一键转载插件
