分布式系统及其监控方法、装置、电子设备及存储介质与流程

本发明涉及网络领域，尤其涉及一种分布式系统及其监控方法、装置、电子设备及存储介质。

背景技术：

谷歌文件系统(googlefilesystem，gfs)奠定了现代大规模分布式存储系统的基石，后续的开源产品hadoop分布式文件系统(hadoopdistributedfilesystem，hdfs)也是类似实现，并广泛运用在需要大规模分布式存储系统的公司和研究机构。

以gfs为例，基本技术架构如图1所示，包括：

客户端(client)，gfs中的库(lib)，链接在用户的应用程序(application)中，用于为分布式存储系统的用户提供各种接口。

块服务器(chunkserver)，gfs的服务器，可以运行linux文件系统(filesystem)，主要用来进行用户数据的存储、读写。

控制端(master)，gfs的服务器，主要用于管理文件的元(meta)数据，可以包含文件命名空间(filenamespace)。

在客户端，控制端，块服务器模式的分布式存储系统中，用户文件的所有元数据都存储在控制端中。文件的数据以多副本的方式保存在不同的块服务器中。

客户端发送文件名称(filename)和块索引(chunkindex)到控制端，控制端返回块句柄(chunkhandle)和块位置(chunklocation)；客户端发送块句柄和字节范围(byterange)到块服务器，块服务器返回块数据(chunkdata)。块服务器还向控制端上报块服务器状态(state)，控制端下发对于块服务器的指令(instructionstochunkserver)给块服务器。其中，块服务器返回给客户端的块数据是数据消息，客户端发送给块服务器的块句柄和字节范围、客户端与控制端之间、控制端与块服务器之间交互的均是控制消息。

现有gfs架构中，包含了三类组件：控制端、块服务器、客户端，此架构下控制端会成为“单点”(当其服务中断时会导致整个系统服务中断)，目前的解决方案一般是增加控制端节点的数量，采用paxos算法来达到冗余互备的目的。

例如当控制端节点有3台时，会利用paxos算法选出一台主(primary)控制端对外提供服务，其余两台作为从控制端。主控制端与从(secondary)控制端依赖网络心跳包进行状态确认。当主控制端发生宕机时，从控制端会发现在指定时间内未收到主控制端的网络心跳包，从控制端将重新选举主控制端，继续对外提供服务。

现实中机器往往存在各种硬件故障，比如磁盘挂起(hang)，机器主板故障等。例如主控制端的磁盘hang的情况下，虽然主控制端仍能保持正常发送给从控制端网络心跳包，但会导致所有需要记录操作日志的请求都无返回，对用户表现为服务异常。此时从控制端并不能发现主控制端服务异常，也不会重新进行选举，导致整个系统持续服务异常；而主控制端上应用程序的自我检查并不能穷举所有单机故障问题；因此，主控制端的故障有可能无法及时被发现，导致系统可用性降低。

技术实现要素：

本申请提供一种分布式系统及其监控方法、装置、电子设备及存储介质，可以提高系统可用性。

本申请采用如下技术方案。

一种分布式系统的监控方法，包括：

获取分布式系统中客户端的通信统计数据；

根据所述客户端的通信统计数据，确定客户端的服务状态；

根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

其中，所述确定所述分布式系统中的控制端的服务状态后还可以包括：

当确定所述分布式系统中的控制端的服务状态为服务异常后，发起控制端的切换。

其中，所述根据所述客户端的通信统计数据，确定控制端的服务状态前还可以包括：

根据客户端的通信统计数据，判断所述分布式系统中总的通信次数是否大于或等于预设的通信总次数阈值，如果大于或等于预设的通信总次数阈值，则进行所述分别根据所述客户端的通信统计数据，确定客户端的服务状态的步骤。

其中，客户端的通信统计数据可以包括该客户端与服务端通信成功、失败的次数、该客户端与控制端通信成功、失败的次数。

其中，所述根据所述客户端的通信统计数据，确定客户端的服务状态可以包括：

