CN105704004B - 业务数据处理方法和装置 - Google Patents

Abstract

本发明实施例提供一种业务数据处理方法和装置。本发明业务数据处理方法，包括：根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型；接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数；利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。本发明实施例实现对于不同形式的paxos算法，根据该paxos算法协商时间模型获取打包大小和并发个数，使得paxos算法处理业务数据性能提升。

Description

业务数据处理方法和装置

技术领域

本发明实施例涉及计算机技术，尤其涉及一种业务数据处理方法和装置。

背景技术

Paxos算法是莱斯利·兰伯特(Leslie Lamport)于1990年提出的一种基于消息传递的一致性算法。paxos算法解决的问题是一个分布式***如何就某个值(决议)达成一致。一个典型的场景是，在一个分布式数据库***中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行“一致性算法”以保证每个节点看到的指令一致。分布式***中节点通信存在两种模型：共享内存(Shared memory)和消息传递 (Messagespassing)。paxos算法就是一种基于消息传递模型的一致性算法。由于paxos大部分时间在处理一致性协商，选主和恢复流程所用时间较少，所以，其算法性能主要指paxos在协商流程中每秒处理的决议数及每条决议的最大时延。

目前主要是利用“打包技术(Batching)”和“流水线技术(Pipelining)”来提升paxos算法的算法性能。其中，paxos算法用到的Pipelining技术，其原理是利用网络传播时延相对业务处理时间大的情况下，在发送和接收端保证消息的顺序性的同时，在等待传播的时间内，进行下一条决议的发送；而paxos用到的Batching技术，其原理是在提案节点(Leader)收到客户端 (Client)提交的多条决议，以一定时间和打包大小限制的策略把多条决议打包发送给批准节点(Acceptor)，进而完成决议表决和业务下盘。其中， Leader节点为paxos集群对外提供服务的主节点,对内通过该Leader节点与 Acceptors节点进行通信进而完成决议的表决，达到管理Leader节点与 Acceptors节点的一致性，该Leader节点与Acceptors节点同时又分别作为学习节点(Learner)，把表决的数据下盘，达到保存数据的一致性。

现有技术中，通常将paxos作为一个黑盒，根据影响性能的参数以及依赖不同环境输入的一些参数的限制值来构造模型，然后根据该模型调整对决议进行打包所使用的打包尺寸和发送决议所使用的并发数，从而达到优化 paxos算法进行一致性处理的性能。这种方式虽然实现了简单的固定调优模型，但其模型没有考虑不同性能参数对于paxos算法内部协商流程的影响，导致其模型只适合经典的paxos流程，对于paxos的很多变种其模型则需要很多调整，所以不具备一般的推广性。

发明内容

本发明实施例提供一种业务数据处理方法和装置，以实现提升paxos算法处理业务数据性能的同时具有广泛的应用性。

第一方面，本发明实施例提供一种业务数据处理方法，包括：

根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型；

接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数；

利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。

结合第一方面，在第一方面的第一种可能的实现方式中，所述根据paxos 算法协商流程时间获取多个协商关键流程，包括：

对paxos算法协商流程时间进行分析，获取所述paxos算法协商流程中的多个协商关键流程，所述多个协商关键流程包括协商消息传输、处理协商消息和业务下盘相关流程。

结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述利用各个协商关键流程对应的时间生成paxos算法协商时间模型，包括：

根据所述协商消息传输构建协商消息传输的时间模型函数式；

获取所述处理协商消息的时间；

根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式；

利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式，生成所述paxos算法协商时间模型。

结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述协商消息传输包括第一协商消息传输、第二协商消息传输、第三协商消息传输和第四协商消息传输；

所述根据所述协商消息传输构建协商消息传输的时间模型函数式，包括：

根据所述第一协商消息传输构建第一协商消息传输的时间模型函数式，所述第一协商消息传输的时间模型函数式为 T_{send_maj_begin}＝((int)(n/2))*(S_begin/B)+L，其中，T_{send_maj_begin}为第一协商消息传输的时间，n为paxos算法中的批准节点的个数，S_begin为第一协商消息的大小，B 为网络带宽，L为传输时延；

根据所述第二协商消息传输构建第二协商消息传输的时间模型函数式，所述第二协商消息传输的时间模型函数式为T_{maj_cb_collect}＝S_collect/B+L，其中， T_{maj_cb_collect}为第二协商消息传输的时间，S_collect为第二协商消息的大小；

根据所述第三协商消息传输构建第三协商消息传输的时间模型函数式，所述第三协商消息传输的模型函数式为T_{send_maj_commit}＝((int)(n/2))*(S_commit/B)+L，其中，T_{send_maj_commit}为第三协商消息传输的时间，S_commit为第三协商消息的大小；

根据所述第四协商消息传输构建第四协商消息传输的时间模型函数式，所述第四协商消息传输的时间模型函数式为T_{maj_cb_commit_ack}＝S_{commit_ack}/B+L，其中，T_{maj_cb_commit_ack}为第四协商消息传输的时间，S_{commit_ack}为第四协商消息的大小。

将所述第一协商消息传输的时间模型函数式、所述第二协商消息传输的时间模型函数式、所述第三协商消息传输的时间模型函数式和所述第四协商消息传输的时间模型函数式相加获取所述协商消息传输的时间模型函数式。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述获取所述处理协商消息的时间，包括：

分别获取第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}；

将所述第一处理协商消息的时间T_{handle_begin}、所述第二处理协商消息的时间T_{handle_commit}以及所述第三处理协商消息的时间T_{leader_logic}相加获取所述处理协商消息的时间。

结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，所述根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，包括：

根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，所述业务下盘相关流程的时间模型函数式为 T_db＝bSyn？(S_{write_db}/SynSpeedW):(S_{write_db}/AsySpeedW)，其中，T_db为数据库执行时间， bSyn为同步或异步布尔变量，S_{write_db}为业务下盘数据大小，SynSpeedW为同步写速度，AsySpeedW为异步写速度。

结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式生成所述paxos算法协商时间模型的模型函数式，所述paxos算法协商时间模型的模型函数式为其中，T_paxos为所述 paxos算法的协商总时间。

结合第一方面的第六种可能的实现方式，在第一方面的第七种可能的实现方式中，所述业务数据的业务参数包括业务要求的最大回调时延T_{cb_max}；

所述根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数，包括：

利用所述T_{cb_max}和所述paxos算法协商时间模型的模型函数式计算出所述业务数据对应的打包最大值；

根据所述T_{cb_max}和所述业务数据对应的打包最大值获取最优打包大小，并利用所述最优打包大小计算出最优并发个数。

结合第一方面的第七种可能的实现方式，在第一方面的第八种可能的实现方式中，所述利用所述最优打包大小计算出最优并发个数，包括：

根据公式w＝(T_batch+(S/B)+L+T_{handle_begin}+(S/B)+L)/(T_batch+(n-1)*(S/B))计算出最优并发个数w，其中，S为最优打包大小，根据公式T_cb＝S/B计算解包回调业务时间T_cb，根据公式T_batch＝T_{cb_max}-(T'_paxos+T_cb)计算最优打包大小对应的打包时间T_batch，其中T'_paxos为以S为打包大小对业务数据进行打包并调用paxos 算法的协商总时间。

结合第一方面的第八种可能的实现方式，在第一方面的第九种可能的实现方式中，所述利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理，包括：

利用所述最优打包大小和所述最优并发个数调用paxos算法对所述业务数据进行一致性处理。

结合第一方面的第三至第九任一种可能的实现方式，在第一方面的第十种可能的实现方式中，所述传输时延L根据 L＝a+a1*MIN(S1,1024)+a2*MAX(S1,S1-1024)+a3*MAX(0,S1-64*1024)得到，其中， S1包括第一协商消息的消息、第二协商消息的大小、第三协商消息的大小、第四协商消息的大小和最优打包大小中任意一个，a为空包发送的时间，a1、a2和a3为不同的增长率，且a1＜a2＜a3。

第二方面，本发明实施例提供一种业务数据处理装置，包括：

获取模块，用于根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型；

优化模块，用于接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数；

处理模块，用于利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。

结合第二方面，在第二方面的第一种可能的实现方式中，所述获取模块包括：

分析单元，用于对paxos算法协商流程时间进行分析，获取所述paxos 算法协商流程中的多个协商关键流程，所述多个协商关键流程包括协商消息传输、处理协商消息和业务下盘相关流程。

结合第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，所述获取模块还包括：

协商消息传输的时间模型函数式单元，用于根据所述协商消息传输构建协商消息传输的时间模型函数式；

时间获取单元，用于获取所述处理协商消息的时间；

业务下盘相关流程的时间模型函数式单元，用于根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式；

生成单元，用于利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式，生成所述paxos 算法协商时间模型。

结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，所述协商消息传输包括第一协商消息传输、第二协商消息传输、第三协商消息传输和第四协商消息传输；

所述协商消息传输的时间模型函数式单元，包括：

第一时间模型函数式子单元，用于根据所述第一协商消息传输构建第一协商消息传输的时间模型函数式，所述第一协商消息传输的时间模型函数式为T_{send_maj_begin}＝((int)(n/2))*(S_begin/B)+L，其中，T_{send_maj_begin}为第一协商消息传输的时间，n为paxos算法中的批准节点的个数，S_begin为第一协商消息的大小， B为网络带宽，L为传输时延；

第二时间模型函数式子单元，用于根据所述第二协商消息传输构建第二协商消息传输的时间模型函数式，所述第二协商消息传输的时间模型函数式为T_{maj_cb_collect}＝S_collect/B+L，其中，T_{maj_cb_collect}为第二协商消息传输的时间，S_collect为第二协商消息的大小；

第三时间模型函数式子单元，用于根据所述第三协商消息传输构建第三协商消息传输的时间模型函数式，所述第三协商消息传输的模型函数式为 T_{send_maj_commit}＝((int)(n/2))*(S_commit/B)+L，其中，T_{send_maj_commit}为第三协商消息传输的时间，S_commit为第三协商消息的大小；

第四时间模型函数式子单元，用于根据所述第四协商消息传输构建第四协商消息传输的时间模型函数式，所述第四协商消息传输的时间模型函数式为T_{maj_cb_commit_ack}＝S_{commit_ack}/B+L，其中，T_{maj_cb_commit_ack}为第四协商消息传输的时间，S_{commit_ack}为第四协商消息的大小。

协商消息传输的时间模型函数式生成子单元，用于将所述第一协商消息传输的时间模型函数式、所述第二协商消息传输的时间模型函数式、所述第三协商消息传输的时间模型函数式和所述第四协商消息传输的时间模型函数式相加获取所述协商消息传输的时间模型函数式。

结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，所述时间获取单元，具体用于：

分别获取第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}；

将所述第一处理协商消息的时间T_{handle_begin}、所述第二处理协商消息的时间T_{handle_commit}以及所述第三处理协商消息的时间T_{leader_logic}相加获取所述处理协商消息的时间。

结合第二方面的第四种可能的实现方式，在第二方面的第五种可能的实现方式中，所述业务下盘相关流程的时间模型函数式单元，具体用于：

根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，所述业务下盘相关流程的时间模型函数式为 T_db＝bSyn？(S_{write_db}/SynSpeedW):(S_{write_db}/AsySpeedW)，其中，T_db为数据库执行时间，bSyn为同步或异步布尔变量，S_{write_db}为业务下盘数据大小，SynSpeedW为同步写速度，AsySpeedW为异步写速度。

结合第二方面的第五种可能的实现方式，在第二方面的第六种可能的实现方式中，生成单元具体用于利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式生成所述paxos算法协商时间模型的模型函数式，所述paxos算法协商时间模型的模型函数式为其中， T_paxos为所述paxos算法的协商总时间。

结合第二方面的第六种可能的实现方式，在第二方面的第七种可能的实现方式中，所述业务数据的业务参数包括业务要求的最大回调时延T_{cb_max}；

所述优化模块，包括：

第一优化单元，用于利用所述T_{cb_max}和所述paxos算法协商时间模型的模型函数式计算出所述业务数据对应的打包最大值；

第二优化单元，用于根据所述T_{cb_max}和所述业务数据对应的打包最大值获取最优打包大小，并利用所述最优打包大小计算出最优并发个数。

结合第二方面的第七种可能的实现方式，在第二方面的第八种可能的实现方式中，所述第二优化单元，具体用于：

