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的重复)。