CN111368002A - 一种数据处理方法、系统、计算机设备和存储介质 - Google Patents

Abstract

本发明提供了一种数据处理方法、系统、计算机设备和存储介质，其方法包括：Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；所述主节点向所述集群中所有的从节点广播所述日志数据；主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。能够基于raft算法实现分布式消息存储多副本机制可以很好实现消息存储强一致性、高可靠、高可用等优点。

Description

一种数据处理方法、系统、计算机设备和存储介质

技术领域

本发明涉及数据处理技术领域，尤指一种数据处理方法、系统、计算机设备和存储介质。

背景技术

自分布式系统出现，系统容灾和一致性成为了经常被讨论的话题。分布式消息存储系统采用的是主从模式架构，其不足点在于：1、缺乏容灾高可用性，不能自动控制节点切换，一旦出了问题需要人为介入手动切换，这就需要运维人员时刻在线处理节点异常。2、数据完整性无法保证，主从模式会存在数据丢失的可能。

发明内容

本发明的目的是提供一种数据处理方法、系统、计算机设备和存储介质，能够基于分布式消息存储多副本机制实现消息存储强一致性、高可靠、高可用。

本发明提供的技术方案如下：

一方面，本发明提供了一种数据处理方法，包括：Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；所述主节点向所述集群中所有的从节点广播所述日志数据；所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。

在一个实施例中，所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈，包括：所述主节点接收所述从节点反馈的存储信息，所述存储信息记载了所述从节点是否存储所述日志数据；所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈。

在一个实施例中，所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈，具体包括：所述主节点对所述从节点反馈的所述存储结果进行仲裁，判断所述集群中是否有超过一半数量的从节点存储了所述日志数据，若是，所述主节点向所述客户端反馈写入成功通知；若否，所述主节点向所述客户端反馈写入失败通知。

在一个实施例中，所述方法还包括：当Dledger集群接收到客户端发起的写请求时，将所述写请求写入所述集群中的主节点。

另一方面，本发明还提供了一种数据处理系统，包括：处理模块，用于当Dledger集群中的主节点在接收到客户端发送的写请求后，控制所述主节点对所述写请求进行处理，得到日志数据；广播模块，用于控制所述主节点向所述集群中所有的从节点广播所述日志数据；反馈模块，用于控制所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。

在一个实施例中，所述反馈模块，具体用于控制所述主节点接收所述从节点反馈的存储信息，根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈；其中，所述存储信息记载了所述从节点是否存储所述日志数据。

在一个实施例中，在所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈方面，所述反馈模块具体用于控制所述主节点对所述从节点反馈的所述存储结果进行仲裁，判断所述集群中是否有超过一半数量的从节点存储了所述日志数据，若是，所述主节点向所述客户端反馈写入成功通知；若否，所述主节点向所述客户端反馈写入失败通知。

在一个实施例中，所述系统还包括：读写模块，用于当Dledger集群接收到客户端发起的写请求时，将所述写请求写入所述集群中的主节点。

本发明还提供一种计算机设备，包括处理器、存储器，其中，所述存储器，用于存放计算机程序；所述处理器，用于执行所述存储器上所存放的计算机程序，实现所述的数据处理方法所执行的操作。

本发明还提供一种存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现所述的数据处理方法所执行的操作。

通过本发明提供的一种数据处理方法、系统、计算机设备和存储介质，Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；所述主节点向所述集群中所有的从节点广播所述日志数据；主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。能够基于raft算法实现分布式消息存储多副本机制可以很好实现消息存储强一致性、高可靠、高可用等优点。

附图说明

下面将以明确易懂的方式，结合附图说明优选实施方式，对一种数据处理方法、系统、计算机设备和存储介质的上述特性、技术特征、优点及其实现方式予以进一步说明。

图1是本发明一种数据处理方法的一个实施例的流程图；

图2是本发明一种日志复制的模型图；

图3是本发明一种数据处理方法的另一个实施例的流程图；

图4是本发明中基于raft算法的一个commitiedlog存储库示意图；