根据公式w＝(T_batch+(S/B)+L+T_{handle_begin}+(S/B)+L)/(T_batch+(n-1)*(S/B))计算出最优并发个数w，其中，S为最优打包大小，根据公式T_cb＝S/B计算解包回调业务时间T_cb，根据公式T_batch＝T_{cb_max}-(T'_paxos+T_cb)计算最优打包大小对应的打包时间T_batch，其中T'_paxos为以S为打包大小对业务数据进行打包并调用paxos 算法的协商总时间。

结合第二方面的第八种可能的实现方式，在第二方面的第九种可能的实现方式中，所述处理模块具体用于：

利用所述最优打包大小和所述最优并发个数调用paxos算法对所述业务数据进行一致性处理。

结合第二方面的第三至第九任一种可能的实现方式，在第二方面的第十种可能的实现方式中，所述传输时延L根据 L＝a+a1*MIN(S1,1024)+a2*MAX(S1,S1-1024)+a3*MAX(0,S1-64*1024)计算得到，其中，S1包括第一协商消息的消息、第二协商消息的大小、第三协商消息的大小、第四协商消息的大小和最优打包大小中任意一个，a为空包发送的时间，a1、a2和a3为不同的增长率，且a1＜a2＜a3。

本发明实施例paxos算法性能优化的方法和装置，通过paxos算法协商流程时间表获取多个协商关键流程，利用各个协商关键流程对应的时间生成paxos算法协商时间模型，根据接收到的业务数据和业务数据的业务参数，利用paxos算法协商时间模型获取打包大小和并发个数，利用该打包大小和并发个数调用paxos算法对业务数据进行一致性处理，由于发明实施例是使用paxos算法协商时间模型获取的打包大小和并发个数调用paxos算法以提升业务数据一致性处理效率，而该paxos算法协商时间模型是根据paoxs算法各个协商关键流程对应的时间生成的，该协商关键流程在不同的paoxs算法类型中均会涉及到，从而使得对于不同类型的paxos算法都可以根据该 paxos算法协商时间模型获取打包大小和并发个数，再使用该打包大小和并发个数调用paoxs算法可以使得paxos算法处理业务数据性能提升。

附图说明

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

图1为Multi paxos算法稳态下具体的协商下盘流程图；

图2为本发明业务数据处理方法实施例一的流程图；

图3为本发明实施例一中的paxos算法协商时间模型的构造方法流程图；

图4为通过Batching技术优化的paxos算法协商流程时间表；

图5为通过Pipelining技术优化的paxos算法协商流程时间表；

图6为本发明业务数据处理方法实施例二的流程图；

图7为本发明业务数据处理装置实施例一的结构示意图；

图8为本发明业务数据处理装置实施例二的结构示意图；

图9为本发明业务数据处理装置实施例三的结构示意图；

图10为本发明业务数据处理装置实施例四的结构示意图；

图11为本发明业务数据处理设备实施例一的结构示意图。

具体实施方式

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

本发明的业务数据处理方法通过优化paoxs算法的打包大小和并发个数后调用paoxs算法，从而实现paoxs算法一致性处理性能的提升，具体的指提升paoxs算法在协商流程中每秒处理的决议数，和减小每条决议的处理时延，本发明的业务数据处理方法适用于不同的paxos算法类型，例如Basic Paxos、Multi paxos以及Paxos Made Simple等不同类型的paxos算法，本发明实施例具体以Multi paxos作举例说明。

为了清楚的理解本发明各实施例，对本发明实施例所涉及的符号定义作如下说明：

表1符号定义说明

本发明实施例涉及paxos算法，paxos算法需要三类节点来完成，分别为提案节点(Leader)、批准节点(Accpetor)和学习节点(Learner)，其中，Accpetor与Learner可以是同一个节点。paxos算法中，图1为Multi paxos 算法稳态下具体的协商下盘流程图，如图1所示，这里以一个提案节点A和两个批准节点(B、C)作举例说明，paxos管理集群包括提案节点A、批准节点B和批准节点C,同时业务存储集群包括提案节点A、学习节点B和学习节点C，批准节点B和学习节点B为同一节点，批准节点C和学习节点C为同一节点，具体协商流程为：(1)客户端首先提交一个决议P；(2)提案节点A收到决议P后，给批准节点B和批准节点C分别发送op_begin消息，该 op_begin消息中带有决议编号和提案节点A最后通过提交的决议编号，询问批准节点B和批准节点C是否通过该决议；(3)批准节点B和批准节点C分别反馈op_collect消息；(4)大多数(n/2+1)个节点通过此决议时，则提案节点A向各批准节点反馈op_commit消息，同时提案节点A对该决议进行下盘，其中n为paxos算法中的批准节点的个数；(5)批准节点B和批准节点C收到op_commit消息后，批准节点B作为学习节点B，对决议进行下盘，批准节点C作为学习节点C，对决议进行下盘，然后分别向提案节点A反馈 op_commit_ack消息；(6)提案节点A收到大多数(n/2+1)个节点反馈的 op_commit_ack消息后，回调业务(即提案节点通知客户端完成此次决议的表决)，进而继续进行下一个决议的表决。

需要说明的是，通过本发明实施例的业务数据处理方法获取打包大小和并发个数后调用上述paoxs算法，即提案节点以本发明实施例的业务数据处理方法获取的打包大小对接收到的业务数据进行打包，将打包后的数据以上述步骤(2)中的op_begin消息发送至批准节点进行表决，在提案节点等待上述步骤(3)中批准节点反馈op_collect消息时，以该并发个数作为限制在等待的时间内继续向批准节点发送之后未表决的决议数据包。从而可以有效提升paoxs算法在协商流程中每秒处理的决议数，和减小每条决议的处理时延。

本发明实施例的业务数据处理方法的执行主体为提案节点，而提案节点可以有一个也可以有多个，此处不以此作为限制，批准节点可以有多个，提案节点和批准节点可以是计算机、移动设备或者类似的其他设备。各批准节点之间是完全对等独立的。

图2为本发明业务数据处理方法实施例一的流程图，如图2所示，本实施例的方法可以包括：

步骤101、根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型。

具体的，对paxos算法进行分析(例如可以对上述图1的paoxs算法协商流程进行分析)，分析可以获知paxos算法协商流程包括：提案节点向各批准节点发送消息，各批准节点向提案节点反馈消息，达到大多数时，提案节点向各批准节点反馈消息，批准节点完成下盘并向提案节点反馈消息等，得出paxos算法协商流程中上述各步骤所用时间，将影响paxos算法性能的协商流程作为协商关键流程，具体是指将paoxs算法协商过程中耗费时间较多的步骤作为协商关键流程，利用多个协商关键流程对应的时间构建paxos 算法协商时间模型。

步骤102、接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数。

其中，打包大小为提案节点对业务数据进行打包的尺寸，即以该打包大小作为限制，把多条决议进行打包后完成决议表决和业务下盘，可以理解的是在以该打包尺寸进行打包过程中，还可以设置进行打包的最大时间，即同时考虑打包大小和打包所使用的时间以进行多条决议打包，举例而言，在进行打包过程中，如果将此次接收到的决议进行打包后小于打包大小，则等待接收下一条决议以进行打包，而由于受到打包的最大时间的限制，在等待接收下一条决议的时候，并不是无限时的等待，而是在该打包的最大时间范围内进行等待，超出时间后，提案节点将以此次决议进行打包后完成决议表决和业务下盘。并发个数为提案节点在等待批准节点返回消息时可以完成多次数据包的发送的次数。

步骤103、利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。

进一步地，步骤101中根据paxos算法协商流程时间获取多个协商关键流程，具体可以为：对paxos算法协商流程时间进行分析，获取paxos算法协商流程的多个协商关键流程，该协商关键流程可以包括协商消息传输、处理协商消息和业务下盘相关流程，除此之外，该协商关键流程还可以包括其他关键流程，此处不以此作为限制。

具体的，利用各个协商关键流程对应的时间生成paxos算法协商时间模型可以为：根据协商消息传输构建协商消息传输的时间模型函数式；获取处理协商消息的时间；根据业务下盘相关流程构建业务下盘相关流程的时间模型函数式；利用该协商消息传输的时间模型函数式、该处理协商消息的时间和该业务下盘相关流程的时间模型函数式，生成paxos算法协商时间模型。

进一步的，该协商消息传输包括第一协商消息传输、第二协商消息传输、第三协商消息传输和第四协商消息传输，其中第一协商消息具体可以为 op_begin消息，第二协商消息具体可以为op_collect消息，第三协商消息具体可以为op_commit消息，第四协商消息具体可以为op_commit_ack消息。

相应的，根据该协商消息传输构建协商消息传输的时间模型函数式具体为：根据第一协商消息传输构建第一协商消息传输的时间模型函数式，该第一协商消息传输的时间模型函数式为：

T_{send_maj_begin}＝((int)(n/2))*(S_begin/B)+L (1)

其中，T_{send_maj_begin}为第一协商消息传输的时间，该第一协商消息传输的时间即为leader节点向paxos集群中acceptor节点发送op_begin消息的时间，具体向集群中所有acceptor节点发送该op_begin消息，这里以(int)(n/2)进行计算，n为paxos算法中的批准节点的个数，S_begin为第一协商消息的大小，即为op_begin消息发送包的大小，B为网络带宽，L为传输时延；

根据第二协商消息传输构建第二协商消息传输的时间模型函数式，该第二协商消息传输的时间模型函数式为：

T_{maj_cb_collect}＝S_collect/B+L (2)

其中，T_{maj_cb_collect}为第二协商消息传输的时间，该第二协商消息传输的时间即acceptor节点向leader节点返回op_collect消息的时间，由于各 acceptor节点为并行发送，所以以公式(2)进行计算T_{maj_cb_collect}，返回 op_collect消息的acceptor节点的和leader节点形成大多数，S_collect为第二协商消息的大小，即为op_collect消息发送包的大小；

根据第三协商消息传输构建第三协商消息传输的时间模型函数式，该第三协商消息传输的模型函数式为：

T_{send_maj_commit}＝((int)(n/2))*(S_commit/B)+L (3)

其中，T_{send_maj_commit}为第三协商消息传输的时间，该第三协商消息传输的时间即为leader节点向acceptor节点发送op_commit消息的时间，具体向集群中所有acceptor节点发送该op_commit消息，这里以(int)(n/2)进行计算 T_{send_maj_commit}，S_commit为第三协商消息的大小，即为op_commit消息发送包的大小；

根据第四协商消息传输构建第四协商消息传输的时间模型函数式，该第四协商消息传输的时间模型函数式为：

T_{maj_cb_commit_ack}＝S_{commit_ack}/B+L (4)

其中，T_{maj_cb_commit_ack}为第四协商消息传输的时间，该第四协商消息传输的时间即为acceptor节点向leader节点返回op_commit_ack消息的时间，返回op_commit_ack消息的acceptor节点的和leader节点形成大多数，S_{commit_ack}为第四协商消息的大小，即为op_commit_ack消息发送包的大小。

将第一协商消息传输的时间模型函数式、第二协商消息传输的时间模型函数式、第三协商消息传输的时间模型函数式和第四协商消息传输的时间模型函数式相加获取协商消息传输的时间模型函数式。

进一步地，获取处理协商消息的时间，具体可以为：分别获取第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}。

