CN114186163A - 一种应用层网络数据缓存方法 - Google Patents

Abstract

本发明公开了应用层网络数据缓存方法，实现通信中间件在性能容量超过极限后于应用层进行的对网络数据缓存进行管理的机制。其技术方案为：方法适配于多链路可靠传输通信组件基于线程池机制的多通道并行的发布‑订阅机制，当接收端不接受数据或者其处理速率比发送速率低，导致底层的系统接收缓存区已满时，发布端将未成功发送的数据先存入应用层缓存区，直到对应发送通道的系统底层的发送队列有空间后，重新将该应用层缓存区的数据依次写入到发送队列进行发送，应用层网络数据缓存方法包括针对内存管理中的多线程固定内存池分配、针对内存管理中的内存回收、针对内存管理中的线程局部存储、以及发布端进行消息发布的流程。

Description

一种应用层网络数据缓存方法

技术领域

本发明涉及一种数据缓存方法，具体涉及可应用于金融交易软件领域中的应用层网络数据的缓存方法。

背景技术

金融交易软件在开发和使用过程中，不可避免地会涉及到不同模块之间的数据流传输，模块之间的数据传输一般交由传输通信组件负责，也称为通信中间件。

对于传输通信组件而言，通信通道，也就是数据传输需要经过的通信通道，是至关重要的。不同机器之间的数据传输，通信通道可以分为TCP、UDP广播、UDP单播、UDP组播四种类型。对于在不同机器之间做数据传输的场景，为保证数据的高可靠性，即对于发布端产生的消息，需保证接收端能有序接收，一般会采用流式通信模式，例如TCP通信。

众所周知，网络是会出现拥塞现象的：

(1)当多个不同节点同时发送数据包到相同的目标节点时，网络交换机会出现排队，然后依次将数据包转发到目标网络。如果网络负载过重，数据包可能必须等待一段时间才能获得发送机会。如果数据量太大，交换机队列塞满，之后的数据包则会被丢弃。

(2)当数据包到达目标机器后，如果所有CPU核都处于繁忙状态，则网络数据包请求会被操作系统排队，直到应用程序能够处理。根据机器的配置和负载情况，这里也会引入一段不确定的等待时间。

为了满足金融交易软件低延迟的特性，发布端支持多通道并行发布。但是系统底层的发送缓存区是有限的，当接收端不接受数据，或者接收端的处理速率比发布端的发送速率低，导致其接收缓存区已满，进而导致数据发送方的发送缓存区的数据不断堆积甚至缓存区撑满，此时就需要一种应用层的数据缓存管理机制。

由于金融交易软件的传输通信组件需要满足低延迟、高可靠的特性，因此对于应用层的网络数据缓存管理组件也需要具备如下特点：

(1)底层的数据队列管理需要支持高性能的入队出队操作。

(2)支持多线程访问安全，支持发布端使用多线程多通道并行发布模式。

而目前业界尚没有这样的实现上述机制和特点的缓存管理系统。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种应用层网络数据缓存方法，实现通信中间件在性能容量超过极限后于应用层进行的对网络数据缓存进行管理的机制，实现高性能的入队出队的操作，并且对于多网卡的通讯环境，可以让发布端充分利用不同网卡提供的传输通道并行发布主题流，提升吞吐，降低整体延时，且发布端、订阅者支持多线程并行发布及订阅。

本发明的技术方案为：本发明揭示了一种应用层网络数据缓存方法，方法适配于多链路可靠传输通信组件基于线程池机制的多通道并行的发布-订阅机制，多链路可靠传输通信组件包括发布端和接收端，当接收端不接受数据或者接收端的处理速率比发布端的发送速率低，导致其底层的系统接收缓存区已满时，发布端将未成功发送的数据先存入应用层缓存区，直到对应发送通道的系统底层的发送队列有空间后，重新将该应用层缓存区的数据依次写入到发送队列进行发送，应用层网络数据缓存方法包括针对内存管理中的多线程固定内存池分配、针对内存管理中的内存回收、针对内存管理中的线程局部存储、以及发布端进行消息发布的流程。