图5是本发明一种数据处理系统的一个实施例的结构示意图；

图6是本发明一种数据处理系统的另一个实施例的结构示意图；

图7是本发明一种计算机设备的一个实施例的结构示意图。

具体实施方式

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对照附图说明本发明的具体实施方式。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。

为使图面简洁，各图中只示意性地表示出了与本发明相关的部分，它们并不代表其作为产品的实际结构。另外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘示了其中的一个，或仅标出了其中的一个。在本文中，“一个”不仅表示“仅此一个”，也可以表示“多于一个”的情形。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本发明提供了一种数据处理方法的一个实施例，如图1所示，该数据处理方法具体包括：

S101、Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；

S102、所述主节点向所述集群中所有的从节点广播所述日志数据；

S103、所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。

本发明是基于raft算法实现的分布式消息存储多副本机制，分布式存储系统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式存储系统的最核心问题：维护多个副本的一致性。

在本实施例中，首先介绍一下基于raft的分布式协议：Raft是一种分布式协议，随着用户数量的增多，用户产生的计算机数据也成倍增加，采用一台机器来运算计算机数据已经远远不能够支撑当前软件后端的运算量，因此诞生了分布式概念，分布式数据中有一个最大的问题在于其高可用性，即数据之间的高一致性，例如当一台计算机上的数据发生改变之后，如何在其他计算机上进行信息的同步，成为了问题的关键。例如用户对于智能学习机上存储的学习资源，当用户在一台学习机上删除或者增加了学习资源后，该台学习机会对该用户对应的学习数据进行更新，但是当该用户在其他学习机上使用该账号进行学习时，如何保证数据的更新成为了问题。再例如用户的账户上存放了一定的金额，当用户在一台取款机上取款之后，该台取款机对用户的账户数据进行了更新，但是其他的取款机或者说后台服务器是否也进行了账户数据的同步更新呢，这就存在很大的隐患，那到底怎么才能让某台机器上的一个操作同步到所有的机器上，这可以分布式协议来完成。

在分布式协议中，需要简单介绍Raft的日志广播过程，当集群在接收到写请求后，在集群中由leader(主节点)进行日志广播，将日志数据发送给follower(从节点)，follower对自己收到的日志进行应答，如果有超过一半以上的从节点进行了应答，那主节点就会通知从节点日志广播成功，向用户端反馈已经写入成功的通知。在集群的所有节点上都有一个存储日志的队列，且队列中的所有数据都序号，其该序号是连续递增的，例如前一个序号是N，那么后一个序号就是N+1，在这个队列中有一个重要的数据就是Commitindex叫做日志的提交位置，这个位置将日志队列分为了两部分，一部分是已经提交的日志，一部分是未提交的日志，已经提交的日志是上述超过半数以上机器收到并且确认的日志，这些数据是可以给客户端来进行读取和使用的，而另一部分就是未提交的日志，也就是leader将日志下发了，但是还没有下发日志广播成功的通知。当节点收到日志之后会依次编号并且放在队列中，等待leader将commit index更新过来之后follower才会更新自己的commit leader，在日志队列中，已经提交的日志是不可改变的。不存在回退的情况。

在Raft中的主节点选举的协议中，协议保证了Raft中只有一个主节点让Raft协议变得简单易懂，除去保证同时只有一个主节点之外，还保证只有主节点可以往从节点发送数据，不可以由从节点往主节点发送数据。在Raft中的主节点采用多数派协议，也就是说只有大多数人同意你成为主节点你才可以成为主节点，支持者必须超过半数，这样的话就保证了同时只能存在一个主节点。当一个主节点失去链接一段时间之后，这个链接是由心跳包来保证的，candidate会发送投票请求，由从节点进行投票，如果超过半数的节点给他投票的话，那他就是新的主节点开始进行广播主节点。但是这时候也会存在一种情况，就是超时机制。首先每个从节点的主节点超时时间是随机的，也就是说如果说真的是主节点出现了情况，这时候在一秒之后a发现了主节点断开了，而b可能两秒钟才能意识到，c则可能是三秒才意识到。这时候不同的机器意识到主节点的时间不同，那他们去竞选成为主节点的时间也就会存在差异。这样就在一定程度上避免了同时多个candidate竞选成为主节点的情况，不过这里的时间都是在一定范围内的随机出来的，不能差距太大。并且还有一层保护机制，就是当每个candidate选举成为主节点如果在一定时间内，没有主节点产生，就会重新发起选举，各个candidate的重新选举时间也是随机的。这样就会避免多个candidate又同时进行竞选主节点。时间同样不能过大或者过小，过大的话影响程序的平滑运行，超时间没有主节点，太小的话很容易引起冲突。

