具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

实施例一

图1是本申请实施例一提供的一种分布式图数据库数据处理方法的流程图，本实施例可适用于利用分布式图数据库对数据进行处理，如向分布式图数据库写入或者读取数据的情况。该方法可以由本申请实施例所提供的分布式图数据库数据处理装置执行，该装置可以由软件和/或硬件的方式来实现，并可集成于运行此系统的电子设备中。

如图1所示，所述分布式图数据库数据处理方法包括：

S110、获取数据处理请求，并根据数据处理请求类型和处理节点角色之间的关联关系，确定处理所述数据处理请求的节点角色作为目标角色。

其中，数据处理请求包括分布式图数据库对应的分布式节点获取到的外部用户的发送的外部数据处理请求，具体的外部数据处理请求包括：数据写入请求、数据读取请求或者数据分析请求中的至少一种。也可以包括，分布式节点在对外部数据处理请求进行处理的过程中，产生的需要分布式节点处理的内部数据处理请求，示例性的，包括：日志写入请求和反馈信息如日志写入成功消息、写入成功消息。其中，分布式图数据库可以为分布式图数据库。

数据处理请求类型和处理节点角色之间的关联关系是由相关技术人员根据实际业务需求预先确定并写入各分布式节点的。关于数据处理请求类型和处理节点角色质之间的关联关系在这里不作限定，具体依据实际情况确定。具体的，本申请中分布式图数据库数据处理采用读写分离的设计，负责处理数据写入请求的节点角色不同于负责处理数据写入请求的节点角色。

在一个可选的实施例中，所述节点角色包括：头节点、尾节点和学习者节点中的至少一种；所述节点角色是根据各分布式节点的性能属性预先确定的。

具体的，节点角色是由元数据服务器根据各分布式节点的性能属性，如资源利用率和数据吞吐量确定的，可选的，在分布式节点中选择性能较优的节点作为头节点、尾节点和学习者节点，在剩余分布式节点中选择中间节点。其中，头节点、尾节点和学习者节点的数量为1，中间节点的数量可以根据实际业务需求确定，具体的，中间节点的数量可以根据分布式图数据库数据备份的数量确定，在这里不作限定。示例性的，若分布式图数据库通过三副本的方式保证数据的可靠性和可用性，则除去头节点和尾节点，仅需设置一个中间节点即可；若分布式图数据库通过四副本的方式保证数据的可靠性和可用性，则除去头节点和尾节点，还需设置两个中间节点。

可选的，在处理外部数据处理请求的情况下，头节点负责处理数据写入请求；尾节点负责处理数据读取请求；学习者节点负责处理数据分析请求。也就是说，对应于数据写入请求的目标角色为头节点；对应于数据读取请求的目标角色为尾节点；对应于数据分析请求的目标角色为学习者节点。

所属于分布式图数据库系统的分布式节点均可能接收到数据处理请求，获取到数据处理请求的分布式节点，可以确定数据请求的类型，并根据预先配置的数据处理请求类型和处理节点角色之间的关联关系，确定处理数据处理请求的节点角色作为目标角色。

S120、获取当前角色信息，若当前角色与所述目标角色相匹配，则根据预设数据处理规则对所述数据处理请求进行处理。

分布式图数据库系统中的分布式节点可能出现宕机等异常情况，以及分布式节点性能属的变化均会导致分布式节点的角色会发生改变。可能发生的网络分区的情况，会导致分布式节点本地保存的节点角色没有及时更新。因此，分布式节点在接收到数据处理请求以后，需要从元数据服务器获取当前角色信息，并根据当前角色信息更新原有角色信息。其中，当前角色信息包括分布式图数据库系统中全部的分布式节点的当前角色。也就是，当前角色信息中既包括自己的当前角色也包括其他分布式节点的当前角色。

接收到待处理数据处理请求的分布式节点，在获取到当前角色信息以后，根据将自己的当前角色与目标角色进行匹配，如果当前角色与目标角色一致，则根据预设数据处理规则对数据处理请求进行处理。其中，预设数据处理规则与数据处理请求的类型相关。不同类型的数据处理请求对应的预设数据处理规则存在差异。预设数据处理规则的具体内容在这里不作限定，具体依据实际情况确定，示例性的，预设数据处理规则可以是数据处理请求的转发、数据的读取或者写入等。

