多区块链交互并发下的数据处理方法、装置及存储介质与流程

本申请涉及区块链技术领域，尤其是涉及一种多区块链交互并发下的数据处理方法、装置及存储介质。

背景技术：

目前，在区块链交易中，每次交易前都需要打开channel中的节点地址端口进行socket连接进行交易；其中，channel在每次使用时都要重新创建，并在使用完成后关闭。而在多区块链交互并发场景下，channel的反复切换、创建和关闭，这就意味着同样的socket连接可能要多次打开/关闭，非常容易造成性能浪费(例如负载过大可能导致的内存溢出等)，甚至可能造成程序崩溃而阻碍业务的流畅性。因此，多区块链的不均匀高并发场景使得channel的复用变得非常困难。当然，虽然也可以将不同区块链区分开成不同的独立程序，各自单独处理一条区块链上的信息；但是，在多条链的场景时需要开发多个java程序，开发与维护的成本巨大，因而并不实用。

因此，如何在多区块链交互并发场景下提高channel的复用是目前亟需解决的技术问题。

技术实现要素：

本申请实施例的目的在于提供一种多区块链交互并发下的数据处理方法、装置及存储介质，以提高多区块链交互并发场景下channel的复用性。

为达到上述目的，一方面，本申请实施例提供了一种多区块链交互并发下的数据处理方法，包括：

在收到交易上链消息后从指定的线程池中取出一个空闲线程；

在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel；

如果该channel是所述交易信息所属区块链对应的channel，则使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首；

如果该channel不是所述交易信息所属区块链对应的channel，则将该channel放至所述双向队列的队尾。

较佳的，所述的多区块链交互并发下的数据处理方法，还包括：

如果所述双向队列为空，则创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。

较佳的，所述的多区块链交互并发下的数据处理方法，还包括：

当从所述双向队列的队首中取channel的次数超过所述双向队列的队列长度，且未匹配到所述交易信息所属区块链对应的channel时，关掉取出的channel，创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。

较佳的，所述的多区块链交互并发下的数据处理方法，所述双向队列的队列长度等于所述线程池的线程池尺寸。

另一方面，本申请实施例还提供了一种多区块链交互并发下的数据处理装置，包括：

取线程模块，用于在收到交易上链消息后从指定的线程池中取出一个空闲线程；

channel匹配模块，用于在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel；

线程第一逻辑模块，用于当该channel是所述交易信息所属区块链对应的channel时，使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首；

线程第二逻辑模块，用于当该channel不是所述交易信息所属区块链对应的channel时，将该channel放至所述双向队列的队尾。

较佳的，所述的多区块链交互并发下的数据处理装置，还包括：

线程第三逻辑模块，用于当所述双向队列为空时，创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。

较佳的，所述的多区块链交互并发下的数据处理装置，还包括：

线程第四逻辑模块，用于当从所述双向队列的队首中取channel的次数超过所述双向队列的队列长度，且未匹配到所述交易信息所属区块链对应的channel时，关掉取出的channel，创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。

较佳的，所述的多区块链交互并发下的数据处理装置，所述双向队列的队列长度等于所述线程池的线程池尺寸。

另一方面，本申请实施例还提供了另一种多区块链交互并发下的数据处理装置，包括存储器、处理器、以及存储在所述存储器上的计算机程序，所述计算机程序被所述处理器运行时执行如下步骤：

在收到交易上链消息后从指定的线程池中取出一个空闲线程；

在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel；

如果该channel是所述交易信息所属区块链对应的channel，则使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首；

如果该channel不是所述交易信息所属区块链对应的channel，则将该channel放至所述双向队列的队尾。

另一方面，本申请实施例还提供了一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

在收到交易上链消息后从指定的线程池中取出一个空闲线程；

在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel；

如果该channel是所述交易信息所属区块链对应的channel，则使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首；

如果该channel不是所述交易信息所属区块链对应的channel，则将该channel放至所述双向队列的队尾。

由以上本申请实施例提供的技术方案可见，本申请实施例可使得使用频率高的channel会更大概率地出现在双向队列的队首，而使用频率低的channel会更大概率地出现在双向队列的队尾；而且，双向队列是可以根据并发时间不同自适应调节的，如某一时段某条区块链交易变多，则对应channel在队列中出现的位置就会靠前。因此，通过这种机制可使最近频繁使用的channel可在下次拿取时优先被取出，从而达到了在多区块链交互并发场景下提高channel复用性的目的。

附图说明

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

图1为本申请一实施例中多区块链交互并发下的数据处理方法的流程图；

图2为本申请另一实施例中多区块链交互并发下的数据处理方法的流程图；

图3为本申请一实施例中多区块链交互并发下的数据处理装置的结构框图；