对于主节点的选取及投票方面，首先candidate的日志节点的长度要等于或者超过一半以上的从节点。因为从节点众多，当一个主节点发生故障的时候从节点中的日志情况很大可能是不相同的，有的多有的少，并且commit index也是可能不相同的。已经提交过的日志是保证不能丢失的，不然这个协议的用处也就没有了，所以已经提交的日志是必须复制到所有节点上的。所以Raft就对candidate进行了规定只有已经包含了所有已经提交的节点才能成为candidate，实现也是十分的简单，当主节点发生故障之后，candidate会发送自己的竞选请求，在请求中包含了自己当前的日志长度，说到投票请求的从节点会和自己对比candidate的日志长度，只有candidate的日志长度等于或者长于自己的日志长度，从节点才会对他进行投票，如果有超过半数的从节点对他进行了投票那他就变成了新的主节点。

也可能是存在一些情况，比如主节点因为网络情况故障了，但是在这段时间内选出来了新的主节点，不过这时候旧的主节点又再次恢复了链接，这时候旧的主节点是不知道自己已经被取代了还是向大家发送数据，Raft并不能让这个旧的主节点不发送消息，但是他会让从节点拒绝旧的主节点的数据，主节点向从节点发送数据的时候并不是只有简单数据，他还包含了一个term值，term是指从一次主节点选举开始到下一次主节点选举的时间，这段时间只能有一个主节点被选举成功，当从节点收到日志之后会检查term号码。如果发送数据来的主节点的term号码大于等于自己的号码，那就接受他来的数据，如果不是那就拒绝这个主节点发送来的数据，说明他已经是一个旧的主节点，这时候他还会给旧的主节点发送自己当前新的term数据。当旧的主节点收到了大于自己的term编号，旧的主节点就知道自己已经过期了不再是主节点了就将自己变成一个从节点。

如图2所示，图2为一个简易的日志复制的模型：图中客户端向DLedger集群发起一个写请求，集群中的主节点(Leader)来处理写请求，首先数据先存入主节点，然后主节点将处理写请求之后得到的日志数据广播给它的所有从节点，从节点接收到主节点的日志数据后，将日志数据进行存储，然后向主节点汇报存储的结果，Leader主节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半的从节点都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。

具体的，为了方便对日志进行管理与辨别，raft协议为每一条消息进行编号，当写请求消息达到主节点时会生成一个唯一的递增号，这样可以根据日志序号来快速的判断数据在主从复制过程中数据是否一致。在主节点收到客户端的数据写入请求后，通过解析请求，提取数据部分，构建日志对象，并生成日志序号，并存储到Leader节点中，然后将日志广播到其从节点，由于这个过程中存在网络时延，如果此时客户端向主节点查询seq的日志，由于日志已经存储在Leader节点中了，如果直接返回给客户端显然会存在问题，因此，DLedger引入了已提交指针，即当主节点收到客户端请求时，首先先将数据存储，但此时数据是未提交的，此时客户端无法访问，只有当集群内超过半数的节点都将日志追加完成后，才会更新指针，得以使客户端进行访问。

可见，本申请中Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；通过主节点向所述集群中所有的从节点广播所述日志数据；并由主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈通过引入基于raft算法实现多副本存储消息机制方式，去除消息队列依赖于外部组件，raft自我协调算法协议，从而实现了消息队列容灾自动切换效果，减少人工干预恢复。