若收到数据处理请求的分布式节点的当前角色与目标角色不匹配。则收到数据处理请求的节点则将根据已经获取到的当前信息，将接收到的数据处理请求转发给当前角色为目标角色分布式节点。由当前角色为目标角色的节点根据预设数据处理规则对数据处理请求进行处理。

具体的，在一个可选的实施例中，所述当前角色为尾节点；目标角色与当前角色相匹配，相应的，根据预设数据处理规则对所述数据处理请求进行处理，包括： 响应于接收到数据读取请求，根据所述数据读取请求在本地图数据库中读取待读取数据，并反馈所述待读取数据。

尾节点响应于接收到数据读取请求，根据数据读取请求在自己维护的本地图数据库中读取待读取数据，并反馈待读取数据，具体的可以将读取到的待读取数据通过分布式图数据库系统中的计算层反馈给用户。其中，数据读取请求是事务型的数据读取请求，例如外部用户产生的数据查询请求。

在一个可选的实施例中，所述当前角色为学习者节点；目标角色与当前角色相匹配，相应的，根据预设数据处理规则对所述数据处理请求进行处理，包括：响应于接收到数据分析请求，根据所述数据分析请求在本地图数据库中读取待分析数据，并反馈所述待分析数据。

学习者节点响应于接收到数据分析请求，根据数据分析请求在自己维护的本地图数据库中读取待分析数据，并反馈待分析数据。具体的可以将读取到的待分析数据通过分布式图数据库系统中的计算层反馈给用户。其中，数据分析请求是分析型的数据读取请求，例如外部用户产生的社区挖掘请求。

值得注意的是，设置在分布式图数据库系统中的计算层，定义有处理数据处理请求的核心逻辑，与分布式节点对应的底层图数据库负责提供基础的数据支持。本申请不对分布式图数据库系统中的计算层进行展开描述，重点关注分布式数据也就是分布式节点的数据处理过程。计算层在处理数据读取请求的过程中，由尾节点提供数据支持。计算层在处理数据分析请求的过程中，由学习者节点提供数据支持。

之所以在处理数据读取请求和数据分析请求的过程中，对节点角色进行区分，是尾节点和学习者节点的不同的数据存储方式决定的。这样做可以使分布式图数据库可以更好的支持HTAP（Hybrid Transaction and Analytical Processing，混合事务和分析处理）业务。在一个可选的实施例中，学习者节点以列存储的方式进行数据存储，尾节点以行存储的方式进行数据存储。其中，学习者节点的特殊数据存储方式使得在计算层进行数据分析时，从学习者节点中读取待分析数据更加有效。通常情况下，分布式图数据库进行图数据存储时是将数据以行存储的方式进行存储。行存储的存储方式，点边和各自的属性值是存储在一起。图数据的数据写入效率高，可以保证数据完整性，能够满足图数据的快速查询需求。但是行存储的方式会存在数据冗余。若以行存储的方式进行数据存储，在进行图分析时会读取出很多并不需要的属性数据。相对而言，列存储的存储方式数据读取效率更高，没有数据冗余，有效数据可紧凑的存储在一起，相同的属性值被存储在一起，同时点和边的连接则用更紧凑的CSR（compressed sparse row）存储在一起，可以极大地提升图分析性能。

在一个可选的实施例中，所述当前角色为头节点；目标角色与当前角色相匹配，相应的，根据预设数据处理规则对所述数据处理请求进行处理，包括：响应于接收到数据写入请求，获取当前各分布式节点的角色信息和通信地址；根据各分布式节点的所述当前角色和所述通信地址，确定目标组播组地址；将所述数据写入请求转发给与所述目标组播组地址关联的节点，以使与所述目标组播组地址关联的节点将所述数据写入请求写入日志。

在分布式图数据库处理数据写入请求的过程中，通常会通过数据备份的手段来保证数据的一致性和可用性。也就是，相同的数据会在分布式图数据库中存储多份副本。为了保证数据可用性可以不受副本数量的影响，本申请实施例采用使用组播复制协议对数据进行实时复制得到数据副本，由头节点负责将数据写入请求广播给需要存储数据的分布式节点，由其进行数据存储得到副本。

为了避免由于网络分区导致节点角色更新不及时的问题，头节点在接收到数据写入请求以后，需要再次向从元数据服务器中获取各分布式节点的最新的角色信息和通信地址，并根据分布式节点的当前角色和通信地址确定目标组播组地址。其中，目标组播组地址为需要存储副本的分布式节点的通信地址。具

