Flume-NG中Transaction并发性探究

　　我们曾经在Flume-NG中的Channel与Transaction关系(原创)这篇文章中说了channel和Transaction的关系，但是在source和sink中都会使用Transaction，那么Transaction的并发性如何？

　　Transaction是介于channel和source、sink直接的一层缓存，为了安全性和可靠性source、sink不能直接访问channel，只能访问在他之上的Transaction，通过Transaction间接操作channel中的数据。

　　这节我们以memory channel和file channel来研究一下Flume-NG的Transaction并发性。

　　首先所有channel的父类都是BasicChannelSemantics，所有Transaction的父类都是BasicTransactionSemantics，mem channel中的Transaction是MemoryTransaction是内部私有类；file channel的Transaction是FileBackedTransaction。一般来说自己定义channel需要实现自己的Transaction。

　　我们在看源码时发现FileBackedTransaction不允许take和put同时操作，在其doCommit和doRollback方法中都有限制使得，究其原因是：。而mem channel的Transaction则没有诸多限制。

　　我们在source和sink中见到的getTransaction()获取的Transaction是同一个吗？如果不是并发性是怎么保证的？第一个很明显不是同一个，试想如果都是同一个，那么不同组件比如一个source和一个sink都会有Transaction.close操作，将会关闭事务，那关闭晚的还如何commit？我们再来看下getTransaction()代码：　　

   /**
    * <p>
    * Initializes the channel if it is not already, then checks to see
    * if there is an open transaction for this thread, creating a new
    * one via <code>createTransaction</code> if not.
    * @return the current <code>Transaction</code> object for the
    *     calling thread
    * </p>
    */
   @Override
   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;
   }

　　上面我们可以看出来，如果transaction还未初始化或者transaction的状态是CLOSED(就是执行了close()方法改了状态)，说明需要通过createTransaction()新建一个Transaction，createTransaction()这个方法在子类中实现的。我们来看看mem和file的createTransaction()方法的代码，先看mem的：

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

　　直接就返回了自己的Transaction对象，在看file的createTransaction()方法的代码：

 @Override
   protected BasicTransactionSemantics createTransaction() {
     if(!open) {
       String msg = "Channel closed " + channelNameDescriptor;
       if(startupError != null) {
         msg += ". Due to " + startupError.getClass().getName() + ": " +
             startupError.getMessage();
         throw new IllegalStateException(msg, startupError);
       }
       throw new IllegalStateException(msg);
     }
     FileBackedTransaction trans = transactions.get();
     if(trans != null && !trans.isClosed()) {        //在这保证put和take只能一个时刻有一个
       Preconditions.checkState(false,
           "Thread has transaction which is still open: " +
               trans.getStateAsString()  + channelNameDescriptor);
     }
     trans = new FileBackedTransaction(log, TransactionIDOracle.next(),
         transactionCapacity, keepAlive, queueRemaining, getName(),
         channelCounter);
     transactions.set(trans);
     return trans;
   }

　　这个就比mem的复杂了点，毕竟代码多了不少。

　　在看上面的getTransaction()方法，如果已经创建了一个Transaction则会放入currentTransaction中，然后以后再调用getTransaction()就会通过currentTransaction返回currentTransaction.get()，这莫不是同一个Transaction吗？那就好像有点不对了，对吧，那到底是怎么回事呢？

　　关键在于currentTransaction这个东西，我们看声明：private ThreadLocal<BasicTransactionSemantics> currentTransaction = new ThreadLocal<BasicTransactionSemantics>()是ThreadLocal的实例，可能有很多人不了解这个东西，其实我也不了解！！简单来说：ThreadLocal使得各线程能够保持各自独立的一个对象，ThreadLocal并不是一个Thread，而是Thread的局部变量，为解决多线程程序的并发问题提供了一种新的思路，详细请谷歌、百度之。ThreadLocal有一个ThreadLocalMap静态内部类，你可以简单理解为一个MAP，这个‘Map’为每个线程复制一个变量的‘拷贝’存储其中，这个“Map”的key是当前线程的ID，value就是set的变量，而get方法会依据当前线程ID从ThreadLocalMap中获取对应的变量，咱们这里就是Transaction。这下明白了吧，每个source和sink都会有单独的线程来驱动的，所以都有各自的Transaction，是不同的，因此也就可以并发了(针对memory channel)。

　　但是上面file的createTransaction()方法为什么是那样的？因为我们说了file的Transaction不能同时put和take(同一个Transaction一般只会做一个事就是put或者take)，也就是不存在并发性的，所以在file channel中的transactions也设置为了private final ThreadLocal<FileBackedTransaction> transactions =new ThreadLocal<FileBackedTransaction>()，由于channel也是单独的线程驱使，所以这个transactions中始终只存在一对值就是file channel的线程ID和创建的Transaction，如果不同sink或者source调用getTransaction()时会试图通过createTransaction()方法来创建新的Transaction但是file的createTransaction()方法由于已经有了一个Transaction，在其关闭之前是不会同意 再次创建的，所以就只能等待这个Transaction关闭了，因此也就保证了put和take不会同时存在了。也就没有并发性了，性能自然大受影响。

　　那file channel为什么不让put和take同时操作呢？这个问题很值得研究，一：put、take、commit、rollback都会获取log的共享锁，一旦获取其他就只能读，获取锁的目的就是这四个操作都要写入log文件；二，put操作并不会将写入log的event的指针放到queue中，而是在commit中才会放到queue中；三、take的操作会直接从queue中取数据，这时如果put已经commit就可以获取数据，如果没有则会返回null；四、由于四个操作都会获取log锁，导致实际上写达不到并发，而且这个log锁使得即使是写不同的数据文件也不可能，因为只有这一个锁，不是每个数据文件一个锁(数据文件的个数是动态的这个不好做)；五、若take和put同时操作会使得可能交替执行获取锁，此时可能put没commit而queue中无数据，take获取锁之后也没什么意义而且也是轮流不是并行，只会降低put和take的性能，比如put和take各自单独只需1s即可，但是这样可能需要2s甚至更长时间(take一直在等待put的commit)才能完成。综上不让put和take同时操作比较合理。

　　但是有没有更好的方案可以提高file的性能呢？因为file是基于文件的性能不可能很高，更为合理的办法是合理提高并发性，可以优化的一个方案是put、take、commit、rollback单独以文件存放，并设置相应的多个锁，但是文件的动态变化以及put和put、take和take、commit和commit、rollback和rollback之间的并发性又难以实现了，似乎只适合take和put的并发，这样貌似会使得file channel更复杂了，但是性能应该会提高一些，会不会得不偿失啊？

　　还有一个问题就是：file channel中的createTransaction()方法如果再次创建Transaction，而先前创建的并未关闭，会执行Preconditions.checkState(false,"Thread has transaction which is still open: " +trans.getStateAsString()+ channelNameDescriptor)会直接抛出异常，但是似乎日志中没有类似的异常啊，而且进程也并未中断，但是显然使用了file channel的flume，sink和source可以正常运行，这是怎么搞得？