根据本发明的应用层网络数据缓存方法的一实施例，发布端通过会话容器维护多个会话通道发布主题流的数据，接收端接入多个会话通道收取主题流的消息，其中发布端的各个发布会话独立运行于不同的线程实体内以实现消息的并行发布；对应的，接收端的各个接收会话独立运行于不同的线程实体内以实现消息的并行收取。

根据本发明的应用层网络数据缓存方法的一实施例，对于多网卡的环境，在每个网卡上分配一个会话通道，将主题流的数据发布的任务分摊到各个会话通道上。

根据本发明的应用层网络数据缓存方法的一实施例，针对内存管理中的多线程固定内存池分配的处理进一步配置为：

应用层缓存区的各个内存节点的地址使用快速队列容器保存在一个队列数据结构的线性缓存区中，该线性缓存区是用于维护所有内存节点的基于快速队列的容器，依赖快速队列的先进先出的特性，将未发送完成的数据入队到队尾，再从队首取出数据进行发送，且内存节点的接口层采用链表型式。

根据本发明的应用层网络数据缓存方法的一实施例，针对内存管理中的内存回收的处理进一步配置为：

当使用内存节点时，从线性缓存区中出队一个内存节点，当该内存节点的读和写的位置相同时，该内存节点将读写位置归零，以表示这个内存节点的整块内存都是空闲状态，此时如果线性缓存区拥有至少一个内存节点时，则通过将该空闲的内存节点入队到线性缓存区的操作，来对该空闲的内存节点进行回收。

根据本发明的应用层网络数据缓存方法的一实施例，针对内存管理中的线程局部存储的处理进一步配置为：

使用单例模式建立一个内存节点池工厂，该内存节点池工厂内建一张全局表，该内存节点池工厂使用当前线程编号在内建的全局表中查询各个内存节点池的地址，以使每个线程都拥有自己独立的数据备份。

根据本发明的应用层网络数据缓存方法的一实施例，针对内存管理中的线程局部存储的处理还包括：

当应用层第一次向应用层缓存区存入数据时，应用层缓存区中不存在内存节点，向内存节点池工厂申请内存节点，内存节点池工厂使用当前线程编号找到对应的内存节点池的地址，如果尚未存在对应的内存节点池，则会创建一个新的内存节点池；

内存节点池创建后申请一段固定内存以建立一个内存节点，再在所建立的内存节点上进行数据缓存，所建立的这个内存节点在使用完毕后被回收到所创建的内存节点池中；

当应用层下一次向应用层缓存区存入数据时，内存节点工厂根据当前线程编号找到之前所创建的内存节点池，再从所找到的内存节点池中将之前所建立的这个空闲的内存节点提取出来以在其上进行数据缓存。

根据本发明的应用层网络数据缓存方法的一实施例，发布端进行消息发布的流程进一步包括：

步骤1：发布端开始发布数据，首先确认会话是否处于会话容器中，若处于会话容器则找到对应的会话通道并通过该会话通道调用发送方法，若未处于会话容器中则发送任务结束；

步骤2：每次调用发送方法时，先判断对应的会话通道的应用层缓存区是否为空，如果应用层缓存区为空，则直接调用套接字的发送方法将数据压入到系统层缓存区，并将未成功压入到系统层缓存区的数据放入应用层缓存区；如果应用层缓存区不为空，则将数据直接放入应用层缓存区，通过异步的方式进行发送；

步骤3：当有数据进入应用层缓存区后，立即向输入输出服务中新增一个写数据的信号，通过输入输出服务的机制触发写数据的动作，从应用层缓存区读取最靠前的最大发送字节的数据，应用层缓存区通过出队方式进行数据发送，直到应用层缓存区的数据全部发送完成为止。

