state

这次来介绍一下fevernova的state功能，与flink的state功能很类似，

flink的state是保证恰好一次计算的核心点，当然至少一次也需要state。

fevernova的state用途

之前fevernova都是作为数据传输框架，对state的依赖并不高。

需要state用来存储kafka的offset，或者binlog的filename和position。

在实现kafka To HDFS模块的时候，也会将关闭的文件列表和commit保存在state里，

减少重复文件的产生，实现恰好一次。类似于flink的rollingfilesink。

state保存的位置

因为只保存少量的meta信息，所以state就简单的保存在文件系统里。

如果需要提高可用性，就通过类似Nas的方式进行目录挂载。这类方案都是非常成熟的。

计算状态

在无意中，发现了一个开源项目OpenHFT。

其中的项目质量还是比较高的，利用其中的序列化、持久化的库进行state的保存非常方便。

让内存中保存状态的对象实现WriteBytesMarshallable和ReadBytesMarshallable接口，

根据需求自定义序列化和反序列化的方法，就可以完成state的读写操作。

简单测试了一下性能还是非常好的。fevernova中的exchange模块中有具体的使用。

去重

单纯依靠Chandy-Lamport算法实现的流计算框架并不能在实际需求中完全实现恰好一次计算。

比如写入kafka的数据有重复，通常就在计算逻辑中去重，这也意味着更多的cpu和内存开销。

fevernova在exchange模块中实现了一个基于Roaringbitmap的滑窗过滤器，通过统一的去重。

压缩的位图信息也会随着state进行保存，重启时可以完美衔接。