做销售的网站,wordpress chianz,京东商城网站建设,黑龙江省住建厅官网#x1f44f;作者简介#xff1a;大家好#xff0c;我是爱吃芝士的土豆倪#xff0c;24届校招生Java选手#xff0c;很高兴认识大家#x1f4d5;系列专栏#xff1a;Spring原理、JUC原理、Kafka原理、分布式技术原理、数据库技术#x1f525;如果感觉博主的文章还不错的… 作者简介大家好我是爱吃芝士的土豆倪24届校招生Java选手很高兴认识大家系列专栏Spring原理、JUC原理、Kafka原理、分布式技术原理、数据库技术如果感觉博主的文章还不错的话请三连支持一下博主哦博主正在努力完成2023计划中源码溯源一探究竟联系方式nhs19990716加我进群大家一起学习一起进步一起对抗互联网寒冬 文章目录 抽奖系统需求概述设计思路总库表梳理核心领域开发之抽奖领域库表梳理结构梳理核心介绍 核心领域开发之发放奖品领域结构梳理 核心领域开发之活动领域流程梳理结构梳理 ID生成与分库分表应用层编排规则引擎设计MQ解耦发货流程定时任务扫描扫描库表补偿发货单MQ消息分布式锁扣减总体思路 优化思路机器环境配置一、定义 REST 接口进行压测使用二、Postmain 模拟调用三、梯度压测四、数据库连接异常五、引入 Druid 数据源六、分布式锁和抽奖的后续流程七、添加索引八、Arthas 分析接口响应时长并将查库操作存入 Redis九、磁盘和网络带宽导致负载增加十、增加 Tomcat 线程数 抽奖系统
需求概述
如果设计一个抽奖系统如何设计一个高并发的秒杀系统
这类项目在网上其实很多但是实际的工作流到底是什么呢难不成只有简单的数据库操作和逻辑判断吗实际的工作流都有哪些呢站在整体上来看都需要哪些呢下面就以一个项目来讲解下都有什么
设计思路
总库表梳理 核心领域开发之抽奖领域
库表梳理 结构梳理 核心介绍
其实可以看到该部分其实是DDD结构中的一个单独的领域主要是用来走抽奖逻辑。那么实际上仅仅对于抽奖这件事来说其实就是抽奖策略的设计。通过策略包装里面的doDraw方法选择合适的策略进行抽奖。那么核心流就是策略都有哪些
实际上关于这方面的策略主要有 总体策略 和 单项策略。
单项策略就是说加入某个奖品抽完了我们不需要重新计算概率如果刚好抽到了没有的奖品那么就相当于没抽到
而总体概率加入说没有商品了需要重新计算现有商品的概率。
核心领域开发之发放奖品领域
这一步算的上是抽出奖品后以什么样的规则进行发放了。
结构梳理
lottery-domain
└── src└── main└── java└── cn.itedus.lottery.domain.award├── model├── repository│ ├── impl│ │ └── AwardRepository│ └── IAwardRepository└── service├── factory│ ├── DistributionGoodsFactory.java│ └── GoodsConfig.java└── goods├── impl│ ├── CouponGoods.java│ ├── DescGoods.java│ ├── PhysicalGoods.java│ └── RedeemCodeGoods.java├── DistributionBase.java└── IDistributionGoodsc.java
关于 award 发奖领域中主要的核心实现在于 service 中的两块功能逻辑实现分别是goods 商品处理、factory 工厂
goods包装适配各类奖品的发放逻辑虽然我们目前的抽奖系统仅是给用户返回一个中奖描述但在实际的业务场景中是真实的调用优惠券、兑换码、物流发货等操作而这些内容经过封装后就可以在自己的商品类下实现了。
factory工厂模式通过调用方提供发奖类型返回对应的发奖服务。通过这样由具体的子类决定返回结果并做相应的业务处理。从而不至于让领域层包装太多的频繁变化的业务属性因为如果你的核心功能域是在做业务逻辑封装就会就会变得非常庞大且混乱。
核心领域开发之活动领域
流程梳理 实际上活动的创建在实际的工作流中必须涉及到这些步骤那么基于这些步骤就可以设计具体的代码结构
结构梳理
lottery-domain
└── src└── main└── java└── cn.itedus.lottery.domain.activity├── model├── repository│ └── IActivityRepository└── service├── deploy├── partake [待开发]└── stateflow├── event│ ├── ArraignmentState.java│ ├── CloseState.java│ ├── DoingState.java│ ├── EditingState.java│ ├── OpenState.java│ ├── PassState.java│ └── RefuseState.java├── impl│ └── StateHandlerImpl.java├── AbstractState.java├── IStateHandler.java└── StateConfig.java
ID生成与分库分表
关于 ID 的生成因为有三种不同 ID 用于在不同的场景下
订单号唯一、大量、订单创建时使用、分库分表活动号唯一、少量、活动创建时使用、单库单表策略号唯一、少量、活动创建时使用、单库单表
所以针对订单号的这种情况需要考虑分库分表的实现思路
综合来说具体的实现思路如下设计一个简易版的数据库路由-CSDN博客
应用层编排 这个图其实就简单的将主题的思路都囊括出来了当有了各种活动以后需要对当前用户能否参与活动进行检验如状态、日期、库存、参与次数等。然后进入抽奖部分按照不同的策略进行抽奖最终做到落库在这里后续的设计打算使用MQ进行解耦分离。
规则引擎设计
应用层编排的设计的具体思路其实还是需要知道一开始的活动才行的但是假如说活动有很多怎么知道要参加什么活动呢
所以需要一种规则引擎 通过这种规则引擎的方式来选取不同的活动然后在执行后续的逻辑。
MQ解耦发货流程 使用消息队列必须要考虑的是发送成功或者失败以后重复消费的问题。
首先需要开启幂等。然后发送端如果发送失败的话更新表这个表中存储的是发送成功或者失败的状态。如果发送失败的话将来需要使用定时任务进行回调而图中下半部分的MQ是否消费成功则是手动开启了消费确认。
定时任务扫描
按照上面说的如果任务发送MQ失败了需要用定时任务进行回调就是使用这个现在比较常见的有xxl-job这里我们使用自研的一个设计一个简易版本的分布式任务调度系统-CSDN博客
扫描库表补偿发货单MQ消息 按照定时任务扫描如果成功了就发送MQ没有成功的话就继续等待下一次定时任务扫描即可。
分布式锁扣减 在抽奖系统中引入 Redis 模块优化用户参与抽奖活动。因为只要有大量的用户参与抽奖那么这个就属于秒杀场景。所以需要使用 Redis 分布式锁的方式来处理集中化库存扣减的问题否则在 TPS 达到1k-2k就会把数据库拖垮。在设计秒杀流程时优化锁的颗粒度力度不要把锁直接放到活动编号上这样在极端临界情况下会出现秒杀解锁失败导致库存有剩余但不能下单的情况。所以需要增加锁的颗粒度以滑动库存剩余编号的方式进行加锁例如 100001_1、100001_2、100001_3以此类推具体看代码实现。增加缓存扣减库存后发送 MQ 消息进行异步更新数据库中活动库存做最终数据一致性处理。这一部分如果你的系统并发体量较大还需要把 MQ 的数据不要直接对库更新而是更新到缓存中再由任务最阶段同步以此减少对数据库表的操作
即使是使用 Redis 分布式锁我们也不希望把锁的颗粒度放的太粗否则还是会出现活动有库存但不能秒杀提示“活动过于火爆”。那么我们就需要按照活动编号把库存锁的颗粒度缩小实际操作也并不复杂只是把活动ID库存扣减后的值一起作为分布式锁的Key这样就缩小了锁的颗粒度。
其中有一个比较关键的就是扣减库存后在各个以下的流程节点中如果有流程失败则进行缓存库存的恢复操作。
总体思路 优化思路
前置知识项目压测优化实践思路-CSDN博客
机器环境配置
1、阿里云服务器三台 4c8G 100mbps 带宽 2、一台中间件机器 3、一台监控机器 prometheus、influxdb 、grafana 4、一台应用机器 jdk 、lottery 、arthas、 nedo_export 一、定义 REST 接口进行压测使用 二、Postmain 模拟调用
Postmain 模拟调用 RESTFUL 接口 需关注响应时长和返回数据包大小因为数据包大小会影响到带宽占用。根据响应时长可以算出压测中线程组的执行总时长 三、梯度压测
梯度压测(逐渐增加并发观察系统的负载找到系统的临界点) 线程数:根据接口的响应时间来决定 如果很短 就可以用很少的线程 反之更多的线程循环次数接口响应时间 * 循环次数 执行样本的时间(s) 可以控制所有线程组在多久的时间内执行完成
线程数循环次数样本数54000200001040004000020400080000254000100000304000120000354000140000404000160000454000180000504000200000
总线程总数275
总循环次数40000 次
总样本数1,040,000
四、数据库连接异常
开始压测MySQL 直接报错
问题 1数据库连接异常 引入 DBRouter 待数据源配置的 用 master 分支的代码需要在 dbrouter 的 master 分支加一个 druid 依赖否则会报如下错误
Caused by: java.lang.ClassNotFoundException: com.alibaba.druid.pool.DruidDataSource
at java.net.URLClassLoader.findClass(URLClassLoader.java:387) ~[na:1.8.0_371]
at java.lang.ClassLoader.loadClass(ClassLoader.java:418) ~[na:1.8.0_371]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355) ~[na:1.8.0_371]
at java.lang.ClassLoader.loadClass(ClassLoader.java:351) ~[na:1.8.0_371]
at java.lang.Class.forName0(Native Method) ~[na:1.8.0_371]
at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_371]
at
cn.bugstack.middleware.db.router.config.DataSourceAutoConfig.createDataSource(DataSourceAu
toConfig.java:103) ~[db-router-spring-boot-starter-1.0.2-SNAPSHOT.jar:1.0.2-SNAPSHOT]加入 Druid 依赖用的是 Master 分支代码 需要加一个 Druid 数据源 否则启动 在 Lottery 的父依赖中排除指定依赖 五、引入 Druid 数据源
压测 2修改 Druid 数据源后直接压测
系统负载1 分钟负载 2.1 5 分钟负载 1.3 15 分钟负载 0.7说明系统可以处理过来系统的负载和 CPU 的核数有关对于 4 核 CPU 来说 当负载大于 4 就需要介入查看。CPU 使用和内存占用不高 每个样本的汇总报告:系统的 TPS 持续增加 RT最开始响应时间长 后来持续平稳应该是最开始的样本 完成了抽奖的整个流程后续的请求返回的都是系统无库存在 Redis 层拦截 TPS 活动线程数 总结看监控信息显示负载不高响应时间在最开始的时候稍长 后续逐渐平稳TPS 持续增加异常率很低。推测是在 Redis 层库存校验时进行了拦截返回几乎后面所有的请求响应结果都是无库存。
{code:0001,info:活动剩余库存非可用,drawAwardInfo:null}六、分布式锁和抽奖的后续流程
压测三基于压测二的总结接下来压测 获取分布式锁和抽奖的后续流程【建议先跑两个线程组看看接口的响应时间在决定启动多个线程执行多少次尽量避免直接启动压测二的样本】
1Jmeter 测试计划 2样本和线程数
线程数循环数样本数51000500010100010000
3聚合报告
看聚合报告 RT 的相应时间都在 100ms 以上所以适合用 少线程 多循环的方式执行原因是因为低时延 prometheus 监控整个系统资源使用率 不高 负载不高 IO 也不高 TPS RT响应时间越来越长 CPU利用率很低 七、添加索引
压测三改进
1对应响应时间长的接口压测的时候可以增加多个线程数 循环次数减
2由于操作数据库比较多查询较多建立字段索引列加快查询效率
创建联合索引user_take_activity 和 user_take_activity_count 添加联合索引activity 表可以给 activity_id 加一个单列索引(数据量较少暂时看不出效果) 索引执行效果 样本
线程数循环次数样本数200204000300206000
聚合报告吞吐量上来了是上一轮压测的 8 倍多 但是执行响应时间还是很长平均值还在708ms 左右 是上一轮的 7 倍左右 RT 总结
通过响应时间 可以确定是采用多线程 少循环次数 还是 少线程 多循环次数
增加索引值 提高查询效率TPS 有所回升所以我们需要确定代码中那块的执行时间比较长进而优化借助阿里的 arthas 性能分析
八、Arthas 分析接口响应时长并将查库操作存入 Redis
监控 doDrawProcess 找到耗时的 doPartake 方法
trace cn/itedus/lottery/application/process/draw/impl/ActivityDrawProcessImpl doDrawProcess监控 doPartake 方法
trace cn/itedus/lottery/domain/activity/service/partake/IActivityPartake doPartak查询账单接口响应时间 100MS 左右 生成领取记录接口在 224ms 左右 优化查询账单接口将查库操作改为查 Redis
修改后的代码 压测后的结果RT 有所减少 TPS 有所增加 Arthas 返回结果查询账单接口减少 50ms 九、磁盘和网络带宽导致负载增加
增加线程数压测
样本数
线程数循环次数样本数20020040000400200800006002001200008002001600001000200200000
聚合报告 TPS 平均在 1500 左右 RT 平均在 472 prometheus 监控显示 系统 1 分钟负载已达到 5.4 说明系统中有大量的排队请求系统已经请求不过来了这个时候就需要优化了因为已经达到系统的瓶颈了带宽也达到最大值说明带宽也影响了系统的处理能力CPU 和内存正常 磁盘 IO 使用率很高、网络带宽不足或延迟 造成系统的负载很高 但是 CPU 和内存正常 TPS: 很稳定 RT响应时间在增加 十、增加 Tomcat 线程数
Tomcat 线程数为 400 默认 200 prometheus 监控显示 负载有所降低 聚合报告 RT TPS:
