Apache Flume - File通道设计

原文链接：https://blogs.apache.org/flume/entry/apache_flume_filechannel

说明：翻译在尽量符合原文表达的基础上，尽量保证行文流畅。水平有限，请多指正！

这篇文章是关于Flume FileChannel的。Flume是为高效收集聚合大量日志数据设计的可靠的、可用的分布式系统。它有一个基于流式数据流的简单灵活的体系。它提供了可控的可靠机制和许多故障转移与恢复机制。它使用了一个用于在线分析应用的简单可扩展的数据模型。

FileChannel是一个持久化的Flume channel，支持并行的写到多个磁盘并且支持加密。

概念

        当使用Flume时，每个流程都有一个Source、Channel、Sink。一个典型的例子是一个webserver通过RPC（比如：AvroSource）将events写到一个Source、然后Source将events写到MemoryChannel，最后HDFSSink消费event，将它写到HDFS。

                    

       MemoryChannel能提供很高的吞吐量，但是当系统断电或程序崩溃时会丢失数据。因此人们急需一个能持久化的Channel。FileChannel在FLUME-1085被实现。它的目标是提供一个可靠的高吞吐量的Channel。FileChannel保证当断电或崩溃发生时，事务被提交，没有数据丢失。

       重要的一点是FileChannel不做任何数据的复制，仅依赖于底层磁盘的可靠性，因此，由于持久性需要使用FileChannel的用户在购买和配置硬件时注意这一点。底层的磁盘将要做RAID、SAN或类似的东西。

       许多系统为了高的吞吐率需要拿允许小量数据丢失做交换。Flume组决定FileChannel采用不同的方式。Flume是一个支持事务的系统，多个event可以在单个事务中被put或take。batch size用来控制吞吐率。使用大的batch size，flume可以以高吞吐率移动数据，并且不丢失数据。batch size完全可以通过client控制。这个方法与DBMS

相似。

       一个flume事务包含put或take，一个事务中不能同时有put和take操作。每个事务都要实现put和take方法。source通过put将event放入channel，sink通过take将event从channel拿走。

设计

       FileChannel是基于内存队列和WAL设计的。每次事务都是根据事物类型（Take和Put）写到WAL，队列也做相应的修改。每次事务被commited，都会调用fsync确保events被存储在磁盘文件，同时指向该event的指针被放到队列中。这里的队列服务就像其他队列一样：它管理着什么被sink消费。在Take期间，该event的指针从队列被删除。直接从WAL读这个event。由于今天我们有大量可用的RAM，从操作系统的文件缓存中读取也是经常发生的。

       崩溃后，通过重放WALs，队列位置能恢复到崩溃前同样的状态，而那些没有commited的事务被丢弃。重放WALs相当耗时，因此队列本身会周期性的写到磁盘。将队列写到磁盘称为checkpoint。这样，崩溃后，队列首先从磁盘checkpoint文件加载，然后仅仅重放那些队列被最后一次checkpoint到磁盘后commited的事务，这样明显的减少了读取WAL的数量。

       例如，一个channel有2个event，如下所示：

      

WALs包含3个重要的属性：事务ID、序列号、event数据。每个事务都有唯一的事务Id，并且每个event都有唯一的序列号。事务Id被用来简单的将event分组到同一事务，而序列号在重放log时使用。上图中，事务ID为1，序列号为1，2，3.

       当队列被checkpoint到磁盘，增加序列号，同时序列号也被保存到磁盘。重启时，队列首先从磁盘加载，然后比队列序列号大的任何WAL实体被重放。checkpoin操作期间，队列是locked，以至于没有Put或Take操作可以更改它的状态。如果checkpoint期间允许队列的修改，将导致磁盘存储的队列快照与实际队列不一致。

       在上面例子中，事务1commited后，checkpoint发生，在队列中的结果带着events被保存到磁盘还有序列号4也被保存。

       之后，在事务2中，从队列take一个event：

        

如果这个时候崩溃了，重启时队列从checkpoint加载，注意，checkpoint发生在事务2前，2个event“a”和“b”都会被加载到队列，之后任何比4大的已经确认的事务被重放，重放后，“a”event从队列被删除。

上面的设计2点没有考虑到，Take或Put进行中，同时发生checkpoint，会导致数据丢失。假定checkpoint发生在take“a”之后：

如果此时崩溃，在以上描述的设计下，event“b”被加载进入队列，之后重放比5大的任何WAL实体，事务2被rollback，但是这里的take “a”不会被重放。event “a”被丢失，Put也存在相似的情况。由于这个原因，当队列的checkpoint发生时，仍然在处理中的事务也被写出，以至于可以适当的处理这个问题。

实现

FileChannel在Flume项目的flume-file-channel模块，对应包名为org.apache.flume.channel.file。上面描述的队列对应FlumeEventQueue类，WAL对应Log类。队列本身是一个环形数组，通过内存映射文件支撑；而WAL对应一组文件，可以使用LogFile类和它的子类读写这些文件。

结论

FileChannel在遇到硬件、软件、环境失败时，给Flume用户提供了持久化的保证，而且具有高的吞吐量。这两个方面对于大多数情况都是比较重要的，因此FileChannel是推荐使用的Channel。