对于客户端进行如下判断：

如果该客户端和控制端通信失败的次数大于通信成功的次数，且该客户端和服务端通信成功的次数大于通信失败的次数，则判断该客户端的服务状态为服务异常；

如果该客户端和控制端通信失败的次数小于通信成功的次数，则判断该客户端的服务状态为服务正常。

其中，所述根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态可以包括：

分别统计组中服务状态为服务正常和服务异常的客户端的数量；根据统计结果确定组的服务状态；

根据客户端的服务状态和组的服务状态，确定所述分布式系统中的控制端的服务状态。

其中，所述根据统计结果确定组的服务状态可以包括：

对于组行如下判断：

当该组中服务状态为服务异常的客户端的数量大于预设阈值时，判断该组的服务状态为服务异常；

当该组中服务状态为服务异常的客户端的数量小于预设阈值时，判断该组的服务状态为服务正常。

其中，所述根据客户端的服务状态和组的服务状态，确定分布式系统中的控制端的服务状态可以包括：

当满足以下任一条件时，确定所述分布式系统中的控制端服务异常：

服务状态为服务异常的组的占比超过第一预设比例阈值；

服务状态为服务异常的客户端的占比超过第二预设比例阈值。

服务状态不是服务正常的客户端的占比超过第三预设比例阈值。

一种分布式系统的监控装置，包括：

获取模块，用于获取分布式系统中客户端的通信统计数据；

第一确定模块，用于根据所述客户端的通信统计数据，确定客户端的服务状态；

第二确定模块，用于根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

其中，客户端的通信统计数据可以包括该客户端与服务端通信成功、失败的次数、该客户端与控制端通信成功、失败的次数。

其中，所述第一确定模块根据所述客户端的通信统计数据，确定client的服务状态可以包括：

所述第一确定模块对于客户端进行如下判断：

如果该客户端和控制端通信失败的次数大于通信成功的次数，且该客户端和服务端通信成功的次数大于通信失败的次数，则判断该客户端的服务状态为服务异常；

如果该客户端和控制端通信失败的次数小于通信成功的次数，则判断该客户端的服务状态为服务正常。

其中，所述第二确定模块根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态可以包括：

所述第二确定模块分别统计组中服务状态为服务正常和服务异常的客户端的数量；根据统计结果确定组的服务状态；根据客户端的服务状态和组的服务状态，确定所述分布式系统中的控制端的服务状态。

其中，所述第二确定模块分别根据统计结果确定组的服务状态可以包括：

所述第二确定模块对于组进行如下判断：

当该组中服务状态为服务异常的客户端的数量大于预设阈值时，判断该组的服务状态为服务异常；

当该组中服务状态为服务异常的客户端的数量小于预设阈值时，判断该组的服务状态为服务正常。

其中，所述第二确定模块根据客户端的服务状态和组的服务状态，确定分布式系统中的控制端的服务状态可以包括：

所述第二确定模块当以下任一条件满足时，确定所述分布式系统中的控制端服务异常：

服务状态为服务异常的组的占比超过第一预设比例阈值；

服务状态为服务异常的客户端的占比超过第二预设比例阈值。

服务状态不是服务正常的客户端的占比超过第三预设比例阈值。

一种用于进行分布式系统监控的电子设备，包括：处理器和存储器；

所述存储器用于保存用于进行分布式系统监控的程序，所述用于进行分布式系统监控的程序在被所述处理器读取执行时，执行以下操作：

获取分布式系统中客户端的通信统计数据；

根据所述客户端的通信统计数据，确定客户端的服务状态；

根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

一种分布式系统，包括：客户端、控制端；

监控端，用于获取分布式系统中客户端的通信统计数据；根据所述客户端的通信统计数据，确定客户端的服务状态；根据客户端的服务状态，确定所述分布式系统中的master的服务状态。

一种存储介质，所述存储介质存储有用于进行分布式系统监控的程序；所述用于进行分布式系统监控的程序被执行时进行如下操作：

