这两天都是在跟文件打交道，很有趣，每一步都不会顺心如意，但每一步的解决都有所获益，首先是对文件变化的监测，能找到很多办法，例如通过elk家族的filebeat工具来探测，但是外部工具不好融合进storm，最好是自己写Java程序来监测。其实jdk7以上版本就有一个比较不错的选择，那就是nio包里的WatchService监控器，我觉得它有两方面的优点，其一就是由操作系统的信号通知机制，当文件目录中出现变化就发信号给应用层监控器，那么这种由操作系统主动通知的效率就远好于应用程序对文件的反复轮巡，而且不占用过多系统资源；其二编程模型并不采用观察者模式注册监听器的方案，而是将多线程问题隐藏起来，客户端对api采取循环阻塞的直观调用，这就非常有利于嵌入到各种运行容器当中去执行文件采集监控。另外监测文件变化后按行采集变化记录我采用了RadmonAccessFile对象，这个文件操作对象常用于断点续传此类的需求，很方便，关键要设计一个可持久化的位移记录文件，保证采集器重启后总能从未读取的最新变化数据点位置开始采集数据。文件监控与采集功能嵌入storm集群之后又出现了一个新问题，那就是storm spout实例不会如你所愿地运行在指定的机器上，而是完全由storm集群随机地在节点上指定运行，但被监测的文件位置是固定的，反正总有笨办法：当storm集群启动后，确定spout运行的机器节点，再由该机器执行cdc文件输出程序，但是这样耦合性太强，必须跟随storm对spout实例的安排而变化采集位置，维护管理就会很麻烦，而且很容易出错。因此我就引出了一个新的假设：通过分布式文件系统(dfs)来解决此问题，但是dfs的选型很重要，Hadoop hdfs肯定不行，它脱离了普通文件系统的操作方式，最终我挑选了两款dfs，一是clusterfs，二是moosefs，它们都具有fuse结合功能，通过mount dfs到本地目录的方式，让访问dfs如同访问本地目录文件一样无缝结合，dfs的任一客户端节点对文件的修改，都会在所有dfs客户端节点上被通知，因此我让storm的所有节点都成为dfs的客户端，这样无论spout随机运行在任何节点上，都可以在本节点的相同目录中去访问dfs中的被监测的文件，同时被监测文件还具有了多副本的高可靠性。今天就是对此假设进行了验证，它们都可以胜任，也让我充分认识到分布式计算与存储的相辅相成。