实时流处理中，分布式存储对文件操作有何特点？

本文共计1197个文字，预计阅读时间需要5分钟。

这两日都在忙于文件交易的对接，很有趣。每一步都不会顺心如意，但每一步的解决方案都大有裨益。首先是对文件变动的监控，能找到许多方法，例如利用ELK家族的Filebeat工具进行探索。

这两天都是在跟文件打交道，很有趣，每一步都不会顺心如意，但每一步的解决都有所获益，首先是对文件变化的监测，能找到很多办法，例如通过ELK家族的Filebeat工具来探测，但是外部工具不好融合进Storm，最好是自己写Java程序来监测。

引入Java NIO 监控文件

其实jdk7以上版本就有一个比较不错的选择，那就是nio包里的WatchService监控器，我觉得它有两方面的优点，其一就是由操作系统的信号通知机制，当文件目录中出现变化就发信号给应用层监控器，那么这种由操作系统主动通知的效率就远好于应用程序对文件的反复轮巡，而且不占用过多系统资源；其二编程模型并不采用观察者模式注册监听器的方案，而是将多线程问题隐藏起来，客户端对api采取循环阻塞的直观调用，这就非常有利于嵌入到各种运行容器当中去执行文件采集监控。

另外监测文件变化后按行采集变化记录我采用了RadmonAccessFile对象，这个文件操作对象常用于断点续传此类的需求，很方便，关键要设计一个可持久化的位移记录文件，保证采集器重启后总能从未读取的最新变化数据点位置开始采集数据。如下图所示：

文件监控与采集功能嵌入Storm集群之后又出现了一个新问题，那就是Storm spout实例不会如你所愿地运行在指定的机器上，而是完全由Storm集群随机地在节点上指定运行，但被监测的文件位置是固定的，反正总有笨办法：当Storm集群启动后，确定spout运行的机器节点，再由该机器执行cdc文件输出程序，但是这样耦合性太强，必须跟随Storm对spout实例的安排而变化采集位置，维护管理就会很麻烦，而且很容易出错。