获取分布式系统中客户端的通信统计数据；

根据所述客户端的通信统计数据，确定客户端的服务状态；

根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

本申请包括以下优点：

本申请至少一个实施例可以不依赖于控制端之间的网络心跳包来判断控制端是否正常，而是可以根据对分布式系统中客户端的通信情况进行统计的结果来确定控制端的服务状态，从而可以及时发现控制端服务异常的情况，避免控制端故障没有及时发现而对系统造成的影响，提高系统的可用性。

本申请实施例的一种实现方式中，先按组判断服务状态，再根据组的服务状态和客户端的服务状态确定控制端的服务状态，这样可以防止误判。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1是gfs的架构示意图；

图2是实施例一的分布式系统的监控方法的流程图；

图3是实施例一的例子中分布式系统的示意图；

图4是实施例二的分布式系统的监控装置的示意图。

具体实施方式

下面将结合附图及实施例对本申请的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本申请实施例以及不同实现方式中的特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在一种配置中，进行分布式系统监控的计算设备可包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存(memory)。

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

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

实施例一、一种分布式系统的监控方法，如图2所示，包括步骤s110～s130。

s110、获取分布式系统中客户端的通信统计数据；

s120、根据所述客户端的通信统计数据，确定客户端的服务状态；

s130、根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

本实施例中，可以不依赖于控制端之间的网络心跳包来判断控制端是否正常，而是可以根据对分布式系统中客户端的通信情况进行统计的结果来确定控制端的服务状态，从而可以及时发现控制端服务异常的情况，避免控制端故障没有及时发现而对系统造成的影响，提高系统的可用性。

本实施例中，分布式系统不限于前文所列举的gfs，还可以是其它包含控制端、客户端及服务端的分布式系统，比如分布式存储系统，分布式文件系统等。其中，服务端(server)是管理数据存储介质的节点或组件，可以包括块服务器、数据节点(datanode)等；控制端(master)是管理命名空间的节点或组件，也可以是名字节点(namenode)等。

本实施例中，所述步骤s110～s130可以周期性执行，也可以在满足触发条件时执行。

本实施例中，客户端(client)的通信统计数据中可以携带有该client的标识，以供区分开不同client的通信统计数据。

本实施例中，所述步骤s110～s130可以但不限于通过分布式系统中，或分布式系统之外的一个第三方监管节点来执行。

本实施例中，所述客户端可以包括一个或多个；当包括多个客户端时，步骤s120可以包括：根据各客户端的通信统计数据，分别确定各客户端的服务状态；步骤s130可以包括：根据这多个客户端中部分或全部客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

本实施例，所述客户端可以包括分布式系统中的全部或部分客户端。

本实施例中，所述client的通信统计数据可以由client自身采集，也可以通过另外的节点实时监视client的通信数据并采集，或者由第三方监管节点。采集通信统计数据的节点可以将所采集的通信统计数据上报给第三方监管节点，或者由第三方监管节点自行提取。

一种实现方式中，所述确定所述分布式系统中的master的服务状态后还可以包括：

当确定所述分布式系统中的master的服务状态为服务异常后，发起master的切换。

本实现方式可以适用于存在多个master节点的分布式系统；可以由第三方监管节点通知primarymaster停止工作，并指示secondarymaster选举新的primarymaster，也可以直接由第三方监管节点指定新的primarymaster。

其它实现方式中，也可以在确定所述分布式系统中的master的服务状态为服务异常后，通知管理人员进行维护或发出警报等。

一种实现方式中，一个client的通信统计数据可以包括该client与server通信成功、失败的次数、该client与master通信成功、失败的次数。

本实现方式中，client向master(或server)发送一个消息并收到回应，可以将该client与master(或server)通信成功的次数增加1次；client向master(或server)发送一个消息但未收到对应，可以将该client与master(或server)通信失败的次数增加1次。

其它实现方式中，通信统计数据也可以包括其它内容，比如通信的成功率/失败率等。