本发明提供了一种数据处理方法的一个实施例，如图3所示，该数据处理方法具体包括：

S301、当Dledger集群接收到客户端发起的写请求时，将所述写请求写入所述集群中的主节点。

S302、Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；

S303、所述主节点向所述集群中所有的从节点广播所述日志数据；

S304、所述主节点接收所述从节点反馈的存储信息，所述存储信息记载了所述从节点是否存储所述日志数据；

S305、所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈。其中，预设数量包括所述集群中的一半数量的从节点。

本发明是基于raft算法实现的分布式消息存储多副本机制，分布式存储系统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式存储系统的最核心问题：维护多个副本的一致性。

如图2所示，图2为一个简易的日志复制的模型：图中客户端向DLedger集群发起一个写请求，集群中的主节点(Leader节点)来处理写请求，首先数据先存入主节点，然后主节点将处理写请求之后得到的日志数据广播给它的所有从节点，从节点接收到主节点的日志数据后，将日志数据进行存储，然后向主节点汇报存储的结果，Leader节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。

具体的，为了方便对日志进行管理与辨别，raft协议为每一条消息进行编号，当写请求消息达到主节点时会生成一个唯一的递增号，这样可以根据日志序号来快速的判断数据在主从复制过程中数据是否一致。在主节点收到客户端的数据写入请求后，通过解析请求，提取数据部分，构建日志对象，并生成日志序号，并存储到Leader主节点中，然后将日志广播到从节点，由于这个过程中存在网络时延，如果此时客户端向主节点查询seq的日志，由于日志已经存储在Leader节点中了，如果直接返回给客户端显然会存在问题，因此，DLedger引入了已提交指针，即当主节点收到客户端请求时，首先先将数据存储，但此时数据是未提交的，此时客户端无法访问，只有当集群内超过半数的节点都将日志追加完成后，才会更新指针，得以使客户端进行访问。

DLedger是一个工业级的Java Library，可以非常好地嵌入各类Java系统中，满足其高可用、高可靠、强一致的需求。DLedger只提供日志的实现，只拥有日志写入和读出的接口，且对顺序读出和随机读出做了优化，充分适应消息系统消峰填谷的需求。

DLedger的纯粹日志写入和读出，使其精简而健壮，而且这种原子化的设计，使其不仅可以充分适应消息系统，也可以基于这些日志去构建自己的状态机，从而适应更广泛的场景。

因此，DLedger是一个基于Raft算法实现高可靠、高可用、强一致的Commitlog存储Library。

如图4所示，DLedgerCommitlog用来代替现有的Commitlog存储实际消息内容，它通过包装一个DLedgerServer来实现复制；依靠DLedger的直接存取日志的特点，消费消息时，直接从DLedger读取日志内容作为消息返回给客户端；依靠DLedger的Raft选举功能，通过RoleChangeHandler把角色变更透传给RocketMQ的Broker，从而达到主备自动切换的目标。

RocketMQ路由注册是通过Broker与NameServer的心跳功能实现。Broker启动时向集群中所有的NameServer发送心跳包，每隔30秒向集群中的所有NameServer发送心跳，NamerServer收到心跳包会更新brokerLiveTable缓存中的BrokerLiveInfo的lastUpdateTimestamp，然后NameServer每隔十秒扫描brokerLiveTable，如果连续120秒没有收到心跳包，NameServer将移除该broker的路由信息，同时关闭Socket连接。

可见，本申请中Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；通过主节点向所述集群中所有的从节点广播所述日志数据；并由主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈通过引入基于raft算法实现多副本存储消息机制方式，去除消息队列依赖于外部组件，raft自我协调算法协议，从而实现了消息队列容灾自动切换效果，减少人工干预恢复。

本发明提供了一种数据处理方法的一个实施例，如图5所示，该系统包括：

处理模块51，用于当Dledger集群中的主节点在接收到客户端发送的写请求后，控制所述主节点对所述写请求进行处理，得到日志数据；