本发明对比现有技术有如下的有益效果：本发明具有以下的一些创新之处：(1)提供一个简易的使用接口，使用者无需关心内部如何申请和销毁内存。(2)应用层缓存区的每个内存节点采用快速队列容器，保证了数据追加和读取的高效性。接口层采用链表型式，保证了数据查找的高效性。(3)适配高性能多链路可靠传输通信组件基于线程池机制的多通道并行的“发布-订阅”机制。对于一个主题流，发布端可通过多个会话通道发布主题流的数据，接收端可接入多个会话通道收取主题流消息。发布端的各个发布会话可独立运行于不同的线程实体内，实现消息的并行发布；类似地，接收端的各个接收会话也可以独立运行于不同的线程实体内，实现消息的并行收取。对于多网卡的环境，可以在每个网卡上分配一个会话通道，充分利用多个网卡的传输能力，将数据发布的任务分摊到各个会话通道上，不用担心触及机器性能瓶颈而导致的数据丢失损坏的风险，提升整体吞吐，降低消息延时。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的应用层网络数据缓存方法的应用场景的整体架构示意图。

图2示出了本发明的应用层网络数据缓存方法的实施例中针对内存管理中的多线程固定内存池分配机制的示意图。

图3示出了本发明的应用层网络数据缓存方法的实施例中针对内存管理中的内存回收机制的示意图。

图4示出了本发明的应用层网络数据缓存方法的实施例中针对内存管理中的线程局部存储机制的示意图。

图5示出了本发明的应用层网络数据缓存方法的实施例中针对发布端消息发布的工作流程的示意图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的应用层网络数据缓存方法的应用场景的整体架构。应用层网络数据缓存方法配置在发布端的发送通道上。应用层网络数据缓存方法在该整体架构中所要实现的功能为：当接收端不接受数据，或者接收端的处理速率比发布端的发送速率低，导致接收端底层的系统接收缓存区已满时，发布端将未成功发送的数据先存入应用层缓存区，直到对应发送通道的系统底层的发送队列有空间后，重新将该应用层缓存区的数据依次写入到发送队列进行发送。

如图1所示，适配高性能多链路可靠传输通信组件基于线程池机制的多通道并行的“发布-订阅”机制。对于一个主题流，发布端可通过会话容器维护多个会话通道发布主题流的数据，接收端可接入多个会话通道收取主题流消息。发布端的各个发布会话可独立运行于不同的线程实体(如图1中的线程1至线程n)内，实现消息的并行发布；类似地，接收端的各个接收会话也可以独立运行于不同的线程实体内，实现消息的并行收取。对于多网卡的环境，可以在每个网卡上分配一个会话通道，充分利用多个网卡的传输能力，将数据发布的任务分摊到各个会话通道上，不用担心触及机器性能瓶颈而导致的数据丢失损坏的风险，提升整体吞吐，降低消息延时。

本发明的应用层网络数据缓存方法的实施例包括以下几个部分：图2所示的针对内存管理中的多线程固定内存池分配、图3所示的针对内存管理中的内存回收、图4所示的针对内存管理中的线程局部存储、以及图5所示的发布端进行消息发布的工作流程。

图2示出了本实施例的方法中的针对内存管理中的多线程固定内存池分配机制的实现。

如图2所示，是一个多线程固定内存池分配器进行内存节点分配的原理。应用层缓存区的每个内存节点采用快速队列容器，保证了数据追加和读取的高效性。内存节点的接口层采用链表型式，保证了数据查找的高效性。多线程固定内存池分配器每次向内存节点池thread_catch_pool申请的内存空间称为一个内存节点Catch_node，每个内存节点的地址使用快速队列容器保存在一个队列结构的线性缓存区List_buffer中。每个内存节点初始化时申请固定大小10M的内存空间，每个内存节点内包含有一个整型变量Write_loc来记录这段内存节点当前数据写入的位置，修改这个变量值可以记录当前数据写入后下一次写入的地址。另有一个整型变量read_loc来记录这段内存节点当前数据读取的位置，通过这个变量值可以获取本次数据读取的地址，读取结束后修改这个变量标志了下一次读取的地址。

线性缓存区是用来维护所有内存节点的基于快速队列的容器。对于应用层来说，每个套接字对应一个缓存区，套接字用于在发布端的会话通道上进行数据发送。线性缓存区依赖快速队列的先进先出的特性，将未发送完成的数据入队到队尾，再从队首取出数据进行发送。

