CN109873713B

CN109873713B - 用于位置服务的无中心化服务集群系统及故障检测方法

Info

Publication number: CN109873713B
Application number: CN201811620264.1A
Authority: CN
Inventors: 王穆; 路松峰; 付四凯
Original assignee: Huazhong University of Science and Technology
Current assignee: Huazhong University of Science and Technology
Priority date: 2018-12-28
Filing date: 2018-12-28
Publication date: 2020-07-10
Anticipated expiration: 2038-12-28
Also published as: CN109873713A

Abstract

本发明公开了一种用于位置服务的无中心化服务集群系统及故障检测方法，采用区域划分使得每个区域分布在不同的服务节点上，保障读写时间复杂度不因用户的增加而增加；达到设计的性能瓶颈时，将区域划分为若干个区域以横向扩展，满足高并发的读写要求；对区域进行主从设计，当区域所在服务节点发生故障，备份节点提供服务，实现高可用；服务节点之间通过定期的消息同步和故障检测来获取网络拓扑，将请求路由到合适的服务节点上，保持最终一致性；通过直接和间接发送探测消息来标记怀疑节点，等待被怀疑的节点来反驳，避免由于消息无法得到及时回复而产生的误报；同时动态调整发送探测消息和怀疑节点被怀疑的时间，来加快网络拓扑的收敛。

Description

用于位置服务的无中心化服务集群系统及故障检测方法

技术领域

本发明属于位置服务技术领域，更具体地，涉及一种用于位置服务的无中心化服务集群系统及故障检测方法。

背景技术

位置服务需要根据一个点的经纬度来查询周围附近的服务用户。很多业务服务都依赖于位置服务。对于交通出行领域，需要查找附近的司机。司机的位置变化就相对较大，而且对司机的位置的准确性要求也相对较高，否则，会导致司机的拒载和客户的投诉。对于城市智能系统，需要判断道路的拥挤状况，这个对位置服务用户的实际地理位置的准确性要求也是非常高的。所以，位置服务的高可用和数据的相对准确性会非常重要。这种服务有如下特点：1.服务使用者的数量庞大，同时，为了保证用户地理位置的准确性，每个用户会较高频率地上报自己的地理位置，因此，对服务的写性能会有很大要求。2.大量的业务依赖这个基础服务，对实时查询的性能要求也会非常高。3.要保证服务不能发生宕机，服务调用的延时不能太大。

位置服务对于数据存储要求经纬度在逻辑上存在有序关系。例如，3的周围是1和2。大于10小于5的整数有6，7，8，9。在实际情况中性能要求不高的情况下，可以查询平衡树来存放这样的数据结构。但是高并发的写会导致需要大量的性能来实现平衡树的分裂和再平衡。同时，也可以采用Geo hash的方式。将Geo hash存储在Redis有序集合(Sorted Set)中，再通过有序集合的有序性来实现位置服务。但是有序集合不是很好的扩展，只能在业务上将每个城市分割为一个一个的有序集合，不能做到很好的扩展。同时Geo hash这种算法会在赤道附近发生跳变，导致查询出来的数据不是非常准确。

发明内容

针对现有技术的缺陷，本发明的目的在于解决现有技术无法实现高并发实时读写地理位置的技术问题。

为实现上述目的，第一方面，本发明实施例提供了一种用于位置服务的无中心化服务集群系统，所述无中心化服务集群系统由多个服务节点组成，每个服务节点在网络拓扑上无差异，只提供一个区域的位置数据，所述区域是根据经度和纬度对地球进行二维分割得到的多个分割中的一个，每个区域由多个存储用户地理位置的单元组成，服务节点之间通过定期的消息同步和故障检测来获取整个无中心化服务集群系统的网络拓扑。

具体地，对区域进行主从设计，让其交叉分布在不同的服务节点上：同一行的区域分别为主从区域，同一列的区域在同一服务节点上。

具体地，所述无中心化服务集群系统采用定期同步数据的方式来同步网络拓扑信息，通过获取其他服务节点的健康状态合并以后，再推送出去；所述服务节点的健康状态包括三种：死亡、怀疑和存活。

具体地，所述无中心化服务集群系统采用服务节点之间定期直接故障检测和间接故障检测来进行故障检查；其中，直接故障检查指的是直接通过服务节点去探测其他服务节点与此服务节点网络相通的节点，所述间接故障检查是指在直接故障检查得不到及时消息回复时，让与网络相通的若干节点来代替它进行故障检查，然后把探测结果传递给它。

