延时任务之zookeeper

前言
实现延时任务的关键点，是要存储任务的描述和任务的执行时间，还要能根据任务执行时间进行排序，那么我们可不可以使用zookeeper来实现延时任务呢？答案当然是肯定的。要知道，zookeeper的znode同样可以用来存储数据，那么我们就可以利用这一点来实现延时任务。实际上，著名的zookeeper客户端curator就提供了基于zookeeper的延时任务API，今天就从源码的角度带大家了解下curator是如何使用zookeeper实现延时任务的。不过需要提前说明的是，使用zookeeper实现延时任务不是一个很好的选择，至少称不上优雅，标题中的优雅实现延时任务只是为了和前文呼应，关于使用zookeeper实现延时任务的弊端，后文我会详细解释。

上手curator

关于zookeeper的安装和使用这里就不介绍了，之前也推送过相关文章了，如果对zookeeper不了解的，可以翻下历史记录看下。接下来直接进入主题，首先来体验一把curator的延时任务API。

首先是任务消费者：

public class DelayTaskConsumer  implements QueueConsumer{
 @Override
 public void consumeMessage(String message) throws Exception {
     System.out.println(MessageFormat.format("发布资讯。id - {0} , timeStamp - {1} , " +
             "threadName - {2}",message,System.currentTimeMillis(),Thread.currentThread().getName()));
 }
 @Override
 public void stateChanged(CuratorFramework client, ConnectionState newState) {
     System.out.println(MessageFormat.format("State change . New State is - {0}",newState));
 }
}

curator的消费者需要实现QueueConsumer接口，在这里我们做的逻辑就是拿到任务描述（这里简单起见，任务描述就是资讯id），然后发布相应的资讯。

接下来看下任务生产者：

public class DelayTaskProducer {

   private static final String CONNECT_ADDRESS="study-machine:32783";

   private static final int SESSION_OUTTIME = 5000;

   private static final String NAMESPACE = "delayTask";

   private static final String QUEUE_PATH = "/queue";

   private static final String LOCK_PATH = "/lock";

   private CuratorFramework curatorFramework;

   private DistributedDelayQueue delayQueue;

   {
       RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 10);
       curatorFramework= CuratorFrameworkFactory.builder().connectString(CONNECT_ADDRESS)
               .sessionTimeoutMs(SESSION_OUTTIME).retryPolicy(retryPolicy)
               .namespace(NAMESPACE).build();
       curatorFramework.start();
       delayQueue= QueueBuilder.builder(curatorFramework, new DelayTaskConsumer(),
               new DelayTaskSerializer(), QUEUE_PATH).lockPath(LOCK_PATH).buildDelayQueue();
       try {
           delayQueue.start();
       }catch (Exception e){
           e.printStackTrace();
       }
   }

   public void produce(String id,long timeStamp){
       try {
           delayQueue.put(id,timeStamp);
       }catch (Exception e){
           e.printStackTrace();
       }
   }

}

任务生产者主要有2个逻辑，一个是在构造代码块中初始化curator的延时任务队列，另一个是提供一个produce方法供外部往队列里放延时任务。

在初始化延时任务时，需要传入一个字节数组与任务描述实体之间的序列化器，这里简单地将任务描述处理成字符串：

public class DelayTaskSerializer implements QueueSerializer {
   @Override
   public byte[] serialize(String item) {
       return item.getBytes();
   }
   @Override
   public String deserialize(byte[] bytes) {
       return new String(bytes);
   }
}

最后写一个客户端测一下：

public class DelayTaskTest {

   public static void main(String[] args) throws Exception{
       DelayTaskProducer producer=new DelayTaskProducer();
       long now=new Date().getTime();
       System.out.println(MessageFormat.format("start time - {0}",now));
       producer.produce("1",now+TimeUnit.SECONDS.toMillis(5));
       producer.produce("2",now+TimeUnit.SECONDS.toMillis(10));
       producer.produce("3",now+TimeUnit.SECONDS.toMillis(15));
       producer.produce("4",now+TimeUnit.SECONDS.toMillis(20));
       producer.produce("5",now+TimeUnit.SECONDS.toMillis(2000));
       TimeUnit.HOURS.sleep(1);
   }
}

客户端比较简单，就是往延时队列里放5个任务，其中最后一个任务的执行时间比较晚，主要是为了观察curator到底往zookeeper里放了些啥。运行程序，结果如下：

接下来我们看下zookeeper里到底存了哪些信息：

[zk: localhost(CONNECTED) 2] ls /
[delayTask, zookeeper]

其中，zookeeper节点是zookeeper自带的，除了zookeeper之后，还有一个delayTask节点，这个节点就是我们在生产者里设置的命名空间NAMESPACE。因为同一个zookeeper集群可能会被用于不同的延时队列，NAMESPACE的作用就是用来区分不同延时队列的。再看看NAMESPACE里是啥：

[zk: localhost(CONNECTED) 3] ls /delayTask
[lock, queue]

可以看到，有2个子节点：lock跟queue，分别是我们在生产者中设置的分布式锁路径LOCK_PATH和队列路径QUEUE_PATH。因为同一个延时队列可能会被不同线程监听，所以为了保证任务只被一个线程执行，zookeeper在任务到期的时候需要申请到分布式锁后才能执行任务。接下来我们重点看下queue节点下有什么：