体的，头节点将当前角色为尾节点和中间节点的通信地址加入目标组播组地址。目标组播组地址中还包括头节点本身的通信地址。头节点将数据写入请求转发给与目标组播组地址关联的节点，与目标组播组地址关联的节点将数据写入请求写入日志。其中，数据写入请求包括待写入数据。

目标组播组地址关联的节点将数据写入请求写入日志以后，会生成日志写入成功消息，并将日志写入成功消息发送给尾节点。

为了进一步提高分布式图数据库的数据处理效率，充分发挥分布式图数据库系统的性能，在分布式图数据库系统处理外部数据处理请求如数据写入请求的过程中产生的内部处理请求，也由不同角色节点进行处理。

在一个可选的实施例中，当前角色为尾节点，目标角色与当前角色相匹配，相应的，根据预设数据处理规则对所述数据处理请求进行处理，包括：响应于接收到日志写入成功消息，统计所述日志成功消息的数量；其中，所述日志成功消息由所述目标组播组地址关联的节点发送； 根据在设定时长内获取到的所述日志写入成功消息的数量和与所述目标组播组地址相关联的节点数量，生成反馈信息，并将所述反馈信息广播给与所述目标组播组地址相关联的节点。

尾节点响应于接受到日志写入成功消息，统计日志成功消息的数量；日志成功消息是由目标组播组地址中头节点和中间节点在日志写入成功以后，产生并发送给尾节点的。其中，尾节点本身在将数据写入请求成功写入日志以后也会产生的日志写入成功消息。在尾节点统计日志成功消息数量的过程中，由尾节点自身产生的日志写入成功消息计算在内。尾节点根据在设定时长内获取到的日志写入成功消息的数量和与目标组播组地址相关联的节点数量，生成反馈信息，并将所述反馈信息广播给与所述目标组播组地址相关联的节点。

其中，设定时间是由相关技术人员根据实际业务需求确定的，具体数值在这里不作限定。若尾节点在设定时间内获取到的日志写入成功消息的数量和与目标组播组地址关联的节点数量一致，则表明全部需要存储副本的分布式节点均已收到数据写入请求，且已将数据写入请求写入日志。此时，尾节点生成的反馈信息为写入成功消息；尾节点将生成的写入成功消息广播给与目标组播组地址相关联的节点，可选的，目标组播组地址中还可以包括角色为学习者节点的地址，但是学习者节点在接收到头节点转发的数据写入请求以后并不会将数据写入请求写入日志，也不会向头节点反馈日志情况。只有在接收到尾节点广播的写入成功消息以后，学习者节点才会与头节点和中间节点将数据写入请求中的待写入数据进行存储。同时，尾节点也会将数据写入请求中的待写入数据进行存储。可选的，头节点和尾节点以行存储的方式进行数据存储，学习者节点以列存储的方式进行数据存储。值得注意的是，在目标组播组地址中包括学习者节点的情况下，由于学习者并不会将数据写入请求写入日志，也不会向头节点反馈日志情况，因此目标组播组地址关联的节点数量应该减去学习者节点的数量。

为了保证数据一致性和可用性，尾节点只有在与目标组播组地址相关联的全部节点均日志写入成功以后，才会生成并广播写入成功消息。与目标组播组地址相关联的各节点也只有在接收到尾节点广播的写入成功消息以后，才会将数据写入请求中的待写入数据进行存储。

若尾节点在设定时间内获取到的日志写入成功消息的数量和与目标组播组地址关联的节点数量不一致，这种情况下，尾节点不会生成反馈信息。这表明存在分布式节点宕机或者网络中断等异常情况使得需要存储副本的分布式节点未能将数据写入请求成功写入日志。

为了保证分布式图数据库系统能够可靠稳健的运行，元数据服务器会在分布式图数据库系统运行过程中，对分布式图数据库系统中各分布式节点的运行状态进行监控。在元数据服务器监测到分布式节点运行状态异常的情况下，元数据服务器会发起视图变更（view change）来更新整个集群的状态。具体的，元数据服务器可以通过更换数据存放节点，重新指定节点角色的方式来更新整个集群状态。示例性的，元数据服务器可以根据分布式节点的工作状态和性能属性，选择处于空闲状态且性能较优的分布式节点替代运行状态异常的分布式节点，来更新节点角色。元数据服务器会根据节点更新情况生成节点角色更新信息，并将节点角色更新信息在分布式图数据库系统中广播，以供分布式节点根据元数据服务器广播的节点角色更新信息来更新自身当前角色以及本地存储的其他分布式节点的当前角色信息。在元数据服务器发起的视图变更（view change）结束后，分布式图数据库系统会在新节点角色配置下，恢复数据处理流程，数据处理流程恢复后，分布式图数据库系统可继续为外部用户提供数据处理服务。在一个可选的实施例中，当前角色为头节点，目标角色与当前角色相匹配；相应的，根据预设数据处理规则对所述数据处理请求进行处理，包括：响应于接收到节点角色更新信息，根据所述节点角色更新信息更新所述目标组播组地址；根据更新后的所述组播组地址，将所述数据写入请求转发给与更新后的所述组播组地址关联的节点。