本实现方式中，所述根据所述client的通信统计数据，确定client的服务状态可以包括：

对于client进行如下判断：

如果该client和master通信失败的次数大于和master通信成功的次数，且该client和server通信成功的次数大于和server通信失败的次数，则判断该client的服务状态为服务异常；

如果该client和master通信失败的次数小于和master通信成功的次数，则判断该client的服务状态为服务正常。

本实现方式中，只有当client和master通信失败较多，但和server通信失败较少的情况下，才确定client的服务状态为服务异常，这里所说的client的服务状态是“服务异常”可以表示client所使用的服务是异常状态的，而不是指client本身异常。

本实现方式中，当client包括多个时，可以分别对各client进行本实现方式中的上述判断。

本实现方式中，当client和master通信失败的次数等于通信成功的次数时，可以按照client和master通信失败的次数大于通信成功的次数时的方式处理，也可以按照client和master通信失败的次数小于通信成功的次数时的方式处理。

本实现方式中，在client和master通信失败的次数大于和master通信成功的情况下，如果该client和server通信成功的次数小于和server通信失败的次数，则可以自行设置该情况下client的服务状态，比如可以设置为服务正常和服务异常之外的第三种状态，例如：待判断。

本实现方式中，在client和master通信失败的次数大于和master通信成功的情况下，如果该client和server通信成功的次数等于和server通信失败的次数，则可以按照该client和server通信成功的次数大于和server通信失败的次数时的方式处理，也可以按照该client和server通信成功的次数小于和server通信失败的次数时的方式处理。

其中，确定client的服务状态的一种做法可以是：

如果该client和master通信失败的次数是和master通信成功的次数的n倍或以上，且该client和server通信成功的次数是和server通信失败的次数的m倍或以上，则判断该client的服务状态为服务异常；

如果该client和master通信失败的次数未达到和master通信成功的次数的n倍，则判断该client的服务状态为服务正常。

其中，n和m的值可以根据系统服务质量要求进行设定。

其中，在计算倍数时，为了防止除数是0造成倍数无意义的情况发生，可以先判断client和master通信成功的次数、client和server通信失败的次数是否为0，如果为0则改成1后再进行上述判断。

其它实现方式中，也可以通过其它方式来确定client的服务状态，比如可以根据client和master、server各自通信的成功率(通信成功的次数除以通信总次数)或失败率来判断client的服务状态。

本实现方式中，根据所述客户端的通信统计数据，确定客户端的服务状态还可以包括：

对于client进行如下判断：如果该client和master、server通信的次数均为0，则判断该client的服务状态为：未上报数据。

一种实现方式中，所述根据所述client的通信统计数据，确定client的服务状态前还可以包括：

根据client的通信统计数据，判断分布式系统中总的通信次数(包括client和master、client和server、server和master之间的通信)是否大于或等于预设的通信总次数阈值，如果大于或等于预设的通信总次数阈值，则进行所述根据所述client的通信统计数据，确定client的服务状态的步骤。

本实现方式中，如果分布式系统中总的通信次数小于或等于预设的通信总次数阈值，则不进行所述根据所述client的通信统计数据，确定client的服务状态的步骤(即：分布式系统中总的通信次数等于预设的通信总次数阈值时，可以进行步骤s120，也可以不进行步骤s120)。

本实现方式可以避免在样本数过小的情况下出现误判。

其中，通信次数可以但不限于是指远程过程调用(remoteprocedurecall，rpc)的次数。

一种实现方式中，所述根据client的服务状态，确定所述分布式系统中的master的服务状态可以包括：

分别统计组中服务状态为服务正常和服务异常的client的数量；根据统计结果确定组的服务状态；

根据client的服务状态和组的服务状态，确定所述分布式系统中的master的服务状态。

本实现方式中，所述组可以包括一个或多个组；当包括多个组时，可以分别根据各组的统计结果，确定各组的服务状态。

本实现方式中，一个client可以只属于一个组。

