【Flume】【源码分析】flumeng的事务控制的原理详解【内存通道memory channel】

一开始我也是以为flume ng的事务控制是在sink端的，因为只看到那里有事务的使用，但是今天看了一下fluem的整个事务控制，我才后知后觉，特此写了这篇文章，望各位不吝指教。

先来一张图吧！！！

从图中可以看出，flume的事务控制在source端和sink端都有，具体的事务是依赖于通道的。这里将的事务和文件通道中的事务控制有个小区别【文件通道中的事务是记录在磁盘上】

1、获取事务

Transaction transaction = channel.getTransaction();

方法定义：

public Transaction getTransaction() {

    if (!initialized) {
      synchronized (this) {
        if (!initialized) {
          initialize();
          initialized = true;
        }
      }
    }

    BasicTransactionSemantics transaction = currentTransaction.get();
    if (transaction == null || transaction.getState().equals(
            BasicTransactionSemantics.State.CLOSED)) {
      transaction = createTransaction();
      currentTransaction.set(transaction);
    }
    return transaction;
  }

内部调用createTransaction();方法，具体定义如下【看内存通道】：

protected BasicTransactionSemantics createTransaction() {
    return new MemoryTransaction(transCapacity, channelCounter);
  }

public MemoryTransaction(int transCapacity, ChannelCounter counter) {
      putList = new LinkedBlockingDeque<Event>(transCapacity);
      takeList = new LinkedBlockingDeque<Event>(transCapacity);

      channelCounter = counter;
    }

事务初始化了三个变量，分别是： 事件放入列表【一次事务中可以放入的event数量】，事件取出列表【一次事务中可以取走的event数量】，通道监控度量数据
transCapacity就是我们配置的事务容量，也就是一次事务中最多可以容下多少个event

事务，以及事务中的变量都定义好了，下面就是事务中具体的方法定义了：

以下只讲述内存通道的相关方法定义：【关于文件通道的讲解】

1、doPut

putList放入一个event，代表一个event已经纳入到事务中了；这个put的操作肯定是由source端发起的，看个例子：【关于ExexSource的源码分析】

 for (Channel reqChannel : reqChannelQueue.keySet()) {
      Transaction tx = reqChannel.getTransaction();
      Preconditions.checkNotNull(tx, "Transaction object must not be null");
      try {
        tx.begin();

        List<Event> batch = reqChannelQueue.get(reqChannel);

        for (Event event : batch) {
          reqChannel.put(event);
        }

        tx.commit();
      } catch (Throwable t) {
        tx.rollback();
        if (t instanceof Error) {
          LOG.error("Error while writing to required channel: " +
              reqChannel, t);
          throw (Error) t;
        } else {
          throw new ChannelException("Unable to put batch on required " +
              "channel: " + reqChannel, t);
        }
      } finally {
        if (tx != null) {
          tx.close();
        }
      }

这是channelprocessor的方法，循环遍历reqChannelQueue这个map对象，对立面每个通道对应的批量event进行put操作，纳入事务的过程中。

event在放入eventQueue是通过list的add方法，所以放在列表尾部

2、doTake

内存通道中有个变量

queue——LinkedBlockingDeque

在通道初始化的时候，初始化该变量了

synchronized(queueLock) {
        queue = new LinkedBlockingDeque<Event>(capacity);
        queueRemaining = new Semaphore(capacity);
        queueStored = new Semaphore(0);
      }

分别记录的通道的总容量、剩余空闲容量、占用容量

take的时候首先从queue中取出队头event，前面第一步说了放入的时候是放在尾部，现在从头部取，保证先入先出；这里是从总体的通道容量中取出一个，还需要操作一下takeList，将其纳入事务中，takeList中也put一次

3、doCommit

 synchronized(queueLock) {
        if(puts > 0 ) {
          while(!putList.isEmpty()) {
            if(!queue.offer(putList.removeFirst())) {
              throw new RuntimeException("Queue add failed, this shouldn't be able to happen");
            }
          }
        }
        putList.clear();
        takeList.clear();
      }

offer——放队尾【从putList中取头一个放】，一直循环到putList取完了

这里commit都做完了，说明doTake肯定没问题的，所以takeList要清空了

4、doRollback

 synchronized(queueLock) {
        Preconditions.checkState(queue.remainingCapacity() >= takeList.size(), "Not enough space in memory channel " +
            "queue to rollback takes. This should never happen, please report");
        while(!takeList.isEmpty()) {
          queue.addFirst(takeList.removeLast());
        }
        putList.clear();
      }

回滚，肯定回滚的是sink写出失败的event，在takeList中，走到这个方法的时候，doCommit肯定是没做的，只有发生异常了，才会到回滚，所以takeList并未clear。

这里将takeList中的最后一个元素，循环取出放回通道队列的第一个【因为doTake会从头取，当然要把刚刚失败的event继续放到头部，下次继续操作这些event】

同理，这里rollback了，说明putList肯定也没用了，清空，重新再放


无论是往通道中放event还是从通道中取event，都有一个超时控制

// this does not need to be in the critical section as it does not
      // modify the structure of the log or queue.
      if(!queueRemaining.tryAcquire(keepAlive, TimeUnit.SECONDS)) {
        throw new ChannelFullException("The channel has reached it's capacity. "
            + "This might be the result of a sink on the channel having too "
            + "low of batch size, a downstream system running slower than "
            + "normal, or that the channel capacity is just too low. "
            + channelNameDescriptor);
      }

这个keepAlive就是我们配置的超时时间，超时则会抛出异常！

以上所有操作方法中，大家看到有一些变量XXXCounter的操作，这些都是监控度量的数据，详见【flume中度量监控的分析】