图3示出了本实施例的方法中针对内存管理中的内存回收机制的原理。如图3所示，是多线程固定内存池分配器进行内存回收的实现。需要使用内存节点时，从队列数据结构的线性缓存区中pop(队列数据结构的一种公知的操作处理，即出队)出一个内存节点，当一个内存节点的读和写的位置(读取数据的位置是图示的write_loc，写入数据的位置是图示的read_loc)相同时，说明此时并没有新的数据需要进行缓存，内存节点会将读写位置归零，以表示这个内存节点的整块内存都是空闲状态。而此时如果整个线性缓存区拥有不止一个内存节点时，该空闲内存节点即可回收。图3中将内存节点push(队列数据结构的一种公知的操作处理，即入队)到内存节点池的动作，即表示将空闲的内存节点进行回收。

图4示出了本实施例的方法中针对内存管理中的线程局部存储机制，实现了同时支持多线程访问，具有高并发的特点。

线程局部存储技术用于将数据与一个正在执行的指定线程关联。一般而言，进程中的全局变量与函数内定义的静态变量被各个线程共享，若某一个线程对其进行修改，则所有线程都会受到影响，这就引发了线程安全问题。如果使用线程同步就会产生大量的额外开销，同步代码的复杂性也使维护变得困难。如图4所示，本实施例使用单例模式建立一个内存节点池工厂(thread_catch_pool_factory)，该内存节点池工厂内建一张全局表，该内存节点池工厂使用当前线程编号(thread ID)在内建的全局表中查询内存节点池(thread_catch_pool1&2)的地址，以使每个线程(图示的thread1&2)都拥有自己独立的数据备份。

当应用层第一次向应用层缓存区存入数据时，应用层缓存区中不存在内存节点，于是向内存节点池工厂申请内存节点。内存节点池工厂使用当前线程编号找到对应的内存节点池的地址，如果尚未存在对应的内存节点池，则会创建一个新的内存节点池。内存节点池创建后申请一段固定内存以建立一个内存节点，再在所建立的内存节点上进行数据缓存。所建立的这个内存节点在使用完毕后被回收到所创建的内存节点池中。当应用层下一次向应用层缓存区存入数据时，内存节点工厂根据当前线程编号找到之前所创建的内存节点池，再从所找到的内存节点池中将前述所建立的这个空闲的内存节点提取出来以在其上进行数据缓存。

图5示出了本实施例的方法中针对发布端进行消息发布的工作流程。

步骤1：服务端的发布端开始发布数据，首先确认会话是否处于会话容器中，若处于会话容器则找到对应的会话通道并通过这一会话通道调用发送(send)方法，若未处于会话容器中则发送任务结束。

通过图5的流程中可以看出，使用者只要通过简易的调用接口就可以进行数据的发送，无需关心内部如何申请和销毁数据占用的内存。

步骤2：每次调用发送方法时，先判断对应的会话通道的应用层缓存区是否为空，如果应用层缓存区为空，则直接调用套接字的发送方法将数据压入到系统层缓存区，并将未成功压入到系统层缓存区的数据放入应用层缓存区；如果应用层缓存区不为空(说明之前已经有数据的积压)，则将数据直接放入应用层缓存区，通过异步的方式进行发送。

发布端是通过多个会话通道进行消息的发布，其中每一会话通道均位于各自的线程中，每个会话通道均通过套接字进行数据发送。

步骤3：当有数据进入应用层缓存区后，立即向输入输出服务(IO服务)中新增一个写数据的信号，通过IO服务的机制触发写数据的动作，从应用层缓存区读取最靠前的最大发送字节的数据，应用层缓存区通过出队方式进行数据发送，直到应用层缓存区的数据全部发送完成为止。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (8)

1.一种应用层网络数据缓存方法，其特征在于，方法适配于多链路可靠传输通信组件基于线程池机制的多通道并行的发布-订阅机制，多链路可靠传输通信组件包括发布端和接收端，当接收端不接受数据或者接收端的处理速率比发布端的发送速率低，导致其底层的系统接收缓存区已满时，发布端将未成功发送的数据先存入应用层缓存区，直到对应发送通道的系统底层的发送队列有空间后，重新将该应用层缓存区的数据依次写入到发送队列进行发送，应用层网络数据缓存方法包括针对内存管理中的多线程固定内存池分配、针对内存管理中的内存回收、针对内存管理中的线程局部存储、以及发布端进行消息发布的流程。

