Hello,你们好,我是楼下小黑哥~java
若是给你一个包含一亿行数据的超大文件,让你在一周以内将数据转化导入生产数据库,你会如何操做?shell
上面的问题实际上是小黑哥前段时间接到一个真实的业务需求,将一个老系统历史数据经过线下文件的方式迁移到新的生产系统。数据库
因为老板们已经敲定了新系统上线时间,因此只留给小黑哥一周的时间将历史数据导入生产系统。小程序
因为时间紧,而数据量又超大,因此小黑哥设计的过程想到一下解决办法:多线程
欢迎关注个人公众号:小黑十一点半,得到平常干货推送。若是您对个人专题内容感兴趣,也能够关注个人博客:studyidea.cn并发
首先咱们能够写个小程序,或者使用拆分命令 split
将这个超大文件拆分一个个小文件。异步
-- 将一个大文件拆分红若干个小文件,每一个文件 100000 行 split -l 100000 largeFile.txt -d -a 4 smallFile_
这里之因此选择先将大文件拆分,主要考虑到两个缘由:async
第一若是程序直接读取这个大文件,假设读取一半的时候,程序忽然宕机,这样就会直接丢失文件读取的进度,又须要从新开头读取。ide
而文件拆分以后,一旦小文件读取结束,咱们能够将小文件移动一个指定文件夹。ui
这样即便应用程序宕机重启,咱们从新读取时,只须要读取剩余的文件。
第二,一个文件,只能被一个应用程序读取,这样就限制了导入的速度。
而文件拆分以后,咱们能够采用多节点部署的方式,水平扩展。每一个节点读取一部分文件,这样就能够成倍的加快导入速度。
当咱们拆分完文件,接着咱们就须要读取文件内容,进行导入。
以前拆分的时候,设置每一个小文件包含 10w 行的数据。因为担忧一会儿将 10w 数据读取应用中,致使堆内存占用太高,引发频繁的 Full GC,因此下面采用流式读取的方式,一行一行的读取数据。
固然了,若是拆分以后文件很小,或者说应用的堆内存设置很大,咱们能够直接将文件加载到应用内存中处理。这样相对来讲简单一点。
逐行读取的代码以下:
File file = ... try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) { while (iterator.hasNext()) { String line=iterator.nextLine(); convertToDB(line); } }
上面代码使用 commons-io
中的 LineIterator
类,这个类底层使用了 BufferedReader
读取文件内容。它将其封装成迭代器模式,这样咱们能够很方便的迭代读取。
若是当前使用 JDK1.8 ,那么上述操做更加简单,咱们能够直接使用 JDK 原生的类 Files
将文件转成 Stream
方式读取,代码以下:
Files.lines(Paths.get("文件路径"), Charset.defaultCharset()).forEach(line -> { convertToDB(line); });
其实仔细看下 Files#lines
底层源码,其实原理跟上面的 LineIterator
相似,一样也是封装成迭代器模式。
上述读取的代码写起来不难,可是存在效率问题,主要是由于只有单线程在导入,上一行数据导入完成以后,才能继续操做下一行。
为了加快导入速度,那咱们就多来几个线程,并发导入。
多线程咱们天然将会使用线程池的方式,相关代码改造以下:
File file = ...; ExecutorService executorService = new ThreadPoolExecutor( 5, 10, 60, TimeUnit.MINUTES, // 文件数量,假设文件包含 10W 行 new ArrayBlockingQueue<>(10*10000), // guava 提供 new ThreadFactoryBuilder().setNameFormat("test-%d").build()); try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) { while (iterator.hasNext()) { String line = iterator.nextLine(); executorService.submit(() -> { convertToDB(line); }); } }
上述代码中,每读取到一行内容,就会直接交给线程池来执行。
咱们知道线程池原理以下:
因为咱们上述线程池设置的核心线程数为 5,很快就到达了最大核心线程数,后续任务只能被加入队列。
为了后续任务不被线程池拒绝,咱们能够采用以下方案:
以上两种方案都存在一样的问题,第一种是至关于将文件全部内容加载到内存,将会占用过多内存。
而第二种建立过多的线程,一样也会占用过多内存。
一旦内存占用过多,GC 没法清理,就可能会引发频繁的 Full GC,甚至致使 OOM,致使程序导入速度过慢。
解决这个问题,咱们能够以下两种解决方案:
CountDownLatch
批量执行CountDownLatch
批量执行JDK 提供的 CountDownLatch
,可让主线程等待子线程都执行完成以后,再继续往下执行。
利用这个特性,咱们能够改造多线程导入的代码,主体逻辑以下:
try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) { // 存储每一个任务执行的行数 List<String> lines = Lists.newArrayList(); // 存储异步任务 List<ConvertTask> tasks = Lists.newArrayList(); while (iterator.hasNext()) { String line = iterator.nextLine(); lines.add(line); // 设置每一个线程执行的行数 if (lines.size() == 1000) { // 新建异步任务,注意这里须要建立一个 List tasks.add(new ConvertTask(Lists.newArrayList(lines))); lines.clear(); } if (tasks.size() == 10) { asyncBatchExecuteTask(tasks); } } // 文件读取结束,可是可能还存在未被内容 tasks.add(new ConvertTask(Lists.newArrayList(lines))); // 最后再执行一次 asyncBatchExecuteTask(tasks); }
这段代码中,每一个异步任务将会导入 1000 行数据,等积累了 10 个异步任务,而后将会调用 asyncBatchExecuteTask
使用线程池异步执行。
/** * 批量执行任务 * * @param tasks */ private static void asyncBatchExecuteTask(List<ConvertTask> tasks) throws InterruptedException { CountDownLatch countDownLatch = new CountDownLatch(tasks.size()); for (ConvertTask task : tasks) { task.setCountDownLatch(countDownLatch); executorService.submit(task); } // 主线程等待异步线程 countDownLatch 执行结束 countDownLatch.await(); // 清空,从新添加任务 tasks.clear(); }
asyncBatchExecuteTask
方法内将会建立 CountDownLatch
,而后主线程内调用 await
方法等待全部异步线程执行结束。
ConvertTask
异步任务逻辑以下:
/** * 异步任务 * 等数据导入完成以后,必定要调用 countDownLatch.countDown() * 否则,这个主线程将会被阻塞, */ private static class ConvertTask implements Runnable { private CountDownLatch countDownLatch; private List<String> lines; public ConvertTask(List<String> lines) { this.lines = lines; } public void setCountDownLatch(CountDownLatch countDownLatch) { this.countDownLatch = countDownLatch; } @Override public void run() { try { for (String line : lines) { convertToDB(line); } } finally { countDownLatch.countDown(); } } }
ConvertTask
任务类逻辑就很是简单,遍历全部行,将其导入到数据库中。全部数据导入结束,调用 countDownLatch#countDown
。
一旦全部异步线程执行结束,调用 countDownLatch#countDown
,主线程将会被唤醒,继续执行文件读取。
虽然这种方式解决上述问题,可是这种方式,每次都须要积累必定任务数才能开始异步执行全部任务。
另外每次都须要等待全部任务执行结束以后,才能开始下一批任务,批量执行消耗的时间等于最慢的异步任务消耗的时间。
这种方式线程池中线程存在必定的闲置时间,那有没有办法一直压榨线程池,让它一直在干活呢?
回到最开始的问题,文件读取导入,其实就是一个生产者-消费者消费模型。
主线程做为生产者不断读取文件,而后将其放置到队列中。
异步线程做为消费者不断从队列中读取内容,导入到数据库中。
一旦队列满载,生产者应该阻塞,直到消费者消费任务。
其实咱们使用线程池的也是一个生产者-消费者消费模型,其也使用阻塞队列。
那为何线程池在队列满载的时候,不发生阻塞?
这是由于线程池内部使用 offer
方法,这个方法在队列满载的时候不会发生阻塞,而是直接返回 。
那咱们有没有办法在线程池队列满载的时候,阻塞主线程添加任务?
实际上是能够的,咱们自定义线程池拒绝策略,当队列满时改成调用 BlockingQueue.put
来实现生产者的阻塞。
RejectedExecutionHandler rejectedExecutionHandler = new RejectedExecutionHandler() { @Override public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { if (!executor.isShutdown()) { try { executor.getQueue().put(r); } catch (InterruptedException e) { // should not be interrupted } } } };
这样一旦线程池满载,主线程将会被阻塞。
使用这种方式以后,咱们能够直接使用上面提到的多线程导入的代码。
ExecutorService executorService = new ThreadPoolExecutor( 5, 10, 60, TimeUnit.MINUTES, new ArrayBlockingQueue<>(100), new ThreadFactoryBuilder().setNameFormat("test-%d").build(), (r, executor) -> { if (!executor.isShutdown()) { try { // 主线程将会被阻塞 executor.getQueue().put(r); } catch (InterruptedException e) { // should not be interrupted } } }); File file = new File("文件路径"); try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), "UTF-8")) { while (iterator.hasNext()) { String line = iterator.nextLine(); executorService.submit(() -> convertToDB(line)); } }
一个超大的文件,咱们能够采用拆分文件的方式,将其拆分红多份文件,而后部署多个应用程序提升读取速度。
另外读取过程咱们还可使用多线程的方式并发导入,不过咱们须要注意线程池满载以后,将会拒绝后续任务。
咱们能够经过扩展线程池,自定义拒绝策略,使读取主线程阻塞。
好了,今天文章内容就到这里,不知道各位有没有其余更好的解决办法,欢迎留言讨论。
欢迎关注个人公众号:小黑十一点半,得到平常干货推送。若是您对个人专题内容感兴趣,也能够关注个人博客:studyidea.cn