将第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}相加获取处理协商消息的时间。

进一步地，根据业务下盘相关流程构建业务下盘相关流程的时间模型函数式，具体可以为：根据业务下盘相关流程构建业务下盘相关流程的时间模型函数式，该业务下盘相关流程的时间模型函数式为：

T_db＝bSyn？(S_{write_db}/SynSpeedW):(S_{write_db}/AsySpeedW) (5)

其中，T_db为数据库执行时间，bSyn为同步/异步布尔变量，S_{write_db}为业务下盘数据大小，SynSpeedW为同步写速度，AsySpeedW为异步写速度。

进一步的，根据协商消息传输的时间模型函数式、处理协商消息的时间和业务下盘相关流程时间模型函数式生成paxos算法协商时间模型的模型函数式，该paxos算法协商时间模型的模型函数式具体为公式(6)。

T_paxos＝T_{send_maj_begin}+T_{send_cb_collect}+T_{send_maj_commit}+T_{maj_cb_commit_ack}+bSyn*T_db+T_{handle_begin}+T_{handle_commit}+T_{leader_logic} (6)

其中，T_paxos为所述paxos算法的协商总时间。

进一步的，业务数据的业务参数包括业务要求的最大回调时延T_{cb_max}，相应的，根据业务数据、业务数据的业务参数和paxos算法协商时间模型获取打包大小和并发个数，具体可以为，利用T_{cb_max}和paxos算法协商时间模型的模型函数式计算出所述业务数据对应的打包最大值，根据T_{cb_max}和业务数据对应的打包最大值获取最优打包大小，并利用最优打包大小计算出最优并发个数。

需要说明的是，上述步骤中的S_begin、S_collect、S_commit、S_{commit_ack}以及S_{write_db}中下标不同是用于标识不同协商流程中的数据包，其大小可以是相等的。

进一步的，利用最优打包大小计算出最优并发个数，具体可以为，根据公式(7)计算出最优并发个数w。

w＝(T_batch+(S/B)+L+T_{handle_begin}+(S/B)+L)/(T_batch+(n-1)*(S/B)) (7)

其中，S为最优打包大小，根据公式(8)计算解包回调业务时间T_cb。

T_cb＝S/B (8)

根据公式(9)计算最优打包大小对应的打包时间T_batch。，其中T'_paxos为以 S为打包大小对业务数据进行打包并调用paxos算法的协商总时间。