广播模块52，用于控制所述主节点向所述集群中所有的从节点广播所述日志数据；

反馈模块53，用于控制所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。

本发明是基于raft算法实现的分布式消息存储多副本机制，分布式存储系统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式存储系统的最核心问题：维护多个副本的一致性。

本实施例中，首先介绍一下raft分布式协议：Raft是一种分布式协议，随着用户数量的增多，计算机数据也成倍增加，采用一台机器来运算计算机数据已经不足及支撑当前软件后端的运算量，因此诞生了分布式概念，分布式数据中有一个最大的问题就是其高可用性，即数据之间的高一致性，例如当一台计算机上的数据发生改变之后，如何在其他计算机上进行信息的同步，成为了问题的关键。例如用户的账户上存放了一定的金额，当用户在一台取款机上取款之后，该台取款机对用户的账户数据进行了更新，但是其他的取款机或者说后台服务器是否也进行了账户数据的同步更新呢，这就存在很大的隐患，那到底怎么才能让某台机器上的一个操作同步到所有的机器上，这可以分布式协议来完成。

在分布式协议中，需要简单介绍Raft的日志广播过程，Raft中这个过程设计的十分简单，当集群在接收到写请求后，在集群中由leader(主节点)进行日志广播，将日志数据发送给follower(从节点)，follower对自己收到的日志进行应答，如果有超过一半以上的从节点进行了应答，那主节点就会通知从节点日志广播成功，向用户端反馈已经写入成功的通知。在集群的所有节点上都有一个存储日志的队列，且队列中的所有数据都序号，其该序号是连续递增的，例如前一个序号是N，那么后一个序号就是N+1，在这个队列中有一个重要的数据就是Commit index叫做日志的提交位置，这个位置将日志队列分为了两部分，一部分是已经提交的日志，一部分是未提交的日志，已经提交的日志是上述超过半数以上机器收到并且确认的日志，这些数据是可以给客户端来进行读取和使用的，而另一部分就是未提交的日志，也就是leader将日志下发了，但是还没有下发日志广播成功的通知。当节点收到日志之后会依次编号并且放在队列中，等待leader将commit index更新过来之后follower才会更新自己的commit leader，在日志队列中，已经提交的日志是不可改变的。不存在回退的情况。

在Raft中的主节点选举的协议中，协议保证了Raft中只有一个主节点让Raft协议变得简单易懂，除去保证同时只有一个主节点之外，还保证只有主节点可以往从节点发送数据，不可以由从节点往主节点发送数据。在Raft中的主节点采用多数派协议，也就是说只有大多数人同意你成为主节点你才可以成为主节点，支持者必须超过半数，这样的话就保证了同时只能存在一个主节点。当一个主节点失去链接一段时间之后，这个链接是由心跳包来保证的，candidate会发送投票请求，由从节点进行投票，如果超过半数的节点给他投票的话，那他就是新的主节点开始进行广播主节点。但是这时候也会存在一种情况，就是超时机制。首先每个从节点的主节点超时时间是随机的，也就是说如果说真的是主节点出现了情况，这时候在一秒之后a发现了主节点断开了，而b可能两秒钟才能意识到，c则可能是三秒才意识到。这时候不同的机器意识到主节点的时间不同，那他们去竞选成为主节点的时间也就会存在差异。这样就在一定程度上避免了同时多个candidate竞选成为主节点的情况，不过这里的时间都是在一定范围内的随机出来的，不能差距太大。并且还有一层保护机制，就是当每个candidate选举成为主节点如果在一定时间内，没有主节点产生，就会重新发起选举，各个candidate的重新选举时间也是随机的。这样就会避免多个candidate又同时进行竞选主节点。时间同样不能过大或者过小，过大的话影响程序的平滑运行，超时间没有主节点，太小的话很容易引起冲突。