其中，节点角色更新信息是由元数据服务器产生的，具体的分布式图数据库系统中所有分布式节点均可以都通过心跳监听元数据服务器广播的更新信息，一旦元数据服务器更新集群状态后，所有分布式节点都会监听到节点角色更新信息，并根据节点角色更新信息更新各分布式节点的当前角色信息。当然，在元数据服务器在进行集群状态更新的过程中，也可能产生新的头节点。

头节点响应于接收到角色更新信息，根据节点角色更新信息更新目标组播组地址。其中，头节点即为元数据服务器在进行集群状态更新的过程指定的头节点。头节点根据节点角色更新信息更新目标组播组地址，具体的，头节点可以根据节点角色更新信息，重新构建新目标组播组地址，直接利用新目标组播组地址更新之前的旧目标组播组地址。还可以根据节点角色更新信息将运行状态异常的节点从目标组播组中剔除，将替代节点加入目标组播组得到更新后的目标组播组地址。

头节点根据更新后的组播组地址，将数据写入请求转发给与更新后的组播组地址关联的节点，以使与更新后的组播组地址关联的各节点，将数据写入请求写入日志。

本申请实施例所提供的技术方案，通过获取数据处理请求，并根据数据处理请求类型和处理节点角色之间的关联关系，确定处理所述数据处理请求的节点角色作为目标角色；获取当前角色信息，若当前角色与所述目标角色相匹配，则根据预设数据处理规则对所述数据处理请求进行处理。本申请通过对分布式图数据库对应节点进行角色区分，节点角色与数据处理请求类型相关联。不同角色的节点处理不同类型的数据处理请求。数据的处理不再仅依赖于一种角色的节点，能够提高分布式图数据库的数据处理效率，充分发挥分布式图数据库的数据处理性能。

在一个具体的实施例中，在分布式图数据库系统中头节点接收到数据写入请求的情况下，分布式图数据库对数据处理方法的流程为：头节点在接受到数据写入请求后，从元数据服务器中获取当前各分布式节点的角色信息和通信地址；将角色为中间节点、学习者节点和尾节点的分布式节点的通信地址添加至目标组播组地址中，并将数据写入请求广播给与目标组播组地址关联的分布式节点。其中，数据写入请求中包括待写入数据，分布式节点间的采用grpc通信的网络通信方式。中间节点和尾节点接收到由头节点发送的数据写入请求以后，将数据写入请求写入日志。并将在日志写入成功以后生成日志写入成功消息，发送给尾节点，由尾节点统计日志写入成功消息的消息数量，并根据消息数量和应发消息节点的节点数量生成广播反馈信息。头节点和中间节点向尾节点反馈日志写入情况的过程即为确定数据一致性的过程。值得注意的是，学习者节点并不参与数据一致性的确定过程中，学习者节点在接收到由头节点转发的数据处理请求以后，无需将数据处理请求写入到日志中，学习者节点也不用向尾节点反馈日志写入情况。

只有在尾节点广播写入成功信息的情况下，学习者节点才会与头节点、尾节点和中间节点将数据写入请求中的待写入数据进行存储。具体的，学习者节点，先将待写入数据缓存到内存中，当缓存达到一定的大小后，通过batch的方法写入到存储中。此时，即可认定数据处理请求已处理完毕，待写入数据已成功备份。

分布式图数据库系统中还设置有元数据服务，用于在分布式图数据库系统运行过程中，对分布式图数据库系统中各分布式节点的运行状态进行监控。在元数据服务器监测到分布式节点运行状态异常的情况下，元数据服务器会发起视图变更（view change）来更新整个集群的状态。具体的，元数据服务器可以通过更换数据存放节点，重新指定节点角色的方式来更新整个集群状态，元数据服务器还会根据节点更新情况生成节点角色更新信息，并将节点角色更新信息在分布式图数据库系统中广播，以供分布式节点根据元数据服务器广播的节点角色更新信息来更新自身当前角色以及本地存储的其他分布式节点的当前角色信息。