T_batch＝T_{cb_max}-(T'_paxos+T_cb) (9)

进一步的，利用打包大小和并发个数调用paxos算法对所述业务数据进行一致性处理，可以具体为，利用最优打包大小和最优并发个数调用paxos 算法对业务数据进行一致性处理。即以最优打包大小和最优并发个数作为限制将业务数据发送给各批准节点进行表决，完成一致性表决后对业务数据进行下盘，以使得分布式***中的提案节点和各批准节点就业务数据达成一致。

可选的，传输时延L可以根据公式(10)计算得到。

L＝a+a1*MIN(S1,1024)+a2*MAX(S1,S1-1024)+a3*MAX(0,S1-64*1024)(10)

其中，a为空包发送的时间，a1、a2和a3为不同的增长率，且a1＜a2＜a3。其中，MIN(S,1024)为取S和1024中的较小者，MAX(S,S-1024)为取S和S-1024 中的较大者，MAX(S,S-64*1024)为取S和S-64*1024中的较大者。S1可以为第一协商消息的大小、或第二协商消息的大小、或第三协商消息的大小、或第四协商消息的大小或最优打包大小。利用公式(10)可以计算出任意大小的消息的传输时延。

传输时延随着包大小的增大而增大，符合递增线段，但包的不同区间，增长率不同。这是因为当包小于1024byte的时候，时间主要消耗在包的消息传递上。当大于1K后，内核内存分配，IP消息分段和IP包重组会增加传播时间。当大于64K后，会受到丢包、带宽等影响增加传播时间。a、a1、a2、 a3的具体值可以根据网络情况进行灵活设置。

本实施例，通过paxos算法协商流程时间获取多个协商关键流程，利用各个协商关键流程对应的时间生成paxos算法协商时间模型，根据接收到的业务数据和业务数据的业务参数，利用paxos算法协商时间模型获取打包大小和并发个数，利用该打包大小和并发个数调用paxos算法对业务数据进行一致性处理，由于本实施例是使用paxos算法协商时间模型获取的打包大小和并发个数调用paxos算法以提升业务数据一致性处理效率，而该paxos算法协商时间模型是根据paoxs算法各个协商关键流程对应的时间生成的，该协商关键流程在不同的paoxs算法类型中均会涉及到，从而使得对于不同类型的paxos算法都可以根据该paxos算法协商时间模型获取打包大小和并发个数，再使用该打包大小和并发个数调用paxos算法可以使得paxos算法处理业务数据性能提升。

下面采用几个具体的实施例，对图2所示方法实施例的技术方案进行详细说明。

图3为本发明实施例一中的paxos算法协商时间模型的构造方法流程图，其核心是对paxos算法协商关键流程进行分析，构建各协商关键流程对应的时间模型函数式，最后综合得出paxos算法协商时间模型，如图3所示，本实施例的方法可以包括：

步骤201、分析paxos算法协商流程中影响算法性能的协商关键流程。

具体的，根据paxos算法的实现分析出协商流程时间表，并选择影响算法性能的多个协商关键流程，根据图1所示的Multi paxos算法稳态下具体的协商下盘流程图分析出如图4所示的通过Batching技术优化的paxos算法协商流程时间表，图4中的客户端用于表示客户端侧，即可以包括多个客户端，批准节点表示批准节点侧，即可以包括多个批准节点，从图4的时间表中可以看出，从k个客户端收集消息进行打包，打包大小为S_begin，相同的原理也可以是从一个客户端接收k个决议进行打包，将打包后的数据包通过 op_begin消息发送给各批准节点，经过一定传输时间后，批准节点对接收到的op_begin消息进行处理后向提案节点反馈op_collect消息，提案节点对该op_collect消息进行处理，若大多数节点通过打包后的决议数据，则提案节点向集群中所有批准节点反馈op_commit消息，经过一定传输时间后，批准节点接收到该op_commit消息，批准节点对该op_commit消息进行处理后，对数据包进行下盘，然后批准节点向提案节点发送op_commit_ack消息，经过一定传输时间后，该op_commit_ack消息到达提案节点，提案节点对该 op_commit_ack消息进行处理，至此完成协商，之后paxos算法还包括提案节点解包，并向客户端返回处理结果。

相同的分析思想，同时可以分析出如图5所示的通过Pipelining技术优化的paxos算法协商流程时间表，从图5的时间表可以看出，对从k个客户端收集的决议以打包大小为S_beginθ1的尺寸进行打包，提案节点通过op_beginθ1 消息发送给批准节点，批准节点经过一定传输时间后接收到该提案节点发送的op_beginθ1消息，并进行处理并反馈op_collectθ1消息，经过一定传输时间后该op_collectθ1消息达到提案节点，在传输op_beginθ1消息以及传输 op_collectθ1消息所使用的总时间范围内，提案节点可以发送新的决议数据包，例如如图5中的S_beginθ2尺寸的数据包，即在提案节点接收到op_collectθ1 消息之前可以向批准节点发送新的数据包，以提升网络资源利用率，这里θ1和θ2用以区分相同类型消息中的不同消息，根据分析可以推导出，提案节点给一个批准节点发送一个消息，并等待该acceptor节点返回消息的时间段，除以提案节点给所有批准节点发送一个消息所耗费的时间，其商为并发个数w。

步骤202、将协商关键流程进行分类。

根据上述时间表将影响算法性能的关键流程进行分类，具体分为协商消息传输、处理协商消息和业务下盘相关流程。其中，协商消息传输与网络和发包大小相关，例如，leader节点给acceptor节点发送op_begin消息， acceptor节点返回op_collect消息，leader节点获知大多数节点通过后， leader节点给acceptor节点发送op_commit消息，acceptor节点反馈 op_commit_ack消息。处理协商消息不受别的性能参数的影响，只需记录一下时间，用于总时间的计算。业务下盘相关流程和硬盘IOPS、使用到的日志数据库以及下盘同步或异步要求的不同相关。

步骤203、根据协商消息传输构建协商消息传输的时间模型函数式，获取处理协商消息的时间，根据业务下盘相关流程构建业务下盘相关流程的时间模型函数式。

具体的，获取协商消息传输的时间模型函数式的具体过程如下：对于发送消息的总时延，发送消息的总时延＝发送时延+传播时延+处理时延+排队时延。而处理时延和排队时延是和路由器相关的，一般花费比较少，所以忽略。所以计算网络和发包大小相关的流程主要是靠发送时延和传播时延来计算。下面给出所用的定理：

网络发送时延＝数据帧长度(b)/信道带宽(b/s)＝发包大小/B

传播时延(L)＝信道长度(m)/电磁波在信道上的传播速率(m/s)

而Paxos算法在协商阶段，除了和发送时延和传播时延有关外，时间花费还和发包的大小、集群中大多数节点的个数有关，综合起来，通过公式(1) 计算第一协商消息传输的时间(leader节点向acceptor节点发送op_begin 消息的传输时间)，通过公式(2)计算第二协商消息传输的时间(acceptor 节点向leader节点返回op_collect消息的传输时间，其中acceptor节点的个数与leader节点个数的总和形成大多数)，通过公式(3)计算第三协商消息传输的时间(leader节点向acceptor节点发送op_commit消息的传输时间)，通过公式(4)计算第四协商消息传输的时间(acceptor节点向leader 节点返回op_commit_ack消息的传输时间，其中acceptor节点的个数与 leader节点个数的总和形成大多数)。其中，传输时延通过公式(10)可以得出。

获取处理协商消息的时间的具体过程为：在acceptor节点记录处理时间，并通过op_collect消息和op_commit_ack消息中增加该处理时间，leader 节点在获取该处理时间后用于paxos算法协商时间模型的构建，具体记录的时间变量为第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间 T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}。

根据业务下盘相关流程构建业务下盘相关流程的时间模型函数式的具体过程为：业务数据通过一致性请求后需要进行一致性下盘，可以通过公式(5) 计算出业务下盘相关流程的时间。

步骤204、构建paxos算法协商时间模型。

具体的，构建如公式(6)的paxos算法协商时间模型的模型函数式。

leader节点在接收到业务数据和业务数据的业务参数后，该业务数据的业务参数为业务要求的最大回调时延T_{cb_max}，计算出打包最大值B_max，同时通过公式(12)计算出打包剩余时间T_{batch_left}，其中T_cb可以根据公式(8)得出， T_{batch_cost}为记录的打包花费时间，在满足打包大小不大于打包最大值，同时打包剩余时间不为0的条件下，不断对打包大小进行调整，以使在业务要求的最大回调时间内发送更多的决议以提升paxos算法性能，根据公式(7)可以看出打包大小的调整同时也会使并发个数进行相应调整。

T_{batch_left}＝T_{cb_max}-(T_paxos+T_cb)-T_{batch_cost} (12)

以上是paxos算法协商时间模型的构造方法，由于该paxos算法协商时间模型是根据各个协商关键流程构造的，而各协商关键流程在不同paoxs算法均会涉及到，因此该paoxs算法协商时间模型具有广泛的应用性。

下面给出应用本发明实施例的paoxs算法协商时间模型对paxos算法进行调优的具体实现过程，具体的算法思想为，通过paxos算法协商时间模型可以计算出打包最大值和并发个数，然后利用该paxos算法协商模型实时计算(每次有决议过来后)打包剩余时间，以此达到动态调整打包大小，实现动态调优，除此之外，还可以对协商关键流程进行时间记录以调整paxos算法协商时间模型。

图6为本发明业务数据处理方法实施例二的流程图，如图6所示，本发明实施例的方法具体包括：

S301、业务调用paoxs算法。

具体指，接收业务数据和该业务数据的业务参数，该业务参数可以为业务要求的最大回调时延T_{cb_max}，即在该最大回调时延时间内对业务数据完成调用paxos算法的一致性处理。

S302、根据业务参数T_{cb_max}利用paxos算法协商模型计算打包最大值。

具体的，根据T_{cb_max}计算出打包最大值。

S303、对业务数据进行打包获取打包大小。

具体的，对接收到的业务数据进行打包，获取打包大小。

S304、判断是否打包大小小于打包最大值且打包剩余时间不等于0，若是则执行S303，若否则执行S305。