本实现方式中，也可以存在不属于任何一个组的client。

本实现方式中，组可以事先划分，比如但不限于将一个机架(rack)的机器节点中的client划为一组。如果服务异常的client都集中在一个或几个组，则可能是该组对应的机器节点或设备出现了问题，而不是master服务异常；本实现方式可以通过按组聚合client的服务状态来减少误判。

比如，一个rack上的机器节点通常连接同一个交换机，有时某个交换机可能出现暂时性的性能波动，而按照rack聚合client的服务状态，就可以尽量避免在交换机性能波动的情况误判成需要切换master。比如聚合后发现系统中只有一个rack服务异常，其它rack都服务正常，则很可能是交换机的性能波动，而不需要切换master。

其它实现方式中，也可以直接通过服务异常的client的占比来确定master的服务状态，而不用先确定组的服务状态。

本实现方式中，所述根据统计结果确定组的服务状态可以包括：

对于组进行如下判断：

当该组中服务状态为服务异常的client的数量大于预设阈值时，判断该组的服务状态为服务异常；

当该组中服务状态为服务异常的client的数量小于预设阈值时，判断该组的服务状态为服务正常。

其中，当组包括多个时，可以分别对各组进行上述判断。

其中，组中服务状态为服务异常的client的数量等于预设阈值时的情况，可以自行设置是作为该组服务正常的情况，还是作为该组服务异常的情况。

其中，预设阈值可以但不限于为组中机器节点的数量，服务异常的client的数量大于预设阈值表明：组中平均每个机器节点至少存在一个服务异常的client。

其它实现方式中，也可以通过其它方式来确定组的服务状态。

本实现方式中，所述根据client的服务状态和组的服务状态，确定所述分布式系统中的master的服务状态可以包括：

当满足以下任一条件时，确定所述分布式系统中的master服务异常：

服务状态为服务异常的组的占比超过第一预设比例阈值；

服务状态为服务异常的client的占比超过第二预设比例阈值。

服务状态不是服务正常的client的占比超过第三预设比例阈值。

其中，第一、第二、第三预设比例阈值可以根据系统需求或经验值、实验值等设置。

本实现方式中，通过上述三个条件从不同维度判断master是否需要切换进行判断。

本实现方式中，client的占比可以是指在分布式系统所有client或步骤s110获取到通信统计数据的client中的占比，也可以是在分布式系统或步骤s110获取到通信统计数据的、除了有问题的client以外的所有client中的占比；其中，有问题的client可以是指与master、server的通信失败次数都大大多于通信成功次数的client。

其它实现方式中，也可以通过其它条件来确定master是否异常，比如根据服务异常或服务正常的组或client和预设的数量阈值比较的结果进行判断；再比如以上条件全都满足或部分满足时确定master异常。

下面用一个例子说明本实施例。

本例子的分布式系统的架构如图3所示，包括：master、仲裁节点(supervisor)、多个机器节点。其中，由仲裁节点执行上述步骤s110～s130，以根据通信统计数据判断master是否服务异常，并在异常时发起切换master。

本例中，master包括三个节点，其中一个是primarymaster，另外两个是secondarymaster。多台机器节点与master进行通信，其中每台机器节点上可以包含以下一个或两个组件：server和client。

本例中，仲裁节点可以周期性获取各client的通信统计数据；获取时可以由各client主动上报给仲裁节点，也可以由仲裁节点主动从各client中提取。仲裁节点获取通信统计数据后，client可以删除已被获取的通信统计数据，重新开始采集。

本例中，由各clinet分别采集本client的通信统计数据。其中，通信统计数据包括本client与server通信成功、失败的次数、本client与master通信成功、失败的次数。

如果不是周期性获取的情况，则client还可以记录采集所述通信统计数据的时间段的长度并提供给仲裁节点，比如本次上报给仲裁节点的通信统计数据是根据采集了5秒的数据统计得到的，则将“5秒”也提供给仲裁节点。

本例中，当获取到各client的通信统计数据后，仲裁节点按照以下流程进行数据聚合，包括步骤201～203：