当前角色为头节点的分布式节点根据节点角色更新信息更新目标组播组地址，并根据更新后的组播组地址，将数据写入请求转发给与更新后的组播组地址关联的节点，再次执行上述过程，直到待写入数据备份成功向用户反馈写入成功的消息。

目前，因为Raft协议易于理解和实现，分布式图数据库的数据复制协议大多使用Raft协议。但是Raft协议是通过Quorum机制即投票机制进行工作的，需要超过半数的节点参与才能工作。因此在两副本的情况下，Raft需要收集到两个副本的投票才可以进行每一个日志的复制。此时如果一个节点宕机，在剩下一个副本的情况下，Raft协议无法继续工作。

而本申请是利用组播复制协议对数据进行实时复制实现数据备份，来保证数据的强一致性，高可用性。其中，数据写入请求由头节点处理，由头节点负责将数据写入请求广播给其他的节点。当数据都存储完成之后，数据写入请求才处理完成，组播复制协议并不是通过投票机制工作的，而是组播全复制的方式进行工作，因此即使只剩下一个副本，组播复制协议也可以继续工作。因此即使是一个副本的情况下也可以分布式图数据库对外提供服务（两个副本中一个宕机的情况）。

不同于Raft协议中所有的数据读写都要通过领导者节点进行，本申请采用读写分离技术，本申请的数据读取请求由尾节点处理，数据分析请求由尾节点处理，可以大大的提高热点数据读写的吞吐量，充分发挥了分布式图数据库的数据处理性能，在读密集负载的情况下提供更高、更稳定的性能。

本申请中组播复制协议中所有节点的角色都由元数据服务器来指定。当节点的状态发生变化，如存在节点宕机情况，在恢复过程中所有节点的角色也都由元数据服务器来指定，而非通过选举协议来决定。节点状态由元数据服务器直接管理，而不是通过复制协议参与管理，极大的减少了系统的复杂度和开发难度。

实施例二

图2是本申请实施例二提供的一种分布式图数据库数据处理装置的结构示意图，本实施例可适用于利用分布式图数据库对数据进行处理，如向分布式图数据库写入或者读取数据的情况。所述装置可由软件和/或硬件实现，可集成于运行此系统的电子设备中。

如图2所示，该装置可以包括：目标角色确定模块310和数据处理模块320。

目标角色确定模块310，用于获取数据处理请求，并根据数据处理请求类型和处理节点角色之间的关联关系，确定处理所述数据处理请求的节点角色作为目标角色；

数据处理模块320，用于获取当前角色信息，若当前角色与所述目标角色相匹配，则根据预设数据处理规则对所述数据处理请求进行处理。

本申请实施例所提供的技术方案，通过获取数据处理请求，并根据数据处理请求类型和处理节点角色之间的关联关系，确定处理所述数据处理请求的节点角色作为目标角色；获取当前角色信息，若当前角色与所述目标角色相匹配，则根据预设数据处理规则对所述数据处理请求进行处理。本申请通过对分布式图数据库对应节点进行角色区分，节点角色与数据处理请求类型相关联。不同角色的节点处理不同类型的数据处理请求。数据的处理不再仅依赖于一种角色的节点，能够提高分布式图数据库的数据处理效率，充分发挥分布式图数据库的数据处理性能。

可选的，其中，所述节点角色包括：头节点、尾节点和学习者节点中的至少一种；所述节点角色是根据各分布式节点的性能属性预先确定的。

可选的，其中，所述当前角色为头节点；相应的，数据处理模块320，包括：信息获取子模块，用于响应于接收到数据写入请求，获取当前各分布式节点的角色信息和通信地址；目标组播组地址确定子模块，用于根据各分布式节点的所述当前角色和所述通信地址，确定目标组播组地址；数据写入请求转发子模块，用于将所述数据写入请求转发给与所述目标组播组地址关联的节点，以使与所述目标组播组地址关联的节点将所述数据写入请求写入日志。

可选的，所述当前角色为尾节点，相应的，数据处理模块320，包括：消息数量统计子模块，用于响应于接收到日志写入成功消息，统计所述日志成功消息的数量；其中，所述日志成功消息由所述目标组播组地址关联的节点发送； 反馈信息生成子模块，用于根据在设定时长内获取到的所述日志写入成功消息的数量和与所述目标组播组地址相关联的节点数量，生成反馈信息，并将所述反馈信息广播给与所述目标组播组地址相关联的节点。