对于主节点的选取及投票方面，首先candidate的日志节点的长度要等于或者超过一半以上的从节点。因为从节点众多，当一个主节点发生故障的时候从节点中的日志情况很大可能是不相同的，有的多有的少，并且commit index也是可能不相同的。已经提交过的日志是保证不能丢失的，不然这个协议的用处也就没有了，所以已经提交的日志是必须复制到所有节点上的。所以Raft就对candidate进行了规定只有已经包含了所有已经提交的节点才能成为candidate，实现也是十分的简单，当主节点发生故障之后，candidate会发送自己的竞选请求，在请求中包含了自己当前的日志长度，说到投票请求的从节点会和自己对比candidate的日志长度，只有candidate的日志长度等于或者长于自己的日志长度，从节点才会对他进行投票，如果有超过半数的从节点对他进行了投票那他就变成了新的主节点。

也可能是存在一些情况，比如主节点故障后，系统选出来了新的主节点，在主节点又再次恢复时，旧的主节点是不知道自己已经被取代了还是向大家发送数据，Raft并不能让这个旧的主节点不发送消息，但是他会让从节点拒绝旧的主节点的数据，主节点向从节点发送数据的时候并不是只有简单数据，他还包含了一个term值，term是指从一次主节点选举开始到下一次主节点选举的时间，这段时间只能有一个主节点被选举成功，当从节点收到日志之后会检查term号码。如果发送数据来的主节点的term号码大于等于自己的号码，那就接受他来的数据，如果不是那就拒绝这个主节点发送来的数据，说明他已经是一个旧的主节点，这时候他还会给旧的主节点发送自己当前新的term数据。当旧的主节点收到了大于自己的term编号，旧的主节点就知道自己已经过期了不再是主节点了就将自己变成一个从节点。

如图2所示，图2为一个简易的日志复制的模型：图中客户端向DLedger集群发起一个写请求，集群中的主节点(Leader)来处理写请求，首先数据先存入主节点，然后主节点将处理写请求之后得到的日志数据广播给它的所有从节点，从节点接收到主节点的日志数据后，将日志数据进行存储，然后向主节点汇报存储的结果，Leader主节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半的从节点都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。

具体的，为了方便对日志进行管理与辨别，raft协议为每一条消息进行编号，当写请求消息达到主节点时会生成一个唯一的递增号，这样可以根据日志序号来快速的判断数据在主从复制过程中数据是否一致。在主节点收到客户端的数据写入请求后，通过解析请求，提取数据部分，构建日志对象，并生成日志序号，并存储到Leader节点中，然后将日志广播到其从节点，由于这个过程中存在网络时延，如果此时客户端向主节点查询seq的日志，由于日志已经存储在Leader节点中了，如果直接返回给客户端显然会存在问题，因此，DLedger引入了已提交指针，即当主节点收到客户端请求时，首先先将数据存储，但此时数据是未提交的，此时客户端无法访问，只有当集群内超过半数的节点都将日志追加完成后，才会更新指针，得以使客户端进行访问。

可见，本申请中Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；通过主节点向所述集群中所有的从节点广播所述日志数据；并由主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈通过引入基于raft算法实现多副本存储消息机制方式，去除消息队列依赖于外部组件，raft自我协调算法协议，从而实现了消息队列容灾自动切换效果，减少人工干预恢复。

本发明还提供了一种数据处理系统的一个实施例，如图6所示，所述系统包括：

读写模块54，用于当Dledger集群接收到客户端发起的写请求时，将所述写请求写入所述集群中的主节点。

处理模块51，用于当Dledger集群中的主节点在接收到客户端发送的写请求后，控制所述主节点对所述写请求进行处理，得到日志数据；

广播模块52，用于控制所述主节点向所述集群中所有的从节点广播所述日志数据；

反馈模块53，用于控制所述主节点接收所述从节点反馈的存储信息，根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈；其中，所述存储信息记载了所述从节点是否存储所述日志数据。

本发明是基于raft算法实现的分布式消息存储多副本机制，分布式存储系统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式存储系统的最核心问题：维护多个副本的一致性。