201、分类

仲裁节点分别根据各client通信统计数据中该client与master、server通信失败和通信成功的次数，确定该client的服务状态(即：对client进行分类)，具体包括：

如果该client和master通信失败的次数是通信成功的次数的n倍或以上，且该client和server通信成功的次数是通信失败的次数的m倍或以上，则判断该client的服务状态为：服务异常；

如果该client和master通信失败的次数未达到通信成功的次数的n倍，则判断该client的服务状态为：服务正常；

如果该client和master、server通信的次数为0，则判断该client的服务状态为：未上报数据。

其中，n和m可以根据系统服务质量要求进行设定。

其中，如果client和master、server通信失败的次数都比通信成功的次数多，则判断是该client出现了问题，后续步骤中如果用到client的总数时，可以忽略该client，比如在计算服务异常的client的占比时，可以不将出现问题的client算入总数内；假设系统中共有100个client，如果有一个client出现问题，9个client服务异常，则服务异常的client的占比是9/99。

其中，在计算倍数时，为了防止除数是0造成倍数无意义的情况发生，可以先判断client和master通信成功的次数、client和server通信失败的次数是否为0，如果为0则改成1后再进行上述判断。

实际应用中不必通过计算通信成功的次数是通信失败的次数的几倍来进行判断，也可以通过其它方式，比如通过通信失败的次数和通信成功的次数之差进行判断，再比如可以通过成功率(通信成功的次数除以通信总次数)/失败率(通信失败的次数除以通信总次数)进行判断。

其中，仲裁节点可以先判断系统中该周期内总的rpc的数量是否大于预设的通信总次数阈值，如果大于则分别判断各client的服务状态，如果不大于则暂时不进行判断。这样可以避免在样本数过小的情况下出现误判。

202、数据聚合

按照机架(rack)对client的服务状态进行聚合。

通常，一个分布式系统可以包括一个或多个rack，一个rack可以包括一个或多个机器节点，一个机器节点可以包括一个或多个client。

本步骤中，对于每个rack，分别统计服务状态为服务正常和服务异常的client的数量，忽略服务状态为未上报数据的client；分别根据每个rack的统计结果确定该rack的服务状态，具体包括：

当该rack中服务状态为服务异常的client的数量大于预设阈值时，判断该rack的服务状态为服务异常；

当该rack中服务状态为服务异常的client的数量小于预设阈值时，判断该rack的服务状态为服务正常。

其中，服务状态为服务异常的client的数量恰好等于预设阈值时，可以自行设置是确定成rack服务正常，还是确定成rack服务异常。

其中，服务状态为服务异常的client的数量大于预设阈值的情况包括：所有client服务异常，或者大多数机器上的client服务异常。

其中，服务状态为服务异常的client的数量小于预设阈值的情况包括：所有client服务正常，或者少量机器上的client服务异常。

预设阈值可以设置成rack中机器节点的数量或比例，比如上述“大多数机器上的client服务异常”的定义可以是：

当k＝1或k＝2时，rack中达到或超过1/2的client服务异常；

当k≥3时，rack中达到或超过1/k的client服务异常。

相应地，“少量机器上的client服务异常”的定义可以是：

当k＝1或k＝2时，rack中不到1/2的client服务异常；

当k≥3时，少于1/k的client服务异常。

其中k是rack的每台机器节点上client的数量(本例中，假设一个rack中的每台机器节点上的client数量相同)。

本例中，假设一个rack中有10个机器节点，每个机器节点上有3个client，也就是该rack中共有30个client；当该rack中至少有30×1/3的client服务异常(相当于平均下来每台机器节点至少存在一个服务异常的client)时，就认为大多数机器上的client服务异常，判断该rack服务异常。这样做是为了避免某个服务自身存在异常，导致上报数据错而影响聚合结果。

本步骤可以作为可选步骤，可以直接根据client的服务状态判断是否切换master，而不用先按照rack进行聚合。另外，也可以按照其它单位来聚合client，而不一定按照rack。