具体地，所述无中心化服务集群系统引入故障节点怀疑机制，将不能及时回复直接故障检测和间接故障检测消息的节点标记为怀疑节点，等待被怀疑的节点来反驳纠正这条消息。

具体地，在系统的某个区域达到设计的性能瓶颈时，通过再次将此区域进行划分为多个子区域，从而实现系统的横向扩展。

第二方面，本发明实施例提供了一种用于如第一方面所述的无中心化服务集群系统的故障检测方法，所述故障检测方法包括：节点探测进程、网络拓扑消息传播进程和消息同步进程，三个进程并行，具体如下：

所述节点探测进程包括以下步骤：

(1)从已知道的节点列表中选择一个节点；

(2)判断选择的节点是否为死亡节点，若是，从节点列表中移除死亡节点，进入下一次探测；否则，进入步骤(3)；

(3)向选择的节点发送直接探测消息，判断是否及时收到回复，若是，则缩减等待消息的间隔，将选择的节点标记为存活节点，进入下一次探测；否则，选择向其他节点发送间接探测消息，根据期待消息个数与实际接收到消息个数的差值，增加等待消息的间隔，将选择的节点标记为怀疑节点，进入下一次探测；

所述网络拓扑消息传播进程具体为：从存活节点、怀疑节点或近期死亡的死亡节点中选择logN个节点，将节点中重要的消息广播给这logN个节点；

所述消息同步进程具体为：根据所述节点探测进程中更新的等待消息的间隔，设置下一次同步消息的时间，将节点状态信息同步。

具体地，若怀疑节点在被怀疑时间内进行反驳，则将该节点标记为存活节点；若怀疑节点在被怀疑时间内未被纠正，则将该节点标记为死亡节点。

具体地，被怀疑时间t_out＝max(mint_out,maxt_out-(maxt_out-mint_out)*log(K+1)/log(N+1))，其中，mint_out为最小时间周期，maxt_out为最大时间周期，K为收到其他节点对同一节点的怀疑消息的数量，N为节点列表中节点总个数。

具体地，所述节点探测进程中改变等待消息的间隔的方式如下：

(1)直接探测成功，score执行减1，如果score小于0，将其置零；直接探测失败，score执行加1，如果score大于设定的最大值，将其设置为最大值；

(2)收到怀疑节点反驳自己不是怀疑节点的消息，score执行加1，如果score大于设定的最大值，将其设置为最大值；