具体的，条件一为打包大小小于打包最大值，条件二为打包剩余时间不等于0，当条件一和条件二都满足时执行S303，当条件一和条件二任一项不满足时则执行S304。其中若条件一和条件二都满足时执行S303过程具体为，等待接收新的业务数据，对业务数据重新打包，获取新的打包大小，进而再执行S304的判断步骤，以此为循环在条件满足的情况下，不断对打包大小进行调整，从而在业务要求的最大回调时间内发送更多的决议以提升paxos算法性能。

其中，打包剩余时间的计算可以通过公式(12)进行计算，具体的已知当前打包大小S、网络带宽B、集群中acceptor节点个数n以及传输时延L，将当前打包大小S作为公式(1)中的S_begin可以根据公式(1)计算出T_{send_maj_begin}，将当前打包大小S作为公式(2)中的S_collect根据公式(2)计算出T_{maj_cb_collect}，将当前打包大小S作为公式(3)中的S_commit根据公式(3)计算出T_{send_maj_commit}，将当前打包大小S作为公式(4)中的S_{commit_ack}根据公式(4)计算出T_{maj_cb_commit_ack}，将当前打包大小S作为公式(8)中的S根据公式(8)计算出T_cb，获取bSyn、SynSpeedW或者AsySpeedW，计算出T_db，进而根据公式(6)计算出T_paxos，在此过程中记录当前的打包花费时间T_{batch_cost}，最后根据公式(12)即可得出打包剩余时间。

S305、调用paxos算法进行一致性处理。

具体的，以S301-S305过程中对打包大小和并发个数不断调优后打包大小有变化，并发个数w根据公式(7)也会相应发生变化，获取到较优的打包大小和并发个数，利用该打包大小和并发个数调用paxos算法进行一致性处理。

S306、利用paxos算法对数据包进行协商处理。

具体的，利用paxos算法对数据包进行协商处理过程中，可以根据本发明实施例的paxos算法协商时间模型分析的各协商关键流程对应的时间进行记录，以对各协商关键流程的时间模型函数式继续调整，以实现对模型函数式的不断调优。具体方法可以包括：

S3061、记录各协商关键流程对应的时间。

具体的，主要记录协商消息传输流程的时间，以及业务下盘相关流程的时间。

S3062、利用记录的各协商关键流程对应的时间更新各协商关键流程的时间模型函数式。

具体的，利用记录的时间与使用协商消息传输的时间模型函数式计算出的时间进行比较，以调整传输时延L，具体调整公式(10)中的a、a1、a2和 a3的大小。

S307、paxos算法协商处理完毕。

paxos算法协商处理完毕后，需要记录paxos算法协商完成总时间，将该记录的paxos算法总时间与通过公式(6)计算出的T_paxos进行比较，进而对 paxos算法协商时间模型的模型函数式进行调整。具体可以包括：

S3071、记录paxos算法协商完成总时间。

S3072、利用记录的协商总时间更新paxos算法协商时间模型。

S308、业务回调。

本实施例，通过利用上述paxos算法协商时间模型对打包大小和并发个数进行不断优化调整，以获取较优的打包大小和并发个数，根据该打包大小和并发个数调用paxos算法进行一致性处理，在对业务数据进行协商处理过程中记录各协商关键流程对应的时间，进而利用记录的时间对paxos算法协商时间模型进行优化调整，以使paxos算法处理业务数据性能提升，本实施例的paxos算法性能优化方法可以适用于不同形式的paxos算法，具有广泛的适用性，从而更好的支撑分布式业务。

图7为本发明业务数据处理装置实施例一的结构示意图，如图7所示，本实施例的装置可以包括：获取模块11、优化模块12以及处理模块13，其中，获取模块11用于根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型，优化模块12用于接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数，处理模块13用于利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。

本实施例的装置，可以用于执行图1所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图8为本发明业务数据处理装置实施例二的结构示意图，如图8所示，本实施例的装置在图7所示装置结构的基础上，进一步地，获取模块11可以包括分析单元111、协商消息传输的时间模型函数式单元112、时间获取单元 113、业务下盘相关流程的时间模型函数式单元114和生成单元115，该分析单元111用于对paxos算法协商流程时间进行分析，获取所述paxos算法协商流程中的多个协商关键流程，所述多个协商关键流程包括协商消息传输、处理协商消息和业务下盘相关流程，协商消息传输的时间模型函数式单元112 用于根据所述协商消息传输构建协商消息传输的时间模型函数式，时间获取单元113用于获取所述处理协商消息的时间，业务下盘相关流程的时间模型函数式单元114用于根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，生成单元115用于利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式，生成 paxos算法协商时间模型。

本实施例的装置，可以用于执行图1和图6所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图9为本发明业务数据处理装置实施例三的结构示意图，如图9所示，本实施例的装置在图8所示装置结构的基础上，进一步地，所述协商消息传输包括第一协商消息传输、第二协商消息传输、第三协商消息传输和第四协商消息传输，所述协商消息传输的时间模型函数式单元112可以包括第一时间模型函数式子单元1121、第二时间模型函数式子单元1122、第三时间模型函数式子单元1123、第四时间模型函数式子单元1124以及协商消息传输的时间模型函数式生成子单元1125，其中，第一时间模型函数式子单元1121 用于根据所述第一协商消息传输构建第一协商消息传输的时间模型函数式，所述第一协商消息传输的时间模型函数式为 T_{send_maj_begin}＝((int)(n/2))*(S_begin/B)+L，其中，T_{send_maj_begin}为第一协商消息传输的时间，n为paxos算法中的批准节点的个数，S_begin为第一协商消息的大小，B 为网络带宽，L为传输时延，第二时间模型函数式子单元1122用于根据所述第二协商消息传输构建第二协商消息传输的时间模型函数式，所述第二协商消息传输的时间模型函数式为T_{maj_cb_collect}＝S_collect/B+L，其中，T_{maj_cb_collect}为第二协商消息传输的时间，S_collect为第二协商消息的大小，第三时间模型函数式子单元1123用于根据所述第三协商消息传输构建第三协商消息传输的时间模型函数式，所述第三协商消息传输的模型函数式为 T_{send_maj_commit}＝((int)(n/2))*(S_commit/B)+L，其中，T_{send_maj_commit}为第三协商消息传输的时间，S_commit为第三协商消息的大小，第四时间模型函数式子单元1124用于根据所述第四协商消息传输构建第四协商消息传输的时间模型函数式，所述第四协商消息传输的时间模型函数式为T_{maj_cb_commit_ack}＝S_{commit_ack}/B+L，其中， T_{maj_cb_commit_ack}为第四协商消息传输的时间，S_{commit_ack}为第四协商消息的大小，协商消息传输的时间模型函数式生成子单元1125，用于将第一协商消息传输的时间模型函数式、第二协商消息传输的时间模型函数式、第三协商消息传输的时间模型函数式和第四协商消息传输的时间模型函数式相加获取协商消息传输的时间模型函数式。

进一步的，所述时间获取单元113，具体用于：分别获取第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}，将所述第一处理协商消息的时间T_{handle_begin}、所述第二处理协商消息的时间T_{handle_commit}以及所述第三处理协商消息的时间T_{leader_logic}相加获取所述处理协商消息的时间。所述业务下盘相关流程的时间模型函数式单元 114，具体用于：根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，所述业务下盘相关流程的时间模型函数式为 T_db＝bSyn？(S_{write_db}/SynSpeedW):(S_{write_db}/AsySpeedW)，其中，T_db为数据库执行时间，bSyn为同步或异步布尔变量，S_{write_db}为业务下盘数据大小，SynSpeedW为同步写速度，AsySpeedW为异步写速度。