203、判断是否切换master。

根据client的服务状态和聚合得到的各rack的服务状态，判断master是否服务异常需要切换，检查条件如下：

条件1、服务状态为服务异常的rack的占比超过第一预设比例阈值；

条件2、服务状态为服务异常的client的占比超过第二预设比例阈值。

条件3、服务状态不是服务正常(即服务状态为服务异常和未上报数据)的client的占比超过第三预设比例阈值。

上述三个条件满足其中任意一个则发起master切换操作。

其中，第一、第二、第三预设比例阈值可以设置成相同或不同；条件2和条件3也可以合并成条件3，即不对服务异常的client单独进行判断，而是和未上报数据的client一起进行判断。

其中，发起master切换操作可以是指仲裁节点停止当前的primarymaster，并指示其余secondarymaster选举新的primarymaster，或者直接指定一个secondarymaster作为新的primarymaster。

实施例二、一种分布式系统的监控装置，如图4所示，包括：

获取模块21，用于获取分布式系统中客户端的通信统计数据；

第一确定模块22，用于根据所述客户端的通信统计数据，确定客户端的服务状态；

第二确定模块23，用于根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

本实施例中，所述获取模块21是上述监控装置中负责获取通信统计数据的部分，可以是软件、硬件或两者的结合。

本实施例中，所述第一确定模块22是上述监控装置中负责确定客户端服务状态的部分，可以是软件、硬件或两者的结合。

本实施例中，所述第二确定模块23是上述监控装置中负责确定master服务状态的部分，可以是软件、硬件或两者的结合。

一种实现方式中，所述监控装置还可以包括：

控制模块，用于当确定所述分布式系统中的master的服务状态为服务异常后，发起master的切换。

一种实现方式中，所述第一确定模块还可以用于在根据所述client的通信统计数据，确定client的服务状态前，根据client的通信统计数据，判断分布式系统中总的通信次数是否大于或等于预设的通信总次数阈值，如果大于或等于预设的通信总次数阈值，则进行所述根据所述client的通信统计数据，确定client的服务状态的操作。

一种实现方式中，client的通信统计数据可以包括该client与服务端server通信成功、失败的次数、该client与master通信成功、失败的次数。

本实现方式中，所述第一确定模块根据所述client的通信统计数据，确定client的服务状态可以包括：

所述第一确定模块对于client进行如下判断：

如果该client和master通信失败的次数大于和master通信成功的次数，且该client和server通信成功的次数大于和server通信失败的次数，则判断该client的服务状态为服务异常；

如果该client和master通信失败的次数小于和master通信成功的次数，则判断该client的服务状态为服务正常。

一种实现方式中，所述第二确定模块根据client的服务状态，确定所述分布式系统中的master的服务状态可以包括：

所述第二确定模块分别统计组中服务状态为服务正常和服务异常的client的数量；根据统计结果确定组的服务状态；根据client的服务状态和组的服务状态，确定所述分布式系统中的master的服务状态。

本实现方式中，所述第二确定模块根据统计结果确定组的服务状态可以包括：

所述第二确定模块对于组进行如下判断：

当该组中服务状态为服务异常的client的数量大于预设阈值时，判断该组的服务状态为服务异常；

当该组中服务状态为服务异常的client的数量小于预设阈值时，判断该组的服务状态为服务正常。

本实现方式中，所述第二确定模块根据client的服务状态和组的服务状态，确定分布式系统中的master的服务状态可以包括：

所述第二确定模块当以下任一条件满足时，确定所述分布式系统中的master服务异常：

服务状态为服务异常的组的占比超过第一预设比例阈值；

服务状态为服务异常的client的占比超过第二预设比例阈值。

服务状态不是服务正常的client的占比超过第三预设比例阈值。

本实施例中，分布式系统的监控装置的各模块的操作可以分别对应于实施例一中的步骤s110～s130，各模块操作的其它实现细节可参见实施例一。