(3对怀疑节点进行间接探测，如果有n个节点没有返回消息，score+n，如果score大于设定的最大值，将其设置为最大值；

(4)等待消息的间隔t_interval＝t_set*(score+1)，t_set为设置等待消息的时间间隔，score为度量当前的网络环境的变量。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有以下有益效果：

1.本发明采用将地球进行区域划分，每个区域分布在不同的服务节点上，区域由若干个单位组成，每个单元存储着具体的用户地理位置，这个可以保障服务的读写时间复杂度不会因为服务用户的增加而增加，某个区域达到设计的性能瓶颈时通过再次将此区域进行划分为若干个区域从而达到系统的横向扩展，从而满足了高并发的读写要求。

2.本发明通过对区域进行主从设计，当一个区域所在的节点发生故障的时候可以有备份节点来提供服务，从而实现高可用。

3.本发明的服务节点之间通过定期的消息同步和故障检测来获取整个无中心化服务集群系统的网络拓扑，然后将具体的请求路由到能够提供服务的节点上，使得每一个服务节点对整个无中心化服务集群系统的网络拓扑信息保持最终一致性，同时对外提供稳定的地理位置服务。

4.本发明通过直接和间接发送探测消息来判断服务节点是否故障，对判断的故障节点不立刻采取措施，而是标记为怀疑节点，等待被怀疑的节点来澄清误报，避免由于消息无法得到及时回复而产生的误报；同时动态调整发送探测消息和怀疑节点被怀疑的时间，来加快网络拓扑的收敛。

附图说明

图1为本发明实施例提供的位置服务系统结构示意图；

图2为本发明实施例提供的查询请求位置服务的流程图；

图3为本发明实施例提供的直接故障检测和间接故障检测示意图；

图4为本发明实施例提供的故障检测的流程图；

图5为本发明实施例提供的区域主从设计示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

首先，对本发明中用到的一些术语进行解释。

位置服务：包括任何基于位置或与位置有关的服务，例如，个人定位、手机导航、物流跟踪、个人位置定位等，其应用场景包括：手机导航、社交网络、车载导航、老年人关爱、应急救援、交通路线规划、医疗定位、物流监控等。

本发明使用系统架构设计、数据一致性设计、节点故障检测策略和动态的服务扩展修复，实现高并发实时读写位置服务、服务的低延时高可用。

如图1所示，位置服务系统包括：网关代理、服务编排和无中心化集群。

网关代理分为两部分：一部分面向Web端用户，负责提供统一的调用接口给用户，通过该接口，将用户的位置服务请求路由到无中心化集群，将无中心化集群反馈的请求结果返回给用户；另一部分面向移动端用户，负责负载均衡SDK，有效地将请求直接路由到合适的服务节点上。

服务编排负责提供位置服务的动态创建和删除，根据无中心化集群广播的网络拓扑信息(包含故障信息)来自动发布代码部署服务，创建服务节点来替代无中心化集群中故障的服务节点。

无中心化服务集群是提供位置服务的实体，由多个服务节点组成。服务节点之间通过定期消息同步和故障检测，确保系统信息的准确性和系统的健康。

本发明根据经度和纬度对地球进行二维分割，每个分割称为一个区域。每个区域由若干单元(CELL)组成，每个单元里面存储用户的地理位置。通过位置的经纬度，可准确定位到具体区域和具体单元。对地理位置进行区域划分，实现多地多机房的部署，可实现访问低延迟，保障位置服务的读/写时间复杂度不会因为服务用户的增加而增加。具体地，服务节点通过定时的故障检测和消息同步来了解整个无中心化服务集群系统的网络拓扑，然后将具体的请求路由到能够提供服务的节点上。

本发明采用无中心化服务集群系统架构，每个服务节点在网络拓扑上无差异，差异体现在服务节点上提供的数据。特定区域的服务节点只提供该区域的位置数据，而无法提取其他区域的位置数据，因此各服务节点提供的数据是不同的。区别于现有技术需要知道系统的所有服务节点，由于架构设计是无中心的，所以每个服务节点需要清楚整个无中心化服务集群系统的网络拓扑。创建启动一个服务节点，只需要指向一个健康的服务节点，新服务节点与指向的服务节点之间进行相互探测，这个节点可学习到整个无中心化服务集群系统的网络拓扑。

如图2所示，查询请求位置服务的流程如下：

(1)判断请求用户是web端用户还是移动端用户，若是移动端用户，进入步骤(3)，若是web端用户，进入步骤(2)；

通过判断是否使用负载均衡SDK，来判断请求用户是web端用户还是移动端用户。

(2)请求网关代理，进入步骤(3)；

(3)选择合适的服务节点；

(4)选中的服务节点根据请求用户的位置信息和区域范围，计算涉及到的区域；

(5)涉及到区域的服务节点获取查询区域范围内的位置信息，并返回给选中的服务节点；

有可能请求用户发送请求时，位于多个区域的交界处，这些涉及到的区域的服务节点均去获取相关位置信息。

(6)选中的服务节点将返回的相关位置信息整理后，反馈给用户。

根据CAP定理，一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性)，三者不可兼得。只能满足分布式服务特性三者中的两个。为了满足服务的低延时，位置服务必须要采用多地多机房部署，因而具有天然的分区容错性，无法保障网络的百分百可用。所以只需在服务可用性和服务数据一致性上面进行权衡。位置服务没有必要保证数据的百分百绝对精确，但是作为基础服务需要保障非常高的可用性。本发明中数据一致性设计总体是一个AP的方案，在数据一致性上选择最终一致性。这里的“最终一致性”是指所有节点的网络拓扑信息保持最终一致性。根据区域划分的不同，服务节点上存储的位置信息是不一样的。服务经过一段时间的收敛，可提供相对准确的数据一致性服务。也就是说在一个服务节点上，服务提供的数据可能与另外一个节点上提供的数据不一样，但是经过一段时间的收敛以后，两个服务节点的数据最终一致。

服务节点与服务节点之间需要交换消息，为了在无中心化服务集群中，让每一个服务节点对整个无中心化服务集群系统的网络拓扑信息保持最终一致性，同时对外提供稳定的地理位置服务。本发明采用定期同步数据的方式来同步网络拓扑信息，通过获取其他服务节点的信息合并以后，再推送出去，直观感受为一拉一推。其他服务节点的信息是指其他服务节点的健康状态，服务节点的健康状态包括三种：死亡、怀疑和存活。服务节点与相邻服务节点同步信息并不是在一个时间周期与所有的节点进行网络拓扑信息交换，只需要确保在几个时间周期以后服务节点与周围的服务节点都交换过信息，这样可以有效地节省系统资源。服务节点会随着业务的增长而增长，为了让整个无中心化服务集群系统的网络拓扑信息的收敛速度不会因此受到显著影响，需要服务节点选择足够多的节点(从N个节点个数中选择logN个数据节点，N为无中心化集群中所有服务节点个数)进行信息交换，可以让网络拓扑信息在logN时间周期收敛。

