您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
实战 SpringCloud 微服务“秒杀”架构(含代码)
 
作者:虎口脱险
  1675  次浏览      16
 2021-1-15 
   
 
编辑推荐:
文章主要介绍了微服务“秒杀”架构原有方案及新增方案、核心支撑文件、秒杀系统场景特点、限流以及负载与分流等等内容。
本文来自于微信公众号 - 搜云库技术团队,由火龙果软件Anna编辑、推荐。

分析,在做秒杀系统的设计之初,一直在思考如何去设计这个秒杀系统,使之在现有的技术基础和认知范围内,能够做到最好;同时也能充分的利用公司现有的中间件来完成系统的实现。

我们都知道,正常去实现一个WEB端的秒杀系统,前端的处理和后端的处理一样重要;前端一般会做CDN,后端一般会做分布式部署,限流,性能优化等等一系列的操作,并完成一些网络的优化,比如IDC多线路(电信、联通、移动)的接入,带宽的升级等等。而由于目前系统前端是基于微信小程序,所以关于前端部分的优化就尽可能都是在代码中完成,CDN这一步就可以免了;

原有方案:

通过分布式锁的方式控制最终库存不超卖,并控制最终能够进入到下单环节的订单,入到队列中慢慢去消费下单

新增方案

请求进来之后,通过活动开始判断和重复秒杀判断之后,即进入到消息队列,然后在消息的消费端去做库存判断等操作,通过消息队列达到削峰的操作

其实,我觉得两种方案都是可以的,只是具体用在什么样的场景;原有方案更适合流量相对较小的平台,而且整个流程也会更加简单;而新增方案则是许多超大型平台采用的方案,通过消息队列达到削峰的目的;而这两种方案都加了真实能进入的请求限制,通过redis的原子自增来记录请求数,当请求量达到库存的n倍时,后面再进入的请求,则直接返回活动太火爆的提示。整编:微信公众号,搜云库技术团队,ID:souyunku

架构介绍

架构介绍 后端项目是基于SpringCloud+SpringBoot搭建的微服务框架架构

前端在微信小程序商城上

核心支撑组件

服务网关 Zuul

服务注册发现 Eureka+Ribbon

认证授权中心 Spring Security OAuth2、JWTToken

服务框架 Spring MVC/Boot

服务容错 Hystrix

分布式锁 Redis

服务调用 Feign

消息队列 Kafka

文件服务 私有云盘

富文本组件 UEditor

定时任务 xxl-job

配置中心 apollo

关于秒杀的场景特点分析

秒杀系统的场景特点

1、秒杀时大量用户会在同一时间同时进行抢购,网站瞬时访问流量激增;

2、秒杀一般是访问请求量远远大于库存数量,只有少部分用户能够秒杀成功;

3、秒杀业务流程比较简单,一般就是下订单操作;

秒杀架构的设计理念

限流:鉴于只有少部分用户能够秒杀成功,所以要限制大部分流量,只允许少部分流量进入服务后端(暂未处理);

削峰:对于秒杀系统瞬时的大量用户涌入,所以在抢购开始会有很高的瞬时峰值。实现削峰的常用方法有利用缓存或者消息中间件等技术;

异步处理:对于高并发系统,采用异步处理模式可以极大地提高系统并发量,异步处理就是削峰的一种实现方式;

内存缓存:秒杀系统最大的瓶颈最终都可能会是数据库的读写,主要体现在的磁盘的I/O,性能会很低,如果能把大部分的业务逻辑都搬到缓存来处理,效率会有极大的提升;

可拓展:如果需要支持更多的用户或者更大的并发,将系统设计为弹性可拓展的,如果流量来了,拓展机器就好;

秒杀设计思路

由于前端是属于小程序端,所以不存在前端部分的访问压力,所以前端的访问压力就无从谈起;

1、秒杀相关的活动页面相关的接口,所有查询能加缓存的,全部添加redis的缓存;

2、活动相关真实库存、锁定库存、限购、下单处理状态等全放redis;