生成单元115具体用于根据所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式生成所述 paxos算法协商时间模型的模型函数式，具体为其中，T_paxos为所述 paxos算法的协商总时间。

本实施例的装置，可以用于执行图1和图6所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图10为本发明业务数据处理装置实施例四的结构示意图，如图10所示，本实施例的装置在图9所示装置结构的基础上，进一步地，所述业务数据的业务参数包括业务要求的最大回调时延T_{cb_max}，所述优化模块12可以包括第一优化单元121和第二优化单元122，其中，第一优化单元121，用于利用所述T_{cb_max}和所述paxos算法协商时间模型的模型函数式计算出所述业务数据对应的打包最大值；第二优化单元122，用于根据所述T_{cb_max}和所述业务数据对应的打包最大值获取最优打包大小，并利用所述最优打包大小计算出最优并发个数。

可选的，所述第二优化单元122，可以具体用于根据公式 w＝(T_batch+(S/B)+L+T_{handle_begin}+(S/B)+L)/(T_batch+(n-1)*(S/B))计算出最优并发个数w，其中，S为最优打包大小，根据公式T_cb＝S/B计算解包回调业务时间T_cb，根据公式T_batch＝T_{cb_max}-(T'_paxos+T_cb)计算最优打包大小对应的打包时间T_batch，其中T'_paxos为以S为打包大小对业务数据进行打包并调用paxos算法的协商总时间。

进一步的，所述处理模块13可以具体用于利用所述最优打包大小和所述最优并发个数调用paxos算法对所述业务数据进行一致性处理。

可选的，可以根据公式 L＝a+a1*MIN(S1,1024)+a2*MAX(S1,S1-1024)+a3*MAX(0,S1-64*1024)计算得到，其中，S1包括第一协商消息的消息、第二协商消息的大小、第三协商消息的大小、第四协商消息的大小和最优打包大小中任意一个，a为空包发送的时间，a1、a2和a3为不同的增长率，且a1＜a2＜a3。

本实施例的装置，可以用于执行图1和图6所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图11为本发明业务数据处理设备实施例一的结构示意图，如图11所示，本实施例提供的业务数据处理设备包括处理器1101，存储器1102和通信接口1103；所述处理器1101，所述存储器1102和所述通信接口1103通过总线相互连接。

所述处理器1101运行所述存储器1102中程序，用于执行本发明如图2 所示方法实施例所提供的技术方案，其实现原理和技术效果类似，可参考图 2所示的方法实施例，此处不再赘述。

所述存储器1102存储程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器1102可能包含随机存取存储器(random access memory，简称RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

所述通信接口1103用于接收业务数据和所述业务数据的业务参数。

所述处理器1101可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP) 等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (22)

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

根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型；

接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数；

利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。

2.根据权利要求1所述的方法，其特征在于，所述根据paxos算法协商流程时间获取多个协商关键流程，包括：

对paxos算法协商流程时间进行分析，获取所述paxos算法协商流程中的多个协商关键流程，所述多个协商关键流程包括协商消息传输、处理协商消息和业务下盘相关流程。

3.根据权利要求2所述的方法，其特征在于，所述利用各个协商关键流程对应的时间生成paxos算法协商时间模型，包括：

根据所述协商消息传输构建协商消息传输的时间模型函数式；

获取所述处理协商消息的时间；

根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式；

利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式，生成所述paxos算法协商时间模型。

4.根据权利要求3所述的方法，其特征在于，所述协商消息传输包括第一协商消息传输、第二协商消息传输、第三协商消息传输和第四协商消息传输；

所述根据所述协商消息传输构建协商消息传输的时间模型函数式，包括：

根据所述第一协商消息传输构建第一协商消息传输的时间模型函数式，所述第一协商消息传输的时间模型函数式为T_{send_maj_begin}＝((int)(n/2))*(S_begin/B)+L，其中，T_{send_maj_begin}为第一协商消息传输的时间，n为paxos算法中的批准节点的个数，S_begin为第一协商消息的大小，B为网络带宽，L为传输时延；

根据所述第二协商消息传输构建第二协商消息传输的时间模型函数式，所述第二协商消息传输的时间模型函数式为T_{maj_cb_collect}＝S_collect/B+L，其中，T_{maj_cb_collect}为第二协商消息传输的时间，S_collect为第二协商消息的大小；

根据所述第三协商消息传输构建第三协商消息传输的时间模型函数式，所述第三协商消息传输的模型函数式为T_{send_maj_commit}＝((int)(n/2))*(S_commit/B)+L，其中，T_{send_maj_commit}为第三协商消息传输的时间，S_commit为第三协商消息的大小；

根据所述第四协商消息传输构建第四协商消息传输的时间模型函数式，所述第四协商消息传输的时间模型函数式为T_{maj_cb_commit_ack}＝S_{commit_ack}/B+L，其中，T_{maj_cb_commit_ack}为第四协商消息传输的时间，S_{commit_ack}为第四协商消息的大小；

将所述第一协商消息传输的时间模型函数式、所述第二协商消息传输的时间模型函数式、所述第三协商消息传输的时间模型函数式和所述第四协商消息传输的时间模型函数式相加获取所述协商消息传输的时间模型函数式。

5.根据权利要求4所述的方法，其特征在于，所述获取所述处理协商消息的时间，包括：

分别获取第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}；

将所述第一处理协商消息的时间T_{handle_begin}、所述第二处理协商消息的时间T_{handle_commit}以及所述第三处理协商消息的时间T_{leader_logic}相加获取所述处理协商消息的时间。

6.根据权利要求5所述的方法，其特征在于，所述根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，包括：

根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，所述业务下盘相关流程的时间模型函数式为T_db＝bSyn？(S_{write_db}/SynSpeedW):(S_{write_db}/AsySpeedW)，其中，T_db为数据库执行时间，bSyn为同步或异步布尔变量，S_{write_db}为业务下盘数据大小，SynSpeedW为同步写速度，AsySpeedW为异步写速度。

7.根据权利要求6所述的方法，其特征在于，利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式生成所述paxos算法协商时间模型的模型函数式，所述paxos算法协商时间模型的模型函数式为其中，T_paxos为所述paxos算法的协商总时间。

8.根据权利要求7所述的方法，其特征在于，所述业务数据的业务参数包括业务要求的最大回调时延T_{cb_max}；

所述根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数，包括：

利用所述T_{cb_max}和所述paxos算法协商时间模型的模型函数式计算出所述业务数据对应的打包最大值；

根据所述T_{cb_max}和所述业务数据对应的打包最大值获取最优打包大小，并利用所述最优打包大小计算出最优并发个数。

9.根据权利要求8所述的方法，其特征在于，所述利用所述最优打包大小计算出最优并发个数，包括：

