通用下载组件,你会吗

前言

下载,是一种常见的业务场景,而【下载】这个动作,其实可以从业务中抽离出来,使其作为一个通用的下载组件,有需求的业务方直接接入即可,避免重复开发。

通用数据下载中心(导出),旨在提供通用的,接入便捷,高效,稳定的数据下载服务

原始

每个服务自己写下载操作:

弊端:

  1. 如果数据量大,将假死在下载页面,交互上不友好
  2. 不方便管理
  3. 代码冗余

针对这些弊端,我们将一一解决!

解决方案

1、异步下载:

针对第一点,数据量大的情况下,我们可以采用异步的方式

  • 用户点击下载时,同步返回下载任务taskId
  • 前端轮询通过taskId获取下载数据

2、下载文件统一存储

针对弊端2(不方便管理),我们一般将下载的文件统一存储,比如 云服务商提供的OSS,对外暴露文件链接即可。

业务上可以自己统一管理这些下载的文件,同时也可以多次下载。

这里你一般需要额外提供一个下载管理页面,管理下载的状态、链接等等,类似于:

3、抽象通用组件

到目前为止,你可能发现了,每一个服务都在自己处理下载操作,并且下载动作的雷同,代码看起来很冗余,接下来我们尝试将下载进行抽象成独立于业务之外的组件。

方案1:写一个通用组件SDK,有需要的应用直接依赖SDK,这样一来,应用方就不需要关注下载这块逻辑,只需要写提供数据的部分即可。

可以看到,SDK统一封装下载逻辑,下载中心生成、管理下载任务,当然,文件上传可以直接从SDK到云OSS,也可以先从SDK将数据推送到下载中心,再由下载中心生成文件上传到云OSS。

方案2:让下载中心承担更多,主要做下载任务提交、下载管理、上传OSS等能力,应用层则提供数据接口,方便下载中心通过接口获取数据。

当然,以上两种方式都已经在生产实践过,各有各的好处,你可以按需选择。

更优解

当你需要导入的数据量级比较大时,你的系统压力可能会过载,频繁GC,最终可能会导致OOM。

怎么优化?

拉取一批数据追加写入到本地文件然后释放内存,保证对象在新生代可回收,预计大数据量导出时内存增长为锯齿波型图。

这里我们通过方案2进行优化:

相关推荐
程序员张31 小时前
SpringBoot计时一次请求耗时
java·spring boot·后端
小马爱打代码4 小时前
微服务外联Feign调用:第三方API调用的负载均衡与容灾实战
微服务·架构·负载均衡
程序员岳焱7 小时前
Java 与 MySQL 性能优化:Java 实现百万数据分批次插入的最佳实践
后端·mysql·性能优化
麦兜*8 小时前
Spring Boot启动优化7板斧(延迟初始化、组件扫描精准打击、JVM参数调优):砍掉70%启动时间的魔鬼实践
java·jvm·spring boot·后端·spring·spring cloud·系统架构
大只鹅8 小时前
解决 Spring Boot 对 Elasticsearch 字段没有小驼峰映射的问题
spring boot·后端·elasticsearch
ai小鬼头8 小时前
AIStarter如何快速部署Stable Diffusion?**新手也能轻松上手的AI绘图
前端·后端·github
9527华安8 小时前
FPGA实现40G网卡NIC,基于PCIE4C+40G/50G Ethernet subsystem架构,提供工程源码和技术支持
fpga开发·架构·网卡·ethernet·nic·40g·pcie4c
IT_10249 小时前
Spring Boot项目开发实战销售管理系统——数据库设计!
java·开发语言·数据库·spring boot·后端·oracle
bobz9659 小时前
动态规划
后端
stark张宇9 小时前
VMware 虚拟机装 Linux Centos 7.9 保姆级教程(附资源包)
linux·后端