nifi的存储包含3个部分：FlowFile Repository，Content Repository，Provenance Repository。
FlowFile Repository：存储了flowfile的metadata
Content Repository：存放了flowfile的内容
Provenance Repository：存放了flowfile的运行时状态
FlowFile Repository
flowfiles是放在JVM内存中的hash map中的，这使得nifi处理速度比较快，但同时，需要一个机制在掉电、内核奔溃、系统升级和维护周期等情况下来保证可靠性。对于flowfile metadata来说，FlowFile Repository就是一个"Write-Ahead Log"。flowfile metadata包括所有与FlowFile相关的属性，一个指向的flowfile实际内容的指针，和FlowFile的状态。这个Write-Ahead Log提供了处理重启和系统意外错误的可靠性。
FlowFile Repository作为nifi的Write-Ahead Log，它记录了flowfile在完成一个事务前的所有状态，它让nifi节点知道在处理flowfile过程中知道flowfile的具体状态，当nifi重启的时候，可以通过它来恢复现场。
nifi会为每一个flowfile周期性的更新“snapshot”，当正在checkpoint的时候，会先写到".partial"文件中。
系统失败时nifi的事务恢复
当nifi节点重启之后，如果"snapshot"文件存在，那么删除".partial"，如果"snapshot"文件不存在，那么将".partial"重命名成"snapshot"。如果nifi节点donwn掉的时候正在写数据，也不会影响数据的正确性。因为nifi具有的Copy On Write和 Immutability这两个特性，所以原始数据一致不变，而副本数据因为变成孤岛而被后台程序删掉。
其中Write-Ahead Log，checkpoint和系统失败恢复的详细过程可参考：nifi wal+checkpoint+recovery wiki
FlowFile Repository中内存和硬盘数据的迁移
flowfile存储在内存中的hash Map中和硬盘上。所有Processor使用的flowfile都向ProcessSession要，这些flowfie存放在hash map中。当flowfile被改变了，在改变内存中对象的同时把变化写到Write-Ahead Log中。这中机制系统运行快速同时也可以让会话提交的时候也能跟踪到发生了什么。
同时，也有"swapping" FlowFiles的概念。当内存中的connection queue中的flowfiles个数超过了“nifi.queue.swap.threshold”的值，批量将10000个优先级低的FlowFiles序列化到磁盘，同时移除出内存。
connection queue会自己决定什么时候把数据换回内存。当有数据交换出去，FlowFile Repository会保存一个swap files的列表。当系统checkpoint的时候，snapshot中为交换出去的f数据开辟了一个section。
Content Repository
Content Repository是存放flow file内容的库，它在磁盘上的数据量远大于另外两个库。
如下图所示，Content Repository的实现由disk和Jvm两部分组成。在磁盘上Content Repository分为container和section两级目录，这样可以提供对于磁盘的并发读写，大大提高nifi的吞吐量，可以达到几百MB，甚至GB。
在Jvm中，每个磁盘上的实体文件在内存中对应一个Reource-claim。每个FlowFile对象都包含了一个Content-claim对象，Content-claim保存了到到Reource-claim的指针，和在文件中的offset和content长度。
Content Repository的immutability
Content Repository中存放的content是“只读”状态，也就说等写到磁盘上后不会被更新，直到数据过期。这样可以最大幅度的保证数据处理的吞吐量和数据的任意状态重放。
Content Repository的copy-on-write
这是一个CompressContent processor用来压缩FlowFiles的例子。FlowFile F1的内容C1要被压缩，由于C1是不能被改变的（immutability）并且我们需要完整的重放数据（通过provenance），所以不会直接覆盖C1。nifi通过copy数据到新的位置C2来实现数据的改变。F1压缩后变成新的FlowFile F1.1 ，重新指向压缩后的数据C2，同时创建一个Provenance Event P1指向F1.1。之前的provenance events依然指向C1，并且拥有旧的属性。
Deletion After Checkpointing
当FlowFile checkpoint之后，会回调FlowFileRepo释放所有的过期的Content-claim对象，并且通知Resource Claim Manager。对应的Resource-claims准备好被删除。
Content Repo会周期性的向Resource Claim Manager轮询可以被删除的resource-claim，然后根据条件来决定数据被归档还是删除。
nifi.properties中的"nifi.content.repository.archive.enabled" 参数决定数据是否被归档，如果没有被归档，则文件会直接被删除。另外，一个后台线程检查磁盘和文件个数来决定是否删除归档文件。
Provenance Repository
Provenance Repository是存放FlowFile历史的地方，为每一条数据提供了数据血统图。每当FlowFile产生动作（FlowFile is created, forked, cloned, modified, etc.），那么就会产生一条provenance event。每一条provenance event中存放了FlowFile的所有属性和指向FlowFile content的指针。Provenance Repository会存放一段时间内的provenance event。
通过provenance event可以查看血统图甚至回放数据，但是如果content被删除了，那么就没发回放了。
nifi会并发写16个provenance日志文件，日志文件会周期性的回滚（30s），回滚的文件先合并，后压缩，最后用Lucene建立索引，以便于查询。索引按照时间戳作sharding，方便删除过期的索引。