可选的，其中，所述当前角色为头节点；相应的，数据处理模块320，包括：节点角色更新信息轮询子模块，用于响应于接收到节点角色更新信息；数据写入请求再次转发子模块，用于根据所述节点角色更新信息更新所述目标组播组地址，并根据更新后的所述组播组地址，将所述数据写入请求转发给与更新后的所述组播组地址关联的节点。

可选的，其中，所述当前角色为学习者节点；相应的，数据处理模块320，包括：待写入数据存储模块，具体用于响应于接收到写入成功消息，将所述数据写入请求中待写入数据以列存储的方式进行存储。

可选的，其中，所述当前角色为尾节点；相应的，数据处理模块320，包括： 数据读取请求处理子模块，具体用于响应于接收到数据读取请求，根据所述数据读取请求在本地图数据库中读取待读取数据，并反馈所述待读取数据。

可选的，其中，所述当前角色为学习者节点；相应的，数据处理模块320，包括：数据分析请求处理子模块，具体用于响应于接收到数据分析请求，根据所述数据分析请求在本地图数据库中读取待分析数据，并反馈所述待分析数据。

本发明实施例所提供的一种分布式图数据库数据处理装置可执行本发明任意实施例所提供的一种分布式图数据库数据处理方法，具备执行一种分布式图数据库数据处理方法相应的性能模块和有益效果。

实施例三

本申请实施例三还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种分布式图数据库数据处理方法，该方法包括：

获取数据处理请求，并根据数据处理请求类型和处理节点角色之间的关联关系，确定处理所述数据处理请求的节点角色作为目标角色；

获取当前角色信息，若当前角色与所述目标角色相匹配，则根据预设数据处理规则对所述数据处理请求进行处理。

存储介质是指任何的各种类型的存储器电子设备或存储电子设备。术语“存储介质”旨在包括：安装介质，例如CD-ROM、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如DRAM、DDR RAM、SRAM、EDO RAM，兰巴斯(Rambus)RAM等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到计算机系统。第二计算机系统可以提供程序指令给计算机用于执行。术语“存储介质”可以包括可以驻留在不同未知中(例如在通过网络连接的不同计 算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的分布式图数据库数据处理方法，还可以执行本申请任意实施例所提供的分布式图数据库数据处理方法中的相关操作。

实施例四

本申请实施例四提供了一种电子设备，该电子设备中可集成本申请实施例提供的分布式图数据库数据处理装置，该电子设备可以是配置于系统内的，也可以是执行系统内的部分或者全部性能的设备。图3是本申请实施例四提供的一种电子设备的结构示意图。如图3所示，本实施例提供了一种电子设备400，其包括：一个或多个处理器420；存储装置410，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器420执行，使得所述一个或多个处理器420实现本申请实施例所提供的分布式图数据库数据处理方法，该方法包括：

获取数据处理请求，并根据数据处理请求类型和处理节点角色之间的关联关系，确定处理所述数据处理请求的节点角色作为目标角色；

获取当前角色信息，若当前角色与所述目标角色相匹配，则根据预设数据处理规则对所述数据处理请求进行处理。

当然，本领域技术人员可以理解，处理器420还实现本申请任意实施例所提供的分布式图数据库数据处理方法的技术方案。

图3显示的电子设备400仅仅是一个示例，不应对本申请实施例的性能和使用范围带来任何限制。

如图3所示，该电子设备400包括处理器420、存储装置410、输入装置430和输出装置440；电子设备中处理器420的数量可以是一个或多个，图3中以一个处理器420为例；电子设备中的处理器420、存储装置410、输入装置430和输出装置440可以通过总线或其他方式连接，图3中以通过总线450连接为例。

存储装置410作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块单元，如本申请实施例中的分布式图数据库数据处理方法对应的程序指令。

存储装置410可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个性能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储装置410可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置410可进一步包括相对于处理器420远程设置的存储器，这些远程存储器可以通过网络连接。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置430可用于接收输入的数字、字符信息或语音信息，以及产生与电子设备的用户设置以及性能控制有关的键信号输入。输出装置440可包括显示屏、扬声器等电子设备。

上述实施例中提供的分布式图数据库数据处理装置、介质及电子设备可执行本申请任意实施例所提供的分布式图数据库数据处理方法，具备执行该方法相应的性能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的分布式图数据库数据处理方法。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。