Disruptor的应用示例——大文件拆分

结合最近Disruptor的学习,和之前一直思考解决的大文件拆分问题,想到是否可以使用Disruptor作为生产者/消费者传递数据的通道呢?借助其高效的传递,理论上应当可以提升性能。此文便是此想法的落地实现。

问题描述

将大文件按照指定大小拆分为若干小文件。具体可参考:大文件拆分方案的java实践(附源码)

方案设计

设计简图

如下:

Disruptor的应用示例——大文件拆分

核心组件

  • FileReadTask —— Disruptor的生产者线程,负责读取源文件,;
  • Disruptor —— FileReadTask和FileLineEventHandler线程之间传递数据的通道,无阻塞;
  • RingBuffer —— Disruptor的核心组件,负责暂存被传递的消息,同时负责协调生产者和消费者之间的工作节奏;
  • FileLineEventHandler —— 不断从Disruptor中读取FileLine,并直接扔给FileWriteTask的queue,是Disruptor的消费者,同时也是queue的生产者;
  • FileWriteTask —— 从queue中读取FileLine,并写入到子文件,是queue的消费者。

设计思路

使用Disruptor作为生产者和消费者之间传递数据的通道,利用Disruptor高效传递数据的特性提升性能;

FileLineEventHandler作为Disruptor的消费者,只负责从中读取数据,但是不负责耗时长的子文件操作;

FIleWriteTask服务耗时长的文件写入工作,且每个task独享queue,减少资源竞争。

性能表现

实测下来,和之前的‘生产者/消费者+nio’方案性能相当,最佳性能点为:

方案

-Xms

-Xmx

readTaskNum

writeTaskNum

queueSize

Durition
(ms)

jvm_
CPU(%)

jvm_
mem

Physics
_mem

生产者/消费者+nio

512m

512m

24

8

4096

8158

80

100M

4.6G

Disruptor+生产者/消费者+nio

512m

512m

2

2

1024

6191  

80

500m

4.2G

相对与不使用Disruptor的方案,时延有所下降,但是并不明显,两个方案主要瓶颈都在于FileReadTask中对文件进行拆分的逻辑处理太费时,需要逐个字节读取并比对是否为换行符/回车符。所以性能提升并不是很明显。且性能表现并不稳定。

心得

这个示例或许没有达到想要的效果,但是通过这个实例,将Disruptor用到了生产者和消费者模式中,体会Disruptor的设计初衷,提升生产者与消费者之间数据传递的效率,尤其是在纯粹地快速交换数据的场景非常有用。

Disruptor持有的entry对象不宜直接传递给后续消费者使用,鉴于Disruptor会对RingBuffer的entries做内存预加载,且会循环使用对应entries,所以如果供消费者直接使用,会出现数据覆盖的问题。可以参考实例代码中FileLineEventHandler对写入queue的FileLine的处理。

代码示例

github地址:https://github.com/daoqidelv/filespilt-demo

包路径:com.daoqidlv.filespilt.disruptor

上一篇:使用electron+vue开发一个跨平台todolist(便签)桌面应用


下一篇:C# .Net 多进程同步 通信 共享内存 内存映射文件 Memory Mapped 转