如图2所示，图2为一个简易的日志复制的模型：图中客户端向DLedger集群发起一个写请求，集群中的主节点(Leader节点)来处理写请求，首先数据先存入主节点，然后主节点将处理写请求之后得到的日志数据广播给它的所有从节点，从节点接收到主节点的日志数据后，将日志数据进行存储，然后向主节点汇报存储的结果，Leader节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。

具体的，为了方便对日志进行管理与辨别，raft协议为每一条消息进行编号，当写请求消息达到主节点时会生成一个唯一的递增号，这样可以根据日志序号来快速的判断数据在主从复制过程中数据是否一致。在主节点收到客户端的数据写入请求后，通过解析请求，提取数据部分，构建日志对象，并生成日志序号，并存储到Leader节点中，然后将日志广播(推送)到其从节点，由于这个过程中存在网络时延，如果此时客户端向主节点查询seq的日志，由于日志已经存储在Leader节点中了，如果直接返回给客户端显然会存在问题，因此，DLedger引入了已提交指针，即当主节点收到客户端请求时，首先先将数据存储，但此时数据是未提交的，此时客户端无法访问，只有当集群内超过半数的节点都将日志追加完成后，才会更新指针，得以使客户端进行访问。

DLedger是一个工业级的Java Library，可以非常好地嵌入各类Java系统中，满足其高可用、高可靠、强一致的需求。DLedger只提供日志的实现，只拥有日志写入和读出的接口，且对顺序读出和随机读出做了优化，充分适应消息系统消峰填谷的需求。

DLedger的纯粹日志写入和读出，使其精简而健壮，总代码不超过4000行，测试覆盖率高达70％。而且这种原子化的设计，使其不仅可以充分适应消息系统，也可以基于这些日志去构建自己的状态机，从而适应更广泛的场景。

综上所述，DLedger是一个基于Raft实现的、高可靠、高可用、强一致的Commitlog存储Library

如图4所示，DLedgerCommitlog用来代替现有的Commitlog存储实际消息内容，它通过包装一个DLedgerServer来实现复制；依靠DLedger的直接存取日志的特点，消费消息时，直接从DLedger读取日志内容作为消息返回给客户端；依靠DLedger的Raft选举功能，通过RoleChangeHandler把角色变更透传给RocketMQ的Broker，从而达到主备自动切换的目标。

RocketMQ路由注册是通过Broker与NameServer的心跳功能实现。Broker启动时向集群中所有的NameServer发送心跳包，每隔30秒向集群中的所有NameServer发送心跳，NamerServer收到心跳包会更新brokerLiveTable缓存中的BrokerLiveInfo的lastUpdateTimestamp，然后NameServer每隔十秒扫描brokerLiveTable，如果连续120秒没有收到心跳包，NameServer将移除该broker的路由信息，同时关闭Socket连接。

可见，本申请中Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；通过主节点向所述集群中所有的从节点广播所述日志数据；并由主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈通过引入基于raft算法实现多副本存储消息机制方式，去除消息队列依赖于外部组件，raft自我协调算法协议，从而实现了消息队列容灾自动切换效果，减少人工干预恢复。

本发明的一个实施例，如图7所示，一种计算机设备700，包括处理器610、存储器720，其中，存储器720，用于存放计算机程序；处理器610，用于执行存储器720上所存放的计算机程序，实现上述所对应方法实施例中的数据处理方法。

图6是本发明实施例提供的一种计算机设备700的结构示意图。参见图6，该计算机设备700包括处理器610和存储器720，还可以包括通信接口740和通信总线750，还可以包括输入/输出接口730，其中，处理器610、存储器720、输入/输出接口730和通信接口740通过通信总线750完成相互间的通信。该存储器720存储有计算机程序，该处理器610用于执行存储器720上所存放的计算机程序，实现上述所对应方法实施例中的数据处理方法。