3、当有请求进来时,首先通过redis原子自增的方式记录当前请求数,当请求超过一定量,比如说库存的10倍之后,后面进入的请求则直接返回活动太火爆的响应;而能进入抢购的请求,则首先进入活动ID为粒度的分布式锁,第一步进行用户购买的重复性校验,满足条件进入下一步,否则返回已下单的提示;整编:微信公众号,搜云库技术团队,ID:souyunku4、第二步,判断当前可锁定的库存是否大于购买的数量,满足条件进入下一步,否则返回已售罄的提示;

5、第三步,锁定当前请求的购买库存,从锁定库存中减除,并将下单的请求放入kafka消息队列;

6、第四步,在redis中标记一个polling的key(用于轮询的请求接口判断用户是否下订单成功),在kafka消费端消费完成创建订单之后需要删除该key,并且维护一个活动id+用户id的key,防止重复购买;

7、第五步,消息队列消费,创建订单,创建订单成功则扣减redis中的真实库存,并且删除polling的key。如果下单过程出现异常,则删除限购的key,返还锁定库存,提示用户下单失败;

8、第六步,提供一个轮询接口,给前端在完成抢购动作后,检查最终下订单操作是否成功,主要判断依据是redis中的polling的key的状态;

9、整个流程会将所有到后端的请求拦截的在redis的缓存层面,除了最终能下订单的库存限制订单会与数据库存在交互外,基本上无其他的交互,将数据库I/O压力降到了最低;

关于限流

SpringCloud zuul的层面有很好的限流策略,可以防止同一用户的恶意请求行为

1 zuul:
2 ratelimit:
3 key-prefix: your-prefix #对应用来标识请求的key的前缀
4 enabled: true 5 repository: REDIS #对应存储类型(用来存储统计信息)
6 behind-proxy: true #代理之后
7 default-policy: #可选 - 针对所有的路由配置的策略,除非特别配置了policies
8 limit: 10 #可选 - 每个刷新时间窗口对应的请求数量限制
9 quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制(秒)
10 refresh-interval: 60 # 刷新时间窗口的时间,默认值 (秒)
11 type: #可选 限流方式
12 - user
13 - origin
14 - url
15 policies:
16 myServiceId: #特定的路由
17 limit: 10 #可选- 每个刷新时间窗口对应的请求数量限制
18 quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制(秒)
19 refresh-interval: 60 # 刷新时间窗口的时间,默认值 (秒)
20 type: #可选 限流方式
21 - user
22 - origin
23 - url

关于负载与分流

当一个活动的访问量级特别大的时候,可能从域名分发进来的nginx就算是做了高可用,但实际上最终还是单机在线,始终敌不过超大流量的压力时,我们可以考虑域名的多IP映射。也就是说同一个域名下面映射多个外网的IP,再映射到DMZ的多组高可用的nginx服务上,nginx再配置可用的应用服务集群来减缓压力。整编:微信公众号,搜云库技术团队,ID:souyunku

这里也顺带介绍redis可以采用redis cluster的分布式实现方案,同时springcloud hystrix 也能有服务容错的效果;

而关于nxinx、springboot的tomcat、zuul等一系列参数优化操作对于性能的访问提升也是至关重要;

补充说明一点,即使前端是基于小程序实现,但是活动相关的图片资源都放在自己的云盘服务上,所以活动前活动相关的图片资源上传CDN也是至关重要,否则哪怕是你IDC有1G的流量带宽,也会分分钟被吃完;

主要代码实现

周末抽空整理了一个小demo,把主要的业务逻辑抽出来了,由于为了方便处理,暂时是弄成了单体应用,上文中提到的很多的组件并没有全部集成进来,只保留了核心的业务处理逻辑;如有需要,再将一整套的框架开源出来了(包含了微服务后端和分离了的VUE+elementUI+AdminLTE的后台管理框架);

swagger地址:

http://localhost:8080/swagger -ui.html

git clone 项目后启动即可访问

设置库存参数

{ "stockNum":100, "stallActivityId":1}

设置去秒杀参数

{ "stallActivityId": 1, "purchaseNum": 1, "openId": "this is a test openId", "formId": "this is a test formId", "addressId": 100 }

设置轮询请求的参数

{ "stallActivityId": 1, "openId": "this is a test openId" }

git地址

 
   
1675 次浏览       16
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...