2.根据权利要求1所述的应用层网络数据缓存方法，其特征在于，发布端通过会话容器维护多个会话通道发布主题流的数据，接收端接入多个会话通道收取主题流的消息，其中发布端的各个发布会话独立运行于不同的线程实体内以实现消息的并行发布；对应的，接收端的各个接收会话独立运行于不同的线程实体内以实现消息的并行收取。

3.根据权利要求2所述的应用层网络数据缓存方法，其特征在于，对于多网卡的环境，在每个网卡上分配一个会话通道，将主题流的数据发布的任务分摊到各个会话通道上。

4.根据权利要求1所述的应用层网络数据缓存方法，其特征在于，针对内存管理中的多线程固定内存池分配的处理进一步配置为：

应用层缓存区的各个内存节点的地址使用快速队列容器保存在一个队列数据结构的线性缓存区中，该线性缓存区是用于维护所有内存节点的基于快速队列的容器，依赖快速队列的先进先出的特性，将未发送完成的数据入队到队尾，再从队首取出数据进行发送，且内存节点的接口层采用链表型式。

5.根据权利要求1所述的应用层网络数据缓存方法，其特征在于，针对内存管理中的内存回收的处理进一步配置为：

当使用内存节点时，从线性缓存区中出队一个内存节点，当该内存节点的读和写的位置相同时，该内存节点将读写位置归零，以表示这个内存节点的整块内存都是空闲状态，此时如果线性缓存区拥有至少一个内存节点时，则通过将该空闲的内存节点入队到线性缓存区的操作，来对该空闲的内存节点进行回收。

6.根据权利要求1所述的应用层网络数据缓存方法，其特征在于，针对内存管理中的线程局部存储的处理进一步配置为：

使用单例模式建立一个内存节点池工厂，该内存节点池工厂内建一张全局表，该内存节点池工厂使用当前线程编号在内建的全局表中查询各个内存节点池的地址，以使每个线程都拥有自己独立的数据备份。

7.根据权利要求6所述的应用层网络数据缓存方法，其特征在于，针对内存管理中的线程局部存储的处理还包括：

当应用层第一次向应用层缓存区存入数据时，应用层缓存区

中不存在内存节点，向内存节点池工厂申请内存节点，内存节点池工厂使用当前线程编号找到对应的内存节点池的地址，如果尚未存在对应的内存节点池，则会创建一个新的内存节点池；

内存节点池创建后申请一段固定内存以建立一个内存节点，再在所建立的内存节点上进行数据缓存，所建立的这个内存节点在使用完毕后被回收到所创建的内存节点池中；

当应用层下一次向应用层缓存区存入数据时，内存节点工厂根据当前线程编号找到之前所创建的内存节点池，再从所找到的内存节点池中将之前所建立的这个空闲的内存节点提取出来以在其上进行数据缓存。

8.根据权利要求1所述的应用层网络数据缓存方法，其特征在于，发布端进行消息发布的流程进一步包括：

步骤1：发布端开始发布数据，首先确认会话是否处于会话容器中，若处于会话容器则找到对应的会话通道并通过该会话通道调用发送方法，若未处于会话容器中则发送任务结束；

步骤2：每次调用发送方法时，先判断对应的会话通道的应用层缓存区是否为空，如果应用层缓存区为空，则直接调用套接字的发送方法将数据压入到系统层缓存区，并将未成功压入到系统层缓存区的数据放入应用层缓存区；如果应用层缓存区不为空，则将数据直接放入应用层缓存区，通过异步的方式进行发送；

步骤3：当有数据进入应用层缓存区后，立即向输入输出服务中新增一个写数据的信号，通过输入输出服务的机制触发写数据的动作，从应用层缓存区读取最靠前的最大发送字节的数据，应用层缓存区通过出队方式进行数据发送，直到应用层缓存区的数据全部发送完成为止。

Images