正文
结合最近Disruptor的学习，和之前一直思考解决的大文件拆分问题，想到是否可以使用Disruptor作为生产者/消费者传递数据的通道呢？借助其高效的传递，理论上应当可以提升性能。此文便是此想法的落地实现。
1. 问题描述
将大文件按照指定大小拆分为若干小文件。具体可参考：大文件拆分方案的java实践（附源码）。
2. 方案设计
设计简图
如下：
核心组件
- 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，减少资源竞争。
3. 性能表现
实测下来，和之前的‘生产者/消费者+nio’方案性能相当，最佳性能点为：
|
方案 |
-Xms |
-Xmx |
readTaskNum |
writeTaskNum |
queueSize |
Durition |
jvm_ |
jvm_ |
Physics |
|
生产者/消费者+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中对文件进行拆分的逻辑处理太费时，需要逐个字节读取并比对是否为换行符/回车符。所以性能提升并不是很明显。且性能表现并不稳定。
4. 心得
这个示例或许没有达到想要的效果，但是通过这个实例，将Disruptor用到了生产者和消费者模式中，体会Disruptor的设计初衷，提升生产者与消费者之间数据传递的效率，尤其是在纯粹地快速交换数据的场景非常有用。
Disruptor持有的entry对象不宜直接传递给后续消费者使用，鉴于Disruptor会对RingBuffer的entries做内存预加载，且会循环使用对应entries，所以如果供消费者直接使用，会出现数据覆盖的问题。可以参考实例代码中FileLineEventHandler对写入queue的FileLine的处理。
5. 代码示例
github地址：https://github.com/daoqidelv/filespilt-demo
包路径：com.daoqidlv.filespilt.disruptor