[发明专利]一种基于Disruptor的数据收发方法

说明书

技术领域

本发明涉及计算机技术领域，特别是涉及一种基于Disruptor的数据收发方法。

背景技术

在大规模的数据处理中，为了实现高性能(低延迟、低资源耗用等)系统，如电子商务系统，金融交易系统等。工程师们会结合现代计算机处理器(CPU)的特点，设计多任务、多线程的架构。这些运行的任务线程，可以争用处理器计算时间，各自独立执行，最终完成同一个或不同的处理任务，这就是我们说的并发。并发程序中通常会发生针对同一程序对象或计算机资源的抢占争用，为了保证这种对某一资源对象的访问操作是安全有序(即线程安全)的，必须为它们设计相应的锁，即我们通常讲的并发同步锁。所以就很容易看到“申请锁”、“读写数据对象(操作资源对象)”、“释放锁”的循环反复情景。在各种架构中，都有专门的、支持并发任务处理的实现，如Java中的线程池ThreadPoolExecutor。

在生产者-消费者场景中，如果生产者和消费者分别使用不同的线程实现，那么这一模型的实质就是不同线程对数据的共享和传递。而在当前普遍的架构中，是使用队列(Queue)来共享数据，生产者线程将消息产出后，放入队列，消费者线程从该队列中获取消息并处理。消息因此得到了传递。所以，队列也可以看成是消息的缓冲区。这种架构允许生产线程在消费线程处理不过来的情况下，还可以继续后面的工作。在Java中，对于队列(Queue)来说，BlockingQueue是主要的线程安全版本。

基于BlockingQueue和ThreadPoolExecutor这一典型的传统技术方案。虽然它帮助实现了异步的、较高性能的并发消息处理，但随着业务增长和上游子系统提交的消息量增加，该方案的缺点也显露无疑。这是因为，这种任务处理机制存在以下明显的不足(缺点)：

(1)BlockingQueue和ThreadPoolExecutor中的并发同步锁无处不在。而锁技术是慢的，代价昂贵。因为它依赖底层操作系统，这导致消息的处理延迟较高。

(2)线程需要申请CPU时间窗口以便执行。数量众多的线程间的上下文切换，意味着频繁的CPU计算资源调度。最终的结果就是，整体的消息处理性能和吞吐量并不能随着线程数量的增加而线性提升。

由此可见，在数据收发过程中，如何克服BlockingQueue和ThreadPoolExecutor所带来的问题是本领域技术人员亟待解决的问题。

发明内容

本发明的目的是提供一种基于Disruptor的数据收发方法，用于在数据收发过程中，克服BlockingQueue和ThreadPoolExecutor所带来的问题。

为解决上述技术问题，本发明提供一种基于Disruptor的数据收发方法，用于数据处理系统，包括：

当接收到上游子系统的待处理数据时，事件处理器获取Disruptor下的RingBuffer的当前最新写入数据的序列号，并将所述待处理数据写入所述序列号所在槽的下一个空闲槽；

所述RingBuffer将当前最新写入数据的序列号加1并公布，然后通知事件监听处理器以进行数据的消费和处理。

优选地，所述RingBuffer中的槽的数量为2ⁿ，其中，n为正整数。

优选地，所述序列号与所述槽的位置号相同。

优选地，所述事件处理器通过基于Netty的数据传输协议接收所述上游子系统的待处理数据。

优选地，所述Disruptor支持单个生产者模式或多个生产者模式。

优选地，还包括：

所述事件监听处理器通过ExecutorService提供的线程池触发所述数据的消费和处理。