实施例三、一种用于进行分布式系统监控的电子设备，包括：处理器和存储器；

所述存储器用于保存用于进行分布式系统监控的程序，所述用于进行分布式系统监控的程序在被所述处理器读取执行时，执行以下操作：

获取分布式系统中客户端的通信统计数据；

根据所述客户端的通信统计数据，确定客户端的服务状态；

根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

一种实现方式中，所述用于进行分布式系统监控的程序在被所述处理器读取执行时，还可以执行以下操作：

当确定所述分布式系统中的master的服务状态为服务异常后，发起master的切换。

一种实现方式中，所述用于进行分布式系统监控的程序在被所述处理器读取执行时，在根据所述client的通信统计数据，确定client的服务状态前还可以执行以下操作：

根据client的通信统计数据，判断分布式系统中总的通信次数是否大于预设的通信总次数阈值，如果大于或等于预设的通信总次数阈值，则进行所述根据所述client的通信统计数据，确定client的服务状态的操作。

一种实现方式中，client的通信统计数据可以包括该client与服务端server通信成功、失败的次数、该client与master通信成功、失败的次数。

本实现方式中，所述用于进行分布式系统监控的程序在被所述处理器读取执行时，根据所述client的通信统计数据，确定client的服务状态可以包括：

对于client进行如下判断：

如果该client和master通信失败的次数大于和master通信成功的次数，且该client和server通信成功的次数大于和server通信失败的次数，则判断该client的服务状态为服务异常；

如果该client和master通信失败的次数小于和master通信成功的次数，则判断该client的服务状态为服务正常。

一种实现方式中，所述用于进行分布式系统监控的程序在被所述处理器读取执行时，根据client的服务状态，确定所述分布式系统中的master的服务状态可以包括：

分别统计组中服务状态为服务正常和服务异常的client的数量；根据统计结果确定组的服务状态；根据client的服务状态和组的服务状态，确定所述分布式系统中的master的服务状态。

本实现方式中，根据统计结果确定组的服务状态可以包括：

对于组进行如下判断：

当该组中服务状态为服务异常的client的数量大于预设阈值时，判断该组的服务状态为服务异常；

当该组中服务状态为服务异常的client的数量小于预设阈值时，判断该组的服务状态为服务正常。

本实现方式中，根据client的服务状态和组的服务状态，确定分布式系统中的master的服务状态可以包括：

当以下任一条件满足时，确定所述分布式系统中的master服务异常：

服务状态为服务异常的组的占比超过第一预设比例阈值；

服务状态为服务异常的client的占比超过第二预设比例阈值。

服务状态不是服务正常的client的占比超过第三预设比例阈值。

本实施例中，用于进行分布式系统监控的程序在被处理器读取执行时，所执行的操作对应于实施例一中的步骤s110～s130；该程序所执行的操作的其它细节可参见实施例一。

实施例四、一种分布式系统，包括：客户端、控制端；

监控端，用于获取分布式系统中客户端的通信统计数据；分别根据所述客户端的通信统计数据，确定客户端的服务状态；根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

本实施例中的分布式系统还可以包括server，架构可以参照图3所示的分布式系统。

本实施例中，监控端所执行的操作可以对应于实施例一中的步骤s110～s130，其它实现细节可参见实施例一。

实施例五、一种存储介质，存储有用于进行分布式系统监控的程序；所述用于进行分布式系统监控的程序被执行时进行如下操作：

获取分布式系统中客户端的通信统计数据；

根据所述客户端的通信统计数据，确定客户端的服务状态；

根据客户端的服务状态，确定所述分布式系统中的控制端的服务状态。

本实施例中，用于进行分布式系统监控的程序被执行时，所进行的操作对应于实施例一中的步骤s110～s130；该程序所进行的操作的其它细节可参见实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

当然，本申请还可有其他多种实施例，在不背离本申请精神及其实质的情况下，熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形，但这些相应的改变和变形都应属于本申请的权利要求的保护范围。