一、问题描述
性能问题
今天开发完功能在本地测试时,发现有一个页面加载缓慢,经排查发现是一个接口响应时间过长导致的。
性能指标
可以看到页面加载平均耗时1秒左右,对用户体验影响较大。
一、问题描述
在水务项目开发过程中,对于设备获取到的数据系统需要根据用户设置的规则进行处理,判断该条数据是否异常,并且根据规则判断是否应该生成告警信息,并将处理结果保存到数据库中。 我们系统采用的微服务架构,阈值规则和告警不属于同一个模块,对于需要生成告警的数据要么考虑 openfeign 或者使用 RPC 远程调用。
为什么选择消息队列
这里我选择使用消息队列实现这一功能,这样阈值规则模块处理完数据,如果需要生成告警只需要发送消息让告警模块去异步处理,无需同步。等待即使告警模块挂了,也不会影响数据处理。因为消息队列可以实现异步处理、解耦、削峰,符合业务需要。
项目简介
该项目是一个在线的非学历职业技能培训平台,核心业务是以售卖各种技能培训的在线课程,并提供丰富的学习辅助功 能、交互功能,以提升用户学习时的氛围感和学习的积极性。
核心技术
SpringBoot、SpringCloud、Mybatis、MySQL、Redis、Redisson、RabbitMQ、XXL-JOB
核心职责
- 参与设计和开发了学习计划和学习进度统计功能。设计了一套高性能的视频播放进度记录系统,在不增加数据库压力的情 况下,使视频播放进度回放精度达到秒级。
- 对评价系统中的点赞功能进行了系统重构:重新设计了点赞数据结构,解除了与业务的耦合,成为了一个通用的点赞系 统。基于Redis实现点赞记录和点赞数缓存,同时基于定时任务做数据持久化,大大提高了点赞系统的并发能力,减轻了数 据库压力。
- 参与了积分排行榜功能的设计和开发。对用户的各种学习和交互行为做积分统计,例如签到积分、学习积分、问答积分 等;并且按月累计积分形成赛季排行榜。做到了当前赛季排行榜的实时更新、历史赛季排行榜的分表持久保存。
- 参与了优惠券系统的设计与开发。优惠券系统支持基于兑换码兑换优惠券,我设计了一套可以支持20亿量级的并且可以脱 离数据库做高效校验的兑换码生成算法。同时也对领券功能进行了并发安全、并发性能的优化设计。另外还设计实现了优 惠券叠加方案推荐算法,基于用户购物车中商品推荐最佳的优惠券叠加方案。
1
功能概述
在之前的过滤规则中,我们使用责任链模式来实现,对于抽奖策略的前置规则过滤是顺序一条链的,有一个成功就可以返回。比如;黑名单抽奖、权重人群抽奖、默认抽奖,总之它只能有一种情况,所以这样的流程是适合责任链的。
但对于抽奖中到抽奖后的规则,它是一个树形的规则过滤每次过滤规则后根据结果不同会有不同的流程,比如抽奖中该奖品是需要一定次数解锁的,就要过滤用户是否满足要求,不满足就可以发别的幸运奖,满足要求再过滤库存,足够的话就正常发奖,不成功的话就走兜底流程。抽奖后是否需要发放优惠券、积分、实物奖品等。所以单独的责任链是不能满足的。如果是拆分开抽奖中规则和抽奖后规则分阶段处理,中间单独写逻辑处理库存操作。那么是可以实现的。不过后续的规则开发仍需要在代码上改造。
功能概述
在我们的流程设计中,用户执行抽奖时会判断是否已经超过N积分,如果超过N积分则可以在限定范围内进行抽奖(权重)。同时如果用户是黑名单范围的羊毛党用户,则只返回固定的奖品ID(黑名单)。
为了刺激用户消费,我们又设计了部分奖品需要抽取一定次数后才能解锁,所以在抽奖中又要进行判断这个奖品是否有抽一定次数后解锁的规则。
以及包括抽奖后的一些后置规则判断。
所以我们在设计抽奖的系统的时候,要时刻记住松耦合。就像 Spring 源码中拆解一个 Bean 对象为不同阶段一样,我们这里也把抽奖拆解为不同时间段的过程,以用于可以在各个节点添加所需的功能流程。这样的设计也就更加便于后续的功能迭代了。
功能概述
抽奖算法目前主要有两种实现方案:
- 空间换时间
- 提前计算好各个奖品的概率分布区间
- 使用本地内存(Guava)或Redis存储概率分布数据
- 抽奖时通过随机数在概率空间内O(1)定位
- 优点是性能高,缺点是占用内存空间
- 时间换空间
- 抽奖时动态生成随机数
- 通过for循环遍历概率区间匹配奖品
- 适用于概率分布数据量大的场景