通信总线750是连接所描述的元素的电路并且在这些元素之间实现传输。例如，处理器610通过通信总线750从其它元素接收到命令，解密接收到的命令，根据解密的命令执行计算或数据处理。存储器720可以包括程序模块，例如内核(kernel)，中间件(middleware)，应用程序编程接口(Application Programming Interface，API)和应用。该程序模块可以是有软件、固件或硬件、或其中的至少两种组成。输入/输出接口730转发用户通过输入输出设备(例如感应器、键盘、触摸屏)输入的命令或数据。通信接口740将该计算机设备700与其它网络设备、用户设备、网络进行连接。例如，通信接口740可以通过有线或无线连接到网络以连接到外部其它的网络设备或用户设备。无线通信可以包括以下至少一种：无线保真(WiFi)，蓝牙(BT)，近距离无线通信技术(NFC)，全球卫星定位系统(GPS)和蜂窝通信等等。有线通信可以包括以下至少一种：通用串行总线(USB)，高清晰度多媒体接口(HDMI)，异步传输标准接口(RS-232)等等。网络可以是电信网络和通信网络。通信网络可以为计算机网络、因特网、物联网、电话网络。计算机设备700可以通过通信接口740连接网络，计算机设备700和其它网络设备通信所用的协议可以被应用、应用程序编程接口(API)、中间件、内核和通信接口740至少一个支持。

本发明的一个实施例，一种存储介质，存储介质中存储有至少一条指令，指令由处理器加载并执行以实现上述数据处理方法对应实施例所执行的操作。例如，计算机可读存储介质可以是只读内存(ROM)、随机存取存储器(RAM)、只读光盘(CD-ROM)、磁带、软盘和光数据存储设备等。

它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

应当说明的是，上述实施例均可根据需要自由组合。以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

Dledger集群中的主节点在接收到客户端发送的写请求后，对所述写请求进行处理，得到日志数据；

所述主节点向所述集群中所有的从节点广播所述日志数据；

所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。

2.根据权利要求1所述的方法，其特征在于，所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈，包括：

所述主节点接收所述从节点反馈的存储信息，所述存储信息记载了所述从节点是否存储所述日志数据；

所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈。

3.根据权利要求2所述的方法，其特征在于，所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈，具体包括：

所述主节点对所述从节点反馈的所述存储结果进行仲裁，判断所述集群中是否有超过一半数量的从节点存储了所述日志数据，若是，所述主节点向所述客户端反馈写入成功通知；若否，所述主节点向所述客户端反馈写入失败通知。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当Dledger集群接收到客户端发起的写请求时，将所述写请求写入所述集群中的主节点。

5.一种数据处理系统，其特征在于，包括：

处理模块，用于当Dledger集群中的主节点在接收到客户端发送的写请求后，控制所述主节点对所述写请求进行处理，得到日志数据；

广播模块，用于控制所述主节点向所述集群中所有的从节点广播所述日志数据；

反馈模块，用于控制所述主节点根据所述从节点对所述日志数据的存储情况对所述用户端进行反馈。

6.根据权利要求5所述的系统，其特征在于，所述反馈模块，具体用于控制所述主节点接收所述从节点反馈的存储信息，根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈；其中，所述存储信息记载了所述从节点是否存储所述日志数据。

7.根据权利要求6所述的系统，其特征在于，在所述主节点根据所述从节点反馈的存储信息，判断所述集群中是否有预设数量的从节点存储了所述日志数据，并根据判断结果向所述用户端进行反馈方面，所述反馈模块具体用于控制所述主节点对所述从节点反馈的所述存储结果进行仲裁，判断所述集群中是否有超过一半数量的从节点存储了所述日志数据，若是，所述主节点向所述客户端反馈写入成功通知；若否，所述主节点向所述客户端反馈写入失败通知。

8.根据权利要求5所述的系统，其特征在于，所述系统还包括：

读写模块，用于当Dledger集群接收到客户端发起的写请求时，将所述写请求写入所述集群中的主节点。

9.一种计算机设备，其特征在于，包括处理器、存储器，其中，所述存储器，用于存放计算机程序；所述处理器，用于执行所述存储器上所存放的计算机程序，实现如权利要求1至权利要求4任一项所述的数据处理方法所执行的操作。

10.一种存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如权利要求1至权利要求4任一项所述的数据处理方法所执行的操作。

Images