BlockingQueue在任务调度中的精彩应用

问题来了…

我们正在构建的系统需要从外部第三方系统中采集数据，受不可控的外部环境的影响，我们的数据采集工作经常被阻塞，一种典型的情况是：某个目标数据库因为要同时处理多个外围系统叠加的查询请求而经常响应缓慢，从而导致我们的Job严重超时，而这个Job原有的设计是每5分钟执行一次，每次执行时会从目标数据库中查询最近5分钟内的数据，通常情况下这种简单的设计没有问题，但是当前一个Job严重超时时，后续启动的Job仍然以启动时的前5分钟作为时间窗口进行查询，就会导致数据丢失。 本文原文出处: 本文原文链接: http://blog.csdn.net/bluishglc/article/details/78447813 转载请注明出处。

异步执行？

一个简单的解决方案是将Job的执行变为异步非阻塞模式，每一个Job被触发时都在一个独立的线程中运行。但是这个方案不适用于我们的系统，原因是这样采集的数据无法保证按时间有序，而确保数据按时间有序对我们的系统至关重要。所以这一方案被否决。

最佳方案！

经过仔细的思考，我们认为必须要将这个Job切分成两个子的Job：第一个Job负责制定周期性的计划，准确地说是周期性地生成查询的时间参数，第二个Job则负责读取时间参数执行查询，这一部分的工作并不是周期性的，原则上，只要有时间参数生成就应该立即执行，如果执行超时，在超时期间,我们需要缓存第一个Job生成的时间参数，而当所有的查询都及时完成没有Pending的查询计划时，第二个Job需要等待新的查询参数到达。到这里事情已经变得很明朗了，我们实际上设计的是一个生产者-消费者模型，只是生产者在“有节奏”的生产，那么在这个模式里，作为第三个参与者：仓库，或者说传送带，就是起最关键作用的，而BlockingQueue就是一个现成的完美实现，于是落地的方案就是：

1. 第一个Job由定时器周期性触发，每次触发时会把当前时间写入到一个BlockingQueue的队尾。

2. 第二个Job循环执行，每次执行的工作就是从BlockingQueue的队头取出时间参数，组装SQL并执行。

   2.1. 当队列为空时，由BlockingQueue来Pending当前线程，等待时间参数进入队列。

3. 当第二个Job执行完一次时，如果队列中还有时间参数，会立即执行第二次，发生此类情况时就说明前一次的执行超过了5分钟。