关于flume里面channel的事务工作流。

Flume的channel是事务性的，事务是原子操作，要么全部成功，要么失败。flume依赖事务来保证event的可靠性，从source-side到channel，channel到sink-side 端。只有sink端的事务提交成功之后，那么这个batch的event才可以从channel里面删除。每个channel可以有多个source和sink。source-side的事务是由channel的processor来处理，sink-side的事务是sink自己处理，sink利用getTransaction来获得一个事务的实例对象，发起事务操作，然后调用take()方法来从channel里面读取一个batch的event到sink端的存储机制（在这个过程中，如果一个event被sink处理的话，其他的sink是不能在处理这哥event了，除非直到sink事务回滚之后，这个event被重新加入到channel里面，所以此刻才可以对于其他的sink是可用的）。

例外当事务提交或者回滚之后，调用close()方法来释放资源。

单个事务不可能同时写入和读取event。那么这样的话就保证了source只能往channel里面写入event,或者sink只能从channel里面读取数据、

下面介绍Memory channel和file channel对于事务的控制。

1、Memory Channel 

是基于内存的channel，在堆上面保存event, 内部维护一个内存队列，source从尾部写入，sink从头部取出。memory支持高吞吐量，因为基于内存吗，另外是线程安全的，可以同时几个source写入操作或者几个sink读取操作。只是适合不关心数据丢失的场景下面。数据没有持久化的保证。

在memory channel里面的事务模型，是单独在内存维护一个队列，当事务提交的时候，该事务中的event会被自动移动到channel的主队列中，如果提交成功的话， 这个事务的event对于sink是可用的，如果事务回滚的话，那么这些event将会被忽略（为了避免event的重复）。