图4为本申请一实施例中多区块链交互并发下的数据处理装置的结构框图。

具体实施方式

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

本申请以下实施例适用于多区块链交互并发场景，尤其适用于多区块链交互不均匀高并发场景。具体而言，就是一个应用程序要处理多条区块链的交易上链消息，同时不同区块链的交易上链消息可能会有根据时间或场景不同的高并发时段。在这样的场景下，channel的反复切换、创建和关闭，非常容易造成性能浪费。因此，多区块链的不均匀高并发场景使得channel的复用变得非常困难。当然，虽然也可以将不同区块链区分开成不同的独立程序，各自单独处理一条区块链上的信息；但是，在多条链的场景时需要开发多个java程序，开发与维护的成本巨大，因而并不实用。此外，在上述多区块链交互不均匀高并发场景下，如果简单的将所有区块链需要的channel统一保存并遍历并不能有效的优化时间和内存。鉴于上述存在的技术难题，本申请的发明人经过研究，提出了以下解决方案(具体如下文所述)。

在本申请以下实施例中，channel是指一个通道，其代表一条区块链(或者channel与区块链一一对应)，具体可是包含一系列peer(节点)，orderer(排序节点)与eventhub(事件集线器)的ip与端口。在通讯时一条channel会在本地打开一个空闲的端口向channel内保存的部分端口连接进行通讯，每一个channel可代表一条区块链在java中的一个客户端实例。

参考图1所示，本申请一实施例的多区块链交互并发下的数据处理方法可以包括以下步骤：

s101、在收到交易上链消息后从指定的线程池中取出一个空闲线程。

在本申请一实施例中，当区块链中的节点准备发送一条交易上链时，可以先对信息进行封装从而生成交易上链消息，并将交易上链消息提供给节点的发送模块。当然，在此之前，可以先要进行一系列区块链的初始化动作，例如可以包括注册证书，创建channel，安装合约，初始化合约等。

其中，所述交易上链消息例如可以包括交易信息(例如交易时间、交易内容等)、交易上链对应的区块链标识(即交易准备上的区块链的区块链标识)等。然后，可从指定的线程池中取出一个空闲线程来处理交易上链消息。如果线程池中当前没有可用线程(即空闲线程)，则可以同步阻塞等待，直到出现空闲的线程。当然，在其他实施例中，根据实际需要，如果线程池中当前没有可用线程，也可以通过同步非阻塞、异步阻塞或异步非阻塞等等待方式实现。

在本申请一实施例中，可在业务逻辑开始前预先创建好线程池，并可在程序结束前回收。使用线程池能够防止过高的并发占用过多内存资源可能导致的系统崩溃。其中，线程池的大小(或称为尺寸)决定了节点可以同时处理的并发交易上链消息数量，因而线程池越大，节点并发处理性能越好，但同时对内存的要求也越高。因此，线程池的大小需根据具体情况合理设置。此外，线程用完后需要放回线程池。

s102、在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel。如果是，则执行步骤s103；否则执行步骤s104。

在本申请一实施例中，在从指定的双向队列的队首中取出一条channel之前，节点的发送模块还可以做一些预处理；例如在收到一条交易上链消息后，先进行消息的拆封，以解析出需要上链的交易信息(包括消息内容，对应的区块链场景等)，具体可取决于业务需求。

在本申请一实施例中，由于交易上链消息内携带有交易上链对应的区块链标识，且channel与区块链一一对应；因此，通过将取出的channel的channel标识与交易上链消息内携带的区块链标识进行匹配，就可以确定该channel是否为所述交易上链消息所属区块链对应的channel。

在本申请一实施例中，在业务逻辑开始前需要先创建好双向队列。这里的双向队列为一种数据结构，可以储存信息，并可以由队首或队尾将数据取出或存入。在一示例性实施例中，所述双向队列例如可以是双向链表等。在java中双向链表通常表示为linkedlist，是链表的一种，它的每个数据节点中都有两个指针，可分别指向直接后继和直接前驱。因而，通过双向链表可以非常快速的访问队列的头尾元素和构建双向的循环。一般的，现今在java程序中使用某种数据结构管理高并发情景对象的生命周期是很常见的行为，而本申请实施例主要针对于区块链中不同场景交错并发且并发频率不同的情况，使用双向链表实现可具有更优秀的效率。

