大体量 高并发 业务与性能 权衡方案参考

亿级筛选十万级数据

业务场景 - 活动预约 & 数据导出
  • 总用户数据量亿级
  • 预约用户数量级为十万级
  • 预约仅保存userId,次日需导出该次预约数据报表,包含用户基本信息
  • 用户基础信息保存于其他系统,需要进行交互查询
解决方案
  • 查询总数为十万级,则查询调用总次数为 (n * 100000 / 单次查询数据量)
  • 用户信息已分表,则需要根据分表规则对userId进行分组,每次查询时只查一个分表
  • 预约结束次日凌晨就开始生成报表,当业务人员点击导出时,报表文件已经生成
方案说明

用户系统数据量为亿级,且用户数据已分表,若上游不进行事先处理,会对用户系统造成较大的性能消耗,进而影响整个系统运转,故由上游事先进行数据分组;业务层面,业务人员需要在次日上班时间将数据导出并进行下一步处理,则数据生成的时间T+1内完成,若实时导出则必然页面loading时间很长,故在凌晨直接生成好文件。

千万级数据统计

业务场景 - 数据收集 & 业绩计算
  • 基础数据每日増量千万级
  • 基础数据需要进一步加工成业绩数据,且每种类型处理方式不同,耗时不同
  • 单位时间数据増量与时间范围没有规律的数学关系
  • 系统性能不足,则无法处理大体量数据,系统性能过高,则会造成性能浪费
解决方案
  • 针对不规则的大体量増量数据,采用MQ进行性能削峰,所有类型的数据均使用MQ接收
  • 系统内部交互也采用MQ进行发送,接收,释放系统性能
  • 定期删除过期数据,仅保留统计结果
方案说明

最终业绩数据只要在T+1日呈现即可,T日数据的接收与处理并非需要实时呈现,针对无规律大体量数据,在无法确定具体接口性能时,使用MQ来规避此问题,性能上仅需保证当日数据当日处理完毕即可。

大体量 高并发 业务与性能 权衡方案参考_第1张图片

万级QPS并发

业务场景 - 抢购 & 秒杀
  • 用户抢购页面,需要查询个人信息
  • 用户抢购QPS峰值为10000左右
  • 需要防止缓存击穿,大量请求进入DB
  • 需要考虑限流,防止系统崩溃
解决方案
  • 配置抢购后,将静态资源放入缓存中
  • 根据过往规律和用户活跃程度,筛选出可能参与的用户,将用户信息放入缓存中
  • 配置布隆过滤器,优化查询路线
  • 配置令牌桶,预先设置好抢购名额
方案说明

高并发下场景,静态资源直接放入缓存,避免读库;针对用户习惯事先缓存一部分用户数据,能缓解查库的压力;配合布隆过滤器,决定该请求的查询是否有效(即数据不存在或可能存在),优化查询路线;使用令牌桶预先保存抢购库藏进行限流。

你可能感兴趣的:(java)