CN106802824A - 一种基于Disruptor的数据收发方法 - Google Patents

Abstract

本发明公开了一种基于Disruptor的数据收发方法，用于数据处理系统，包括：当接收到上游子系统的待处理数据时，事件处理器获取Disruptor下的RingBuffer的当前最新写入数据的序列号，并将待处理数据写入序列号所在槽的下一个空闲槽；RingBuffer将当前最新写入数据的序列号加1并公布，然后通知事件监听处理器以进行数据的消费和处理。由于Disruptor相对于传统方式没有锁也就不存在竞争，因此能够克服处理延迟较高的问题，另外无需CPU频繁的资源调度，因此整体的消息处理性能和吞吐量随着线程数量的增加而线性提升。

Description

一种基于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提供的线程池触发所述数据的消费和处理。

本发明所提供的基于Disruptor的数据收发方法，用于数据处理系统，包括：当接收到上游子系统的待处理数据时，事件处理器获取Disruptor下的RingBuffer的当前最新写入数据的序列号，并将待处理数据写入序列号所在槽的下一个空闲槽；RingBuffer将当前最新写入数据的序列号加1并公布，然后通知事件监听处理器以进行数据的消费和处理。由于Disruptor相对于传统方式没有锁也就不存在竞争，因此能够克服处理延迟较高的问题，另外无需CPU频繁的资源调度，因此整体的消息处理性能和吞吐量随着线程数量的增加而线性提升。经过测试对比发现，基于Disruptor的数据收发方法的性能比基于BlockingQueue的收发方法高出一个数量级，数据处理的吞吐量和延迟指标都远远超越了BlockingQueue的收发方法高出一个数量级，数据处理的吞吐量和延迟指标都远远超越了BlockingQueue的收发方法。

附图说明

为了更清楚地说明本发明实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种基于Disruptor的数据收发方法的流程图；

图2为本发明实施例提供的一种基于Disruptor的数据收发的示意图；

图3为本发明实施例提供的另一种基于Disruptor的数据收发方法的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本发明保护范围。

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

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。

图1为本发明实施例提供的一种基于Disruptor的数据收发方法的流程图。图2为本发明实施例提供的一种基于Disruptor的数据收发的示意图。如图1所示，基于Disruptor的数据收发方法，用于数据处理系统，包括以下步骤：

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

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

Disruptor的关键特性是无锁编程，这个是通过单一写线程的方式实现的，即一块数据在同一时间永远只有一个线程写入。通过遵循这个编程原则来避免使用昂贵的同步锁或CAS操作，这就是为什么Disruptor这么快的原因。Disruptor在的缓存区域就是RingBuffer。Ring Buffer：如其名，环形的缓冲区。这个数据结构的主要特点是，数据是被写入到它上面一个个称为槽的位置，前提是这个槽是空闲的。

在具体实施中，这些槽的数量是可以允许自己定义和设置的，作为优选地实施方式，RingBuffer中的槽的数量为2ⁿ，其中，n为正整数。所以它可以是几万到几千万数量不等的数据缓冲规模。RingBuffer里的每一个数据都有一个序列号(sequence number)来索引，在具体实施中，可以设置序列号与槽的位置号相同。RingBuffer维护当前最新放置的元素的序列号，这个序列号一直递增，(通过求余来得到数据在RingBuffer下面的数组下标)。可以理解的是，如果RingBuffer中的槽用完后，则之前被取走数据的槽就可以作为空闲槽进入一轮的使用，此时槽的序号会依据当前待处理的序列号而变化。

例如，RingBuffer维护的最新写入的数据的序列号是18，事件处理器在接收到待处理数据后，从RingBuffer可以获知下一空闲数据写入槽位是19，则生产线程将待处理数据写入到19号槽位。写入之后，RingBuffer才会将最后写入数据的序列号更新为19并对外公布，并通知事件监听处理器进行消息数据的消费和处理。

如图2所示，该图显示的是基于Disruptor的新技术方案，事件处理器在接收到上游子系统提交来的待处理数据后，放入了Disruptor中的内存存储结构RingBuffer中，这些待处理数据被认为是一个个事件(event)，并被Disruptor中已注册的若干个事件监听处理器(event handler)监听和处理。在此图中，左边将待处理数据写入Ring Buffer结构中的箭头就是“生产者-消费者”模型中的生产者，而右边的箭头，即事件监听处理器就是消费者。

本实施例提供的基于Disruptor的数据收发方法，用于数据处理系统，包括：当接收到上游子系统的待处理数据时，事件处理器获取Disruptor下的RingBuffer的当前最新写入数据的序列号，并将待处理数据写入序列号所在槽的下一个空闲槽；RingBuffer将当前最新写入数据的序列号加1并公布，然后通知事件监听处理器以进行数据的消费和处理。由于Disruptor相对于传统方式没有锁也就不存在竞争，因此能够克服处理延迟较高的问题，另外无需CPU频繁的资源调度，因此整体的消息处理性能和吞吐量随着线程数量的增加而线性提升。经过测试对比发现，基于Disruptor的数据收发方法的性能比基于BlockingQueue的收发方法高出一个数量级，数据处理的吞吐量和延迟指标都远远超越了BlockingQueue的收发方法高出一个数量级，数据处理的吞吐量和延迟指标都远远超越了BlockingQueue的收发方法。

在上述实施例的基础上，事件处理器通过基于Netty的数据传输协议接收上游子系统的待处理数据。基于Netty(一个基于NIO的、提供异步的、事件驱动的、客户-服务器端通信编程框架)的数据传输协议，连接上游子系统。上游子系统的待处理数据正是通过基于Netty的数据传输协议被提交到了核心系统。

Disruptor支持两种生产者类型，SINGLE和MULTI，即单个生产者模式或多个生产者模式。在具体实施中，可以根据实际情况设置，如图2所示，配置的是多个生产者模式。

图3为本发明实施例提供的另一种基于Disruptor的数据收发方法的流程图。在上述实施例的基础上，还包括：

S12：事件监听处理器通过ExecutorService线程池触发数据的消费和处理。

在基于Netty的数据传输协议中，可以配置事件监听处理器和ExecutorService线程池。这里的事件监听处理器就是消费者(Consumer)，可以是一个也可以是多个，它们是通过ExecutorService提供的线程来触发消息事件处理的。正是因为有了RingBuffer这一优越的数据结构作为基础，配合Disruptor中以序列号(sequence number)来索引这一核心设计要素，使得消费者线程避免了昂贵的同步锁就可以高效地消费和处理待处理数据。

以上对本发明所提供的基于Disruptor的数据收发方法进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (6)

1.一种基于Disruptor的数据收发方法，用于数据处理系统，其特征在于，包括：

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

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

2.根据权利要求1所述的基于Disruptor的数据收发方法，其特征在于，所述RingBuffer中的槽的数量为2ⁿ，其中，n为正整数。

3.根据权利要求1所述的基于Disruptor的数据收发方法，其特征在于，所述序列号与所述槽的位置号相同。

4.根据权利要求1所述的基于Disruptor的数据收发方法，其特征在于，所述事件处理器通过基于Netty的数据传输协议接收所述上游子系统的待处理数据。

5.根据权利要求1所述的基于Disruptor的数据收发方法，其特征在于，所述Disruptor支持单个生产者模式或多个生产者模式。

6.根据权利要求1所述的基于Disruptor的数据收发方法，其特征在于，还包括：

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