在本申请一些实施例中，考虑到线程池尺寸过大可能会导致队尾进入的channel花费太长时间到队首，而线程池尺寸过小又可能会导致队列溢出以及部分线程过多创建新channel而资源浪费；因此，线程池尺寸的大小需要合理设置。类似的，双向队列也需要合理设置。假设一共有n个线程，m条区块链，理论上需要m*n的队列长度才可以实现不重复队列，然而，如果这样可能会有大量的冗余channel闲置，从而容易造成空间浪费。较佳的，所述双向队列的队列长度可等于所述线程池的线程池尺寸。如此，使用n的队列长度就保证了在程序高度繁忙时也可以保证每个线程都可以分配到channel。因此，将双向队列长度设置为线程池长度，在程序稳定运行后可有利于保证系统处于较佳的运算效率与内存占用。此外，在具体的开发过程中，可以根据并发频率与交易种类数量调整队列长度以优化性能。

s103、如果该channel是所述交易信息所属区块链对应的channel，则使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首。

在本申请一实施例中，如果channel是交易信息所属区块链对应的channel，则节点的发送模块利用该channel以函数调用或者远程传送等方式进行交易上链。

s104、如果该channel不是所述交易信息所属区块链对应的channel，则将该channel放至所述双向队列的队尾。

由此可见，在本申请一些实施例中，可将每一条区块链交易需要的channel保存在一个双向队列里(具体而言，是将需要的channel放在双向队列的队首，不需要的channel放在双向队列的队尾)，而在交易结束后不立即关闭channel，而是使用双向队列的数据结构将channel保存起来。而在上述步骤的循环反复中，使用频率高的channel会更大概率地出现在双向队列的队首，而使用频率低的channel会更大概率地出现在双向队列的队尾。而且双向队列是可以根据并发时间不同自适应调节的，如某一时段某条区块链交易变多，则对应channel在队列中出现的位置就会靠前。因此，通过这种机制可使最近频繁使用的channel可在下次拿取时优先被取出，从而达到了在多区块链交互并发场景下提高channel复用性的目的。

在本申请另一实施例的多区块链交互并发下的数据处理方法中，如果所述双向队列为空，则创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。在交易开始的初期，线程由于在队列中没有得到自己需要的channel，可能会比较多的创建channel，这种情况在交易并发情况大量改变的时候也会出现，而当交易并发趋近于稳定时，线程很大概率可以双向从队列中优先取出自己需要的channel，而不必关闭不需要channel再创建新的channel。

在本申请另一实施例的多区块链交互并发下的数据处理方法中，当从所述双向队列的队首中取channel的次数超过所述双向队列的队列长度，且未匹配到所述交易信息所属区块链对应的channel时，关掉取出的channel，创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。有基于此，本申请另一些实施例中，多区块链交互并发下的数据处理方法可如图2所示。在图2中，判断当前取出的channel是否可以用是指判断当前取出的channel是否为所述交易上链消息所属区块链对应的channel。在本申请实施例中，使用双向队列长度与多次取channel不可用后创建新channel的判断，防止出现程序不停从双向链取channel的死循环。此外，将取channel的次数上限设置为线程池长度，也可有助于在程序稳定运行后保证较佳的运算效率与内存占用。

参考图3所示，本申请实施例的一种多区块链交互并发下的数据处理装置可以包括：

取线程模块31，可以用于在收到交易上链消息后从指定的线程池中取出一个空闲线程；

channel匹配模块32，可以用于在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel；

线程第一逻辑模块33，可以用于当该channel是所述交易信息所属区块链对应的channel时，使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首；

线程第二逻辑模块34，可以用于当该channel不是所述交易信息所属区块链对应的channel时，将该channel放至所述双向队列的队尾。

本申请另一实施例中，多区块链交互并发下的数据处理装置还可以包括：

线程第三逻辑模块，其可以用于当所述双向队列为空时，创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。

本申请另一实施例中，多区块链交互并发下的数据处理装置还可以包括：

线程第四逻辑模块，其可以用于当从所述双向队列的队首中取channel的次数超过所述双向队列的队列长度，且未匹配到所述交易信息所属区块链对应的channel时，关掉取出的channel，创建一条所述交易信息所属区块链对应的channel，使用该channel发送所述交易信息，并在使用后将该channel放至所述双向队列的队首。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

参考图4所示，本申请实施例的另一种多区块链交互并发下的数据处理装置，包括存储器、处理器、以及存储在所述存储器上的计算机程序，所述计算机程序被所述处理器运行时执行如下步骤：

在收到交易上链消息后从指定的线程池中取出一个空闲线程；

在所述空闲线程内，解析所述交易上链消息获得交易信息，从指定的双向队列的队首中取出一条channel，并确定该channel是否为所述交易信息所属区块链对应的channel；

如果该channel是所述交易信息所属区块链对应的channel，则使用该channel发送所述交易信息，并在使用后将该channel放回至所述双向队列的队首；

如果该channel不是所述交易信息所属区块链对应的channel，则将该channel放至所述双向队列的队尾。

虽然上文描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。