在一个分布式系统中，单个节点出现概率的情况是非常低的，但是集群整体出现故障的概率还是相对较高的。因此需要及时地发现系统中出现故障的节点，重新部署新的节点来替代故障节点从而保障系统的健康。本发明采用服务节点之间定期直接故障检测和间接故障检测来进行故障检查。直接故障检查指的是直接通过服务节点去探测其他服务节点与此服务节点网络相通的节点。间接故障检查是指在直接故障检查得不到及时消息回复的情况，让与网络相通的若干节点来代替它进行故障检查，然后把探测结果传递给它。

在实际的应用环境中，不能直接由于短暂的故障检测失败来判断一个节点的健康状态。服务节点之间的消息传递可能是正确的也可能是错误的。由于网络原因(例如，短暂的网络抖动)和服务节点负载过高，无法及时反馈故障检测的消息，导致探测消息得不到及时的回复(故障信息的误报)，其实不是真正的服务节点出现故障，这样会给整个系统带来频繁的服务创建和删除，造成系统资源的浪费。本发明引入故障节点怀疑机制，将不能及时回复直接故障检测和间接故障检测消息的节点标记为怀疑节点，等待被怀疑的节点来反驳纠正这条消息。消息同步时被怀疑的节点再被多次确认以后还是会存在误报的情况。因为短时间服务节点还是不能及时回复检测消息。在这里采用动态的检查时间间隔，在得不到确切回复时增加探测时间间隔，在得到确切回复缩短探测时间间隔来加快网络拓扑的收敛。

如图3所示，服务节点A发送直接探测消息给服务节点B，等待服务节点B在设定的时间间隔回复消息，若服务节点B及时回复，服务节点A缩短下次等待的时间间隔；若没有等到服务节点B及时的直接的消息回复，服务节点A将选择向服务节点C和D发送间接探测消息，服务节点C和D向服务节点B转发探测消息。根据间接探测消息的回复数来加长下次等待的时间间隔。

故障节点怀疑机制具体如下：