根据公式w＝(T_batch+(S/B)+L+T_{handle_begin}+(S/B)+L)/(T_batch+(n-1)*(S/B))计算出最优并发个数w，其中，S为最优打包大小，根据公式T_cb＝S/B计算解包回调业务时间T_cb，根据公式T_batch＝T_{cb_max}-(T'_paxos+T_cb)计算最优打包大小对应的打包时间T_batch，其中T'_paxos为以S为打包大小对业务数据进行打包并调用paxos算法的协商总时间。

10.根据权利要求9所述的方法，其特征在于，所述利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理，包括：

利用所述最优打包大小和所述最优并发个数调用paxos算法对所述业务数据进行一致性处理。

11.根据权利要求8至10任一项所述的方法，其特征在于，所述传输时延L根据L＝a+a1*MIN(S1,1024)+a2*MAX(S1,S1-1024)+a3*MAX(0,S1-64*1024)得到，其中，S1包括所述第一协商消息的大小、所述第二协商消息的大小、所述第三协商消息的大小、所述第四协商消息的大小和所述最优打包大小中任意一个，a为空包发送的时间，a1、a2和a3为不同的增长率，且a1＜a2＜a3。

12.一种业务数据处理装置，其特征在于，包括：

获取模块，用于根据paxos算法协商流程时间获取多个协商关键流程，同时利用各个协商关键流程对应的时间生成paxos算法协商时间模型；

优化模块，用于接收业务数据和所述业务数据的业务参数，根据所述业务数据、所述业务数据的业务参数和所述paxos算法协商时间模型获取打包大小和并发个数；

处理模块，用于利用所述打包大小和所述并发个数调用paxos算法对所述业务数据进行一致性处理。

13.根据权利要求12所述的装置，其特征在于，所述获取模块包括：

分析单元，用于对paxos算法协商流程时间进行分析，获取所述paxos算法协商流程中的多个协商关键流程，所述多个协商关键流程包括协商消息传输、处理协商消息和业务下盘相关流程。

14.根据权利要求13所述的装置，其特征在于，所述获取模块还包括：

协商消息传输的时间模型函数式单元，用于根据所述协商消息传输构建协商消息传输的时间模型函数式；

时间获取单元，用于获取所述处理协商消息的时间；

业务下盘相关流程的时间模型函数式单元，用于根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式；

生成单元，用于利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式，生成所述paxos算法协商时间模型。

15.根据权利要求14所述的装置，其特征在于，所述协商消息传输包括第一协商消息传输、第二协商消息传输、第三协商消息传输和第四协商消息传输；

所述协商消息传输的时间模型函数式单元，包括：

第一时间模型函数式子单元，用于根据所述第一协商消息传输构建第一协商消息传输的时间模型函数式，所述第一协商消息传输的时间模型函数式为T_{send_maj_begin}＝((int)(n/2))*(S_begin/B)+L，其中，T_{send_maj_begin}为第一协商消息传输的时间，n为paxos算法中的批准节点的个数，S_begin为第一协商消息的大小，B为网络带宽，L为传输时延；

第二时间模型函数式子单元，用于根据所述第二协商消息传输构建第二协商消息传输的时间模型函数式，所述第二协商消息传输的时间模型函数式为T_{maj_cb_collect}＝S_collect/B+L，其中，T_{maj_cb_collect}为第二协商消息传输的时间，S_collect为第二协商消息的大小；

第三时间模型函数式子单元，用于根据所述第三协商消息传输构建第三协商消息传输的时间模型函数式，所述第三协商消息传输的模型函数式为T_{send_maj_commit}＝((int)(n/2))*(S_commit/B)+L，其中，T_{send_maj_commit}为第三协商消息传输的时间，S_commit为第三协商消息的大小；

第四时间模型函数式子单元，用于根据所述第四协商消息传输构建第四协商消息传输的时间模型函数式，所述第四协商消息传输的时间模型函数式为T_{maj_cb_commit_ack}＝S_{commit_ack}/B+L，其中，T_{maj_cb_commit_ack}为第四协商消息传输的时间，S_{commit_ack}为第四协商消息的大小；

协商消息传输的时间模型函数式生成子单元，用于将所述第一协商消息传输的时间模型函数式、所述第二协商消息传输的时间模型函数式、所述第三协商消息传输的时间模型函数式和所述第四协商消息传输的时间模型函数式相加获取所述协商消息传输的时间模型函数式。

16.根据权利要求15所述的装置，其特征在于，所述时间获取单元，具体用于：

分别获取第一处理协商消息的时间T_{handle_begin}、第二处理协商消息的时间T_{handle_commit}以及第三处理协商消息的时间T_{leader_logic}；

将所述第一处理协商消息的时间T_{handle_begin}、所述第二处理协商消息的时间T_{handle_commit}以及所述第三处理协商消息的时间T_{leader_logic}相加获取所述处理协商消息的时间。

17.根据权利要求16所述的装置，其特征在于，所述业务下盘相关流程的时间模型函数式单元，具体用于：

根据所述业务下盘相关流程构建业务下盘相关流程的时间模型函数式，所述业务下盘相关流程的时间模型函数式为T_db＝bSyn？(S_{write_db}/SynSpeedW):(S_{write_db}/AsySpeedW)，其中，T_db为数据库执行时间，bSyn为同步或异步布尔变量，S_{write_db}为业务下盘数据大小，SynSpeedW为同步写速度，AsySpeedW为异步写速度。

18.根据权利要求17所述的装置，其特征在于，生成单元具体用于利用所述协商消息传输的时间模型函数式、所述处理协商消息的时间和所述业务下盘相关流程的时间模型函数式生成所述paxos算法协商时间模型的模型函数式，所述所述paxos算法协商时间模型的模型函数式为其中，T_paxos为所述paxos算法的协商总时间。

19.根据权利要求18所述的装置，其特征在于，所述业务数据的业务参数包括业务要求的最大回调时延T_{cb_max}；

所述优化模块，包括：

第一优化单元，用于利用所述T_{cb_max}和所述paxos算法协商时间模型的模型函数式计算出所述业务数据对应的打包最大值；

第二优化单元，用于根据所述T_{cb_max}和所述业务数据对应的打包最大值获取最优打包大小，并利用所述最优打包大小计算出最优并发个数。

20.根据权利要求19所述的装置，其特征在于，所述第二优化单元，具体用于：

根据公式w＝(T_batch+(S/B)+L+T_{handle_begin}+(S/B)+L)/(T_batch+(n-1)*(S/B))计算出最优并发个数w，其中，S为最优打包大小，根据公式T_cb＝S/B计算解包回调业务时间T_cb，根据公式T_batch＝T_{cb_max}-(T'_paxos+T_cb)计算最优打包大小对应的打包时间T_batch，其中T'_paxos为以S为打包大小对业务数据进行打包并调用paxos算法的协商总时间。

21.根据权利要求20所述的装置，其特征在于，所述处理模块具体用于：

利用所述最优打包大小和所述最优并发个数调用paxos算法对所述业务数据进行一致性处理。

22.根据权利要求19至21任一项所述的装置，其特征在于，所述传输时延L根据L＝a+a1*MIN(S1,1024)+a2*MAX(S1,S1-1024)+a3*MAX(0,S1-64*1024)计算得到，其中，S1包括所述第一协商消息的大小、所述第二协商消息的大小、所述第三协商消息的大小、所述第四协商消息的大小和所述最优打包大小中任意一个，a为空包发送的时间，a1、a2和a3为不同的增长率，且a1＜a2＜a3。