[zk: localhost(CONNECTED) 7] ls /delayTask/queue
[queue-|165B92FCD69|0000000014]

发现里面只有一个子节点，我们猜想应该就是我们刚刚放到延时队列里面的还未执行的任务，我们接着看看这个子节点下面还有没有子节点：

[zk: localhost(CONNECTED) 8] ls /delayTask/queue/queue-|165B92FCD69|0000000014
[]

发现没有了。

那我们就看看queue-|165B92FCD69|0000000014这个节点里面放了什么数据：

[zk: localhost(CONNECTED) 9] get /delayTask/queue/queue-|165B92FCD69|0000000014
5
cZxid = 0x3d
ctime = Sat Sep 08 12:20:41 GMT 2018
mZxid = 0x3d
mtime = Sat Sep 08 12:20:41 GMT 2018
pZxid = 0x3d
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 11
numChildren = 0

可以发现放的是任务描述，也就是资讯id——5。到这里我们就会知道了，zookeeper把任务描述放到了相应任务节点下了，那么任务执行时间放到哪里了呢？由于queue-|165B92FCD69|0000000014并没有子节点，所以我们可以猜想任务执行时间放在了节点名称上了。观察节点名称，queue只是一个前缀，没什么信息量。0000000014应该是节点序号（这里也可以猜测zookeeper用来存放任务的节点是顺序节点）。那么就只剩下165B92FCD69了，这个看上去并不像时间戳或者日期，但是里面有字母，可以猜测会不会是时间戳的十六进制表示。我们将其转化为十进制看下：

@Test
   public void test(){
       long number = Long.parseLong("165B92FCD69", 16);
       System.out.println(number);
       System.out.println(new Date(number));
   }

可以转化为十进制，然后将十进制数转化成日期，确实也是我们在一开始设置的任务执行时间。这样一来就大概清楚了curator是怎么利用zookeeper来存储延时任务的了：将任务执行时间存储在节点名称中，将任务描述存储在节点相应的数据中。

那么到底是不是这样的呢？接下来我们看下curator的源码就知道了。

curator源码解析

1.DistributedDelayQueue类

curator延时任务的入口就是DistributedDelayQueue类的start方法了。我们先不说start方法，先来看看DistributedDelayQueue类有哪些属性：

private final DistributedQueue      queue;


   DistributedDelayQueue
       (
           CuratorFramework client,
           QueueConsumer consumer,
           QueueSerializer serializer,
           String queuePath,
           ThreadFactory threadFactory,
           Executor executor,
           int minItemsBeforeRefresh,
           String lockPath,
           int maxItems,
           boolean putInBackground,
           int finalFlushMs
       )
   {
       Preconditions.checkArgument(minItemsBeforeRefresh >= 0, "minItemsBeforeRefresh cannot be negative");

       queue = new DistributedQueue
       (
           client,
           consumer,
           serializer,
           queuePath,
           threadFactory,
           executor,
           minItemsBeforeRefresh,
           true,
           lockPath,
           maxItems,
           putInBackground,
           finalFlushMs
       )
       {
           @Override
           protected long getDelay(String itemNode)
           {
               return getDelay(itemNode, System.currentTimeMillis());
           }

           private long getDelay(String itemNode, long sortTime)
           {              
               long epoch = getEpoch(itemNode);
               return epoch - sortTime;
           }

           @Override
           protected void sortChildren(List children)
           {
               final long sortTime = System.currentTimeMillis();
               Collections.sort
               (
                   children,
                   new Comparator()
                   {
                       @Override
                       public int compare(String o1, String o2)
                       {
                           long        diff = getDelay(o1, sortTime) - getDelay(o2, sortTime);
                           return (diff < 0) ? -1 : ((diff > 0) ? 1 : 0);
                       }
                   }
               );
           }
       };
   }

这里截取一部分代码出来。实际上DistributedDelayQueue里只有一个queue属性，queue属性是DistributedQueue类的实例，从名字可以看到其是一个分布式队列。不过DistributedDelayQueue里的queue比较特殊，其是DistributedQueue类的匿名内部类的实例，这个匿名子类重写了DistributedQueue的部分方法，如：getDelay、sortChildren等。这一点很重要，后面的代码会用到这2个方法。

2.DistributedDelayQueue的入口start方法

接下来我们就来看下DistributedDelayQueue的入口start方法：

/**
    * Start the queue. No other methods work until this is called
    *
    * @throws Exception startup errors
    */
   @Override
   public void     start() throws Exception
   {
       queue.start();
   }

可以看到，其调用的是queue的start方法。我们跟进去看看：

@Override
   public void     start() throws Exception
   {
       if ( !state.compareAndSet(State.LATENT, State.STARTED) )
       {
           throw new IllegalStateException();
       }

       try
       {
           client.create().creatingParentContainersIfNeeded().forPath(queuePath);
       }
       catch ( KeeperException.NodeExistsException ignore )
       {
           // this is OK
       }
       if ( lockPath != null )
       {
           try
           {
               client.create().creatingParentContainersIfNeeded().forPath(lockPath);
           }
           catch ( KeeperException.NodeExistsException ignore )
           {
               // this is OK
           }
       }

       if ( !isProducerOnly || (maxItems != QueueBuilder.NOT_SET) )
       {
           childrenCache.start();
       }

       if ( !isProducerOnly )
       {
           service.submit
               (
                   new Callable