(3对怀疑节点进行间接探测，如果有n个节点没有返回消息，score+n，如果score大于设定的最大值，将其设置为最大值。

等待消息的间隔TimeoutInterval＝ConfigTimeoutInterval*(score+1)，ConfigTimeoutInterval为设置等待消息的时间间隔。score为度量当前的网络环境的变量，最小值为0，最大值为设定值。回复数越多，加长的时间越少。

如图4所示，故障检测包括三个并行的进程，每个进程有各自的周期，具体如下：

创建节点探测进程(UDP)

(1)从已知道的节点列表中选择一个节点；

每一个服务节点都有一个自己本地的节点列表，存放与该服务节点相连通的服务节点。

(3)向选择的节点发送直接探测消息，判断是否及时收到回复，若是，则缩减等待消息的间隔，将选择的节点标记为存活节点，进入下一次探测；否则，选择向其他节点发送间接探测消息，根据期待消息个数与实际接收到的差值增加等待消息的间隔，将选择的节点标记为怀疑节点，进入下一次探测。

被怀疑的节点会收到自己被怀疑的信息，若怀疑节点在被怀疑时间内进行反驳，即怀疑节点直接给怀疑它的节点发送怀疑拒绝消息，则将该节点标记为存活节点，这个怀疑节点的状态就恢复正常了。被怀疑的节点如果真的死亡，那被怀疑的节点也不会收到消息。过了被怀疑的时间就会被认为死亡。即怀疑节点在被怀疑时间内未被纠正，则将该节点标记为死亡节点。

怀疑节点变为死亡节点的时间Timeout＝max(MinTimeout，MaxTimeout-(MaxTimeout-MinTimeout)*log(K+1)/log(N+1))，其中，MinTimeout为最小时间周期，MaxTimeout为最大时间周期，K为收到其他节点对同一节点的怀疑消息的数量，N为节点总个数。

创建网络拓扑消息传播进程(UDP)

从存活节点、怀疑节点或近期死亡的死亡节点中选择logN个节点，将节点中重要的消息广播给这logN个节点。

选择的logN个节点经过多个传播周期，可以将消息覆盖全部N个节点。

创建消息同步进程(TCP)

根据节点探测进程中更新的等待消息的间隔，设置下一次同步消息的时间，将节点状态信息同步。

使用TCP进行通讯，是为了先从选中节点获取节点状态信息，然后从将获取到的信息与自身的信息进行合并，然后再推送给被选中的节点，让被选中的节点再进行合并，这样就保证了这两个节点对于节点状态信息的一致。

在系统的某个区域达到设计的性能瓶颈时，通过再次将此区域进行划分为若干个区域从而达到系统的横向扩展。

在检测到故障(接收到节点被判定为死亡节点的消息)以后，为了达到更高的可用性，本发明通过对区域进行主从设计对服务节点进行备份。如图5所示，对区域进行主从设计，让其交叉分布在不同的服务节点上。同一行的区域分别为主从区域，例如，A为主区域，A＇为A的从区域；同一列的区域在同一服务节点上，例如，区域A和区域C＇都在服务节点1上。当服务节点1发生故障时，无法从服务节点1获取主区域A，可从备份的服务节点2获取从区域A＇。

当一个区域所在的节点发生故障的时候，故障节点检测机制及时地通知服务编排系统，服务编排系统创建健康的服务节点来替代故障服务节点，让备份节点来提供服务。服务节点故障检测和服务自动修复将会在若干个时间周期内让发生故障的区域恢复主从设计。

以上，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims

1.一种用于无中心化服务集群系统的故障检测方法，其特征在于，所述无中心化服务集群系统由多个服务节点组成，每个服务节点在网络拓扑上无差异，只提供一个区域的位置数据，所述区域是根据经度和纬度对地球进行二维分割得到的多个分割中的一个，每个区域由多个存储用户地理位置的单元组成，服务节点之间通过定期的消息同步和故障检测来获取整个无中心化服务集群系统的网络拓扑；所述故障检测方法包括：节点探测进程、网络拓扑消息传播进程和消息同步进程，三个进程并行，具体如下：

所述节点探测进程包括以下步骤：

(1)从已知道的节点列表中选择一个节点；

所述网络拓扑消息传播进程具体为：从存活节点、怀疑节点或近期死亡的死亡节点中选择logN个节点，将节点中重要的消息广播给这logN个节点，N为节点列表中节点总个数；

2.如权利要求1所述的故障检测方法，其特征在于，对区域进行主从设计，让其交叉分布在不同的服务节点上：同一行的区域分别为主从区域，同一列的区域在同一服务节点上。

3.如权利要求1所述的故障检测方法，其特征在于，所述无中心化服务集群系统采用定期同步数据的方式来同步网络拓扑信息，通过获取其他服务节点的健康状态合并以后，再推送出去；所述服务节点的健康状态包括三种：死亡、怀疑和存活。

4.如权利要求1所述的故障检测方法，其特征在于，所述无中心化服务集群系统采用服务节点之间定期直接故障检测和间接故障检测来进行故障检测；其中，直接故障检测指的是直接通过服务节点去探测其他服务节点与此服务节点网络相通的节点，所述间接故障检测是指在直接故障检测得不到及时消息回复时，让与网络相通的若干节点来代替它进行故障检测，然后把探测结果传递给它。

5.如权利要求4所述的故障检测方法，其特征在于，所述无中心化服务集群系统引入故障节点怀疑机制，将不能及时回复直接故障检测和间接故障检测消息的节点标记为怀疑节点，等待被怀疑的节点来反驳纠正这条消息。

6.如权利要求1所述的故障检测方法，其特征在于，在系统的某个区域达到设计的性能瓶颈时，通过再次将此区域进行划分为多个子区域，从而实现系统的横向扩展。

7.如权利要求1至6任一项所述的故障检测方法，其特征在于，若怀疑节点在被怀疑时间内进行反驳，则将该节点标记为存活节点；若怀疑节点在被怀疑时间内未被纠正，则将该节点标记为死亡节点。

8.如权利要求7所述的故障检测方法，其特征在于，被怀疑时间Timeout＝max(MinTimeout，MaxTimeout–(MaxTimeout-MinTimeout)*log(K+1)/log(N+1))，其中，MinTimeout为最小时间周期，MaxTimeout为最大时间周期，K为收到其他节点对同一节点的怀疑消息的数量。

9.如权利要求1至6任一项所述的故障检测方法，其特征在于，所述节点探测进程中改变等待消息的间隔的方式如下：

(3)对怀疑节点进行间接探测，如果有n个节点没有返回消息，score+n，如果score大于设定的最大值，将其设置为最大值；

(4)等待消息的间隔TimeoutInterval＝ConfigTimeoutInterval(score+1)，ConfigTimeoutInterval为设置等待消息的时间间隔，score为度量当前的网络环境的变量。