CN114564340B - 航天地面系统分布式软件高可用方法 - Google Patents

Abstract

本发明公开的一种航天地面系统分布式软件高可用方法，具有高吞吐、高可用、可扩展性。本发明通过下述技术方案：首先每个代理关联一个实际的内存数据库服务，内存数据库服务代理启动以及仲裁内存数据库的主备；然后，内存数据库服务代理彼此通过心跳交互自身的状态，通过阈值时间是否收到对方代理心跳判断内存数据库服务代理及内存数据库状态，是则判定为彼此的内存数据库服务代理及内存数据库都存活，否则认为对方或者自的内存数据库服务代理及内存数据库丢失；在彼此存活的情况下，根据每个内存数据库成为主服务的时间以及彼此对应物理机的ip大小，仲裁内存数据库的主备；在彼此收不到心跳时，则与三方ip集群的通断仲裁出内存数据库的主备。

Description

航天地面系统分布式软件高可用方法

技术领域

本发明是涉及一种主要应用于航天地面站主备或主从分布式系统的高可用解决方法。

背景技术

目前分布式系统在各个领域代表了系统结构的发展方向，相对于传统的集中式系统，分布式系统信息分布与地理位置无关，程序部署方便，可靠性高等优点。如果其中某个节点失效了，则其余的节点可以继续操作，整个系统不会因为一个或少数几个节点的故障而全体崩溃。因此，分布式系统有很好的容错性能。分布式系统中各个节点通过一个通信网络互联在一起。通信网络由通信线路、调制解调器和通信处理器等组成，不同节点的用户可以方便地交换信息，通信方便、快捷。尽管分布式系统具备众多优势，但它也有自身的缺点，主要是可用软件不足，系统软件、编程语言、应用程序以及开发工具都相对很少。此外，还存在通信网络饱和或信息丢失和网络安全问题，方便的数据共享同时意味着机密数据容易被窃取。随着在轨卫星数量的不断增加，航天地面站在航天系统工程中的重要性越来越高，有限的地面站资源与航天器数量爆炸式增长的矛盾将会越来越突出。由于分布式系统几乎是解决网络业务承载量问题的最基本方法，但分布式系统并不是简单的把一堆服务器一起运行起来就能满足需求的。对比单机或少量服务器的集群，有一些特别需要解决的问题。比如分布式系统高吞吐，可以同时承载大量的用户使用。整个系统能同时服务的用户数。但这个吞吐量肯定是不可能用单台服务器解决的，因此需要多台服务器协作，才能达到所需要的吞吐量。而在多台服务器的协作中，如何才能有效的利用这些服务器，不致于其中某一部分服务器成为瓶颈，从而影响整个系统的处理能力，这就是一个分布式系统，在架构上需要仔细权衡的问题。许多应用是固有分布式的。这方面的实例有事务处理和Internet Javad，程序。这些应用的性能取决于吞吐量(事务响应时间或每秒完成的事务数)而不是一般多处理机所用的执行时间。分布式集群除了扩容，还有缩容的需求。当用户人数下降，服务器硬件资源出现空闲的时候，往往需要这些空闲的资源能利用起来，放到另外一些新的服务集群里去。由于分布式集群中的扩容、缩容，以及希望尽量能在线操作，这导致了非常复杂的技术问题需要处理。此外服务器自己的内存、硬盘等故障，服务器之间的网络线路故障更加常见。而且这种故障还有可能是偶发的，或者是会自动恢复的。面对这种问题，如果只是简单的把“出现故障”的机器剔除出去，那还是不够的。因为网络可能过一会儿就又恢复了，而集群可能因为这一下的临时故障，丢失了过半的处理能力。

航天地面站硬件系统可能主要面对的风险包括网络故障、服务器硬件故障、服务器关机以及操作系统系统运行故障等异常情况。在一台服务器出现故障(不能恢复，或者需要超过阈值的时间恢复)之后，内存数据库代理会出现彼此收不到心跳，或者是跟三方ip集群(参考机集群)不通的表现。由于在分布式系统的集群，包含了很多个服务器，当这样一个集群的硬件承载能力到达极限的时候，最自然的想法就是增加更多的硬件。然而，一个软件系统不是那么容易就可以通过“增加”硬件来提高承载性能的。因为软件在多个服务器上的工作，是需要有复杂细致的协调工作。在对一个集群扩容的时候，往往会要停掉整个集群的服务，然后修改各种配置，最后才能重新启动一个加入了新的服务器的集群。高并发是高吞吐的一个延伸需求。当在承载海量用户的时候，希望每个服务器都能尽其所能的工作，而不要出现无谓的消耗和等待的情况。然而，软件系统并不是简单的设计，就能对同时处理多个任务，做到“尽量多”的处理。很多时候，程序会因为要选择处理哪个任务，而导致额外的消耗。这也是分布式系统解决的问题。由于一个数量庞大的分布式系统，必然需要把用户的请求经过多次的分发，整个延迟可能会因为这些分发和转交的操作，变得更高。

卫星接收系统地面测控站系统监控台主要完成对全站设备，包括天线、信道、终端、标校测试及环境保障等设备的监控及管理，控制相关设备实现全系统的标校测试，除此之外还要接收并执行管理中心的控制命令及各种计划。之前的监控系统都是用的传统集中式来实现的，它存在的缺点是部署难，不可靠，可扩展性差。分布式对象技术是计算机软件业流行的一种设计思想,中间件是分布式技术中的关键技术。中间件是为解决分布异构问题提出的概念，所谓中间件就是位于操作系统和应用软件之间的一个软件层，它向各种应用软件提供服务，不同的应用进程在屏蔽掉平台差异的情况下，通过网络互相通信，也就是位于平台(硬件和操作系统)和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现，中间件的出现是分布式系统发展的产物，是软件构架演进的必然。中间件应该具有如下一些特点:满足大量应用的需要、运行于多种硬件和OS平台、支持分布计算、提供跨网络、硬件和OS平台的透明性的应用或服务的交互、支持标准的协议、支持标准的接口。由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境。由于分布式技术在航天测控地面接收系统监控分系统中，满足地面站部署的站点有限，因此航天地面站将越来越庞大，单一地面站将包含数十套天线系统，这就给地面站的运行管理提出了很高的要求。因此，分布式软件系统在航天地面站也开始大量使用。所谓分布式系统，肯定就不是只有一台服务器。在实际生产环境，一个独立的服务器进程自身并不带特别的集群功能。也就是说这并不能直接组建成一个统一的集群。如果一个不够用，就要手工用代码去分配，这对于真正的大型分布式系统来说，管理一个这样的缓冲系统，是一个很繁琐的工作。因此传统集群高可用方法需要至少3台机器或者3个选举服务才能够搭建起本地开发环境，双机部署的分布式系统，如果网络出现故障带来的系统架构缺陷问题，传统的双机高可用则会在此时出现双主内存数据库服务或者双备内存数据库服务的情况，在此种情况下还是避免不了双主或双备内存数据库服务的出现。高并发是高吞吐的一个延伸需求。当在承载海量用户的时候，当然希望每个服务器都能尽其所能的工作，而不要出现无谓的消耗和等待的情况。然而，软件系统并不是简单的设计，就能对同时处理多个任务，做到“尽量多”的处理。很多时候，程序会因为要选择处理哪个任务，而导致额外的消耗。这也是分布式系统解决的问题。低延迟对于人数稀少的服务来说不算什么问题。然而，如果需要在大量用户访问的时候，也能很快的返回计算结果，这就要困难的多。因为除了大量用户访问可能造成请求在排队外，还有可能因为排队的长度太长，导致内存耗尽、带宽占满等空间性的问题。如果因为排队失败而采取重试的策略，则整个延迟会变的更高。所以分布式系统会采用很多请求分拣和分发的做法，尽快的让更多的服务器来处理用户的请求。由于一个数量庞大的分布式系统，必然需要把用户的请求经过多次的分发，整个延迟可能会因为这些分发和转交的操作，变得更高，所以分布式系统除了分发请求外，还要尽量想办法减少分发的层次数，以便让请求能尽快的得到处理。计算高可用相比于存储高可用而言，其复杂度和难度降低不少。分布式系统是支持分布式处理的软件系统，是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统、分布式数据库系统等，当然这些也是分布式的关键技术。分布式系统虽然有一些优势，但也存在一些问题，架构设计变得复杂(尤其是其中的分布式事务)，部署单个服务会比较快，但是如果一次部署需要多个服务，部署会变得复杂，系统的吞吐量会变大，但是响应时间会变长。运维复杂度会因为服务变多而变得很复杂，架构复杂导致学习曲线变大，测试和查错的复杂度增大。技术可以很多样，这会带来维护和运维的复杂度，梳理分布式系统中的服务和调度变得困难和复杂。分布式系统架构的难点在于系统设计，以及管理和运维。所以分布式系统架构在解决了一些问题的同时，也增加了其他的问题，这就需要不断的再用各种各样的技术跟手段去解决这些新增的问题。计算高可用方法的关键在于任务分发器的性能。任务分发器可以理解为类似于负载均衡。单点系统可能会由于断电，宕机等情况，使得系统不可用，根据CAP理论，分布式系统只能在CP或AP之间进行选择，无法实现CA。特别强调CAP是忽略网络延迟的，也就是说对于CP来讲，只要不发生网络分区，各节点数据就是一致的。但由于网络天然的不可靠性，延迟是必然存在的，网络延迟不在CAP的讨论范围内。CAP理论是站在数据的角度来考虑的，而不是站在系统的角度。一个系统存在各种各样的数据，如果站在整个系统的角度来决策是选择CP还是AP就会顾此失彼。

发明内容

本发明的目的是针对双机部署的分布式系统，由于网络出现故障带来的系统架构缺陷问题，以提供一种具体高吞吐、高可用、可扩展的航天地面系统分布式软件方法。

本发明的上述目的可以通过下述方法予以实现：一种航天地面系统分布式软件高可用方法，具有如下技术特征：首先，建立分布式内存数据库服务代理，每个代理关联一个实际的内存数据库服务，内存数据库服务代理负责启动、停止、重启、以及仲裁内存数据库的主备；然后，内存数据库服务代理彼此通过心跳交互自身的状态，通过阈值时间是否收到对方代理心跳判断内存数据库服务代理及内存数据库状态，阈值时间收到则判定为彼此的内存数据库服务代理以及内存数据库都存活，否则认为对方或者自的内存数据库服务代理以及内存数据库丢失；在彼此存活的情况下，根据每个内存数据库成为主服务的时间以及彼此对应物理机的ip大小仲裁出主备，在彼此不能判断多方存活，则通过判断自方与三方ip集群的通断状态仲裁出自身主备状态；将三方ip参考机集群指定为本机，在单机的应用场景下，判定出主内存数据库，并将本机切换为主内存数据库；内存数据库以外的其他业务相关服务，利用内存数据库中的分布式锁进行竞争方式仲裁主备；其次，内存数据库服务代理定时获取内存数据库服务连接状态，不能建立连接则认为本机内存数据库服务代理与内存数据库连接存在异常，内存数据库服务代理则自动进行重启内存数据库直到能够正常建立连接为止，如果重启过程能够在心跳阈值时间内完成，则内存数据库维持故障前状态，如果超过心跳阈值时间内存数据库才被重启起来，则重启之后为自动成为备内存数据库。

本发明相比于现有技术具有如下有益效果：

本发明支持分布式系统单机开发环境的搭建。本发明采用建立分布式内存数据库服务代理，每个代理关联一个实际的内存数据库服务，内存数据库服务代理启动、停止、重启、以及仲裁内存数据库的主备；然后，内存数据库服务代理彼此通过心跳交互自身的状态，通过阈值时间是否收到对方代理心跳判断内存数据库服务代理及内存数据库状态，根据每个内存数据库成为主服务的时间以及彼此对应物理机的ip大小，并将三方ip参考机集群指定为本机，这种将三方ip集群(参考机集群)指定为本机就可以搭建起开发环境而进行项目开发。可以避免在传统集群高可用方法需要至少3台机器或者3个选举服务才能够搭建起本地开发环境的不足。航天地面系统分布式软件高吞吐：系统监控分布式软件中可以支持主备服务，也可以支持负载均衡服务。系统监控分布式软件可以根据业务相关的需要，将系统的性能瓶颈或者高流量业务服务采用负载均衡的设计策略进行设计，从而使得系统在关键业务节点的吞吐量能够满足系统监控的应用需求。在本发明中，系统监控业务主备服务则利用内存数据库提供的分布式锁采用竞争的方式完成主备的仲裁，该类型的服务吞吐量由服务内存保证不在本发明内；系统监控业务负载均衡服务则采用轮训、随机的方式进行均衡的任务分配方式以达到高吞吐，系统可以根据业务需求，对负载均衡服务进行动态部署。

本发明利用三方ip参考机集群作为参考仲裁自己是否可以成为主内存数据库服务还是备内存数据库服务，在双机心跳正常情况下，根据各自内存数据库服务成为主的时间以及各自的本机ip大小仲裁出来主内存数据库服务，在双机的分布式系统中相较于传统双机环境的高可用增加代理的交换信息。在双机心跳正常情况下，可以根据各自内存数据库服务成为主的时间以及各自的本机ip大小仲裁出来主内存数据库服务。如果心跳不正常的情况下，则可以根据双机各自与三方ip集群(参考机集群)的通断仲裁出可靠的主内存数据库服务，极端情况下出现双主或双备的时候，系统可以根据增加三方ip集群(参考机集群)的数量、可靠性或者是三方ip集群(参考机集群)为系统的关键设备(如交换机)来进行避免，系统也能够在极端情况恢复的时候根据各自成为主内存数据库服务的时间进行最优的仲裁。分布式系统更加可靠。一个单元或资源(软件或硬件)的故障不影响其他资源的正常功能。

本发明航天地面系统分布式软件可扩展，首先在物理机只有一台的情况下，我们可以将三方ip集群配置为本机或者其他一个可达的网络目标机器，则能够在没有集群其他心跳的情况下，采用发送探测包给三方ip集群的方式仲裁出内存数据库的主备。在多物理机的情况下(大于2台)，本方法则利用2台物理机的方式，即在能够收到系统监控内存数据库代理集群的心跳时，则利用心跳仲裁出内存数据库的主备，在没有心跳的时候，则利用自己与三方ip集群的探测包检测自己是否可以成为主内存数据库。内存数据库以外的系统监控主备业务服务，则可以在内存数据库仲裁出来，利用其分布式锁可以选择出相关业务服务的主备关系，从而使得航天地面系统分布式软件也能够工作。所以在本发明中，我们采用三方ip集群是内存数据库仲裁主备的充分条件，而非必要条件的方式来完成航天地面系统分布式软件的可扩展性。进行扩展性设计，并对分布式系统的横向动态扩容进行适配，兼容系统扩容之后的多机高可用问题，也支持集群分布式系统的高可用扩展，及兼容内存数据库集群部署。在此种情况下，内存数据库的仲裁则是在收不到集群中的心跳时，则利用三方ip集群(参考机集群)作为选举参考。

本发明航天地面系统分布式软件业务运行过程中，面对到网络异常、服务器硬件故障、服务器关机以及操作系统运行故障、业务服务模块自身退出等异常情况的风险，在一台服务器出现故障(不能恢复，或者需要超过阈值的时间恢复)之后，业务软件系统会根据分布式锁的抢占与维持来重新选举出新的主服务。如果故障机器恢复并且进行了重启，首先重启服务默认是备服务，并且分布式锁已经被其他服务抢占，在重启之后不会引入当前主被抢占，或者双主的情况。备服务所在服务器故障并且重新启动，则不会造成主备切换，并且也不会出现抢占当前存在的主服务状态。因此在一台主用机器出现故障之后，备用服务器可以在升为主之后提供正常的服务(切换时间可以配置)。对于故障的一台机器能否恢复都可以保证系统运行。故障机器恢复之后在外部环境稳定的情况下也不会抢占现有系统的各个任务，保证系统的运行状态不会因为机器的动态接入而影响系统的任务稳定性。在运行过程中，出现备机服务器故障的情况则对整个系统监控不会带来任何的影响，并且所有主服务的状态也不会因为临时的外部因素而发生变化

附图说明

图1是本发明航天地面系统分布式软件高可用逻辑结构图；

图2是本发明航天地面系统分布式软件高可用流程图；

图3是本发明航天地面系统分布式软件部署示意图；

图4是本发明航天地面系统分布式软件业务初始运行示意图；

图5是本发明航天地面系统分布式软件内存数据库异常切换示意图；

图6是本发明航天地面系统分布式软件业务异常切换示意图。

下面结合附图和实施例对本发明专利进一步说明。

具体实施方式

参阅图1、图2、图3。根据本发明，首先，建立分布式内存数据库服务代理，每个代理关联一个实际的内存数据库服务，内存数据库服务代理负责启动、停止、重启、以及仲裁内存数据库的主备；然后，内存数据库服务代理彼此通过心跳交互自身的状态，通过阈值时间是否收到对方代理心跳判断内存数据库服务代理及内存数据库状态，阈值时间收到则判定为彼此的内存数据库服务代理以及内存数据库都存活，否则认为对方或者自的内存数据库服务代理以及内存数据库丢失；在彼此存活的情况下，根据每个内存数据库成为主服务的时间以及彼此对应物理机的ip大小仲裁出主备，在彼此不能判断多方存活，则通过判断自方与三方ip集群的通断状态仲裁出自身主备状态；将三方ip参考机集群指定为本机，在单机的应用场景下，判定出主内存数据库，并将本机切换为主内存数据库；内存数据库以外的其他业务相关服务，利用内存数据库中的分布式锁进行竞争方式仲裁主备；其次，内存数据库服务代理定时获取内存数据库服务连接状态，不能建立连接则认为本机内存数据库服务代理与内存数据库连接存在异常，内存数据库服务代理则自动进行重启内存数据库直到能够正常建立连接为止，如果重启过程能够在心跳阈值时间内完成，则内存数据库维持故障前状态，如果超过心跳阈值时间内存数据库才被重启起来，则重启之后为自动成为备内存数据库。

构建的航天地面系统分布式软件包括：根据预先设定的部署配置策略及系统需要，将主从服务分别部署在2台服务器上，根据系统监控业务需要将负载均衡服务按情况和预先设定的部署配置策略，将多个负载均衡服务分别部署在2台服务器上，2台服务器组成分布式软件集群。在每一台服务器上部署一个内存数据库服务与代理服务，组成分布式内存数据库集群以保证系统监控数据的稳定性；数据库服务在每台系统监控服务器各部署一个保证数据库高可用组成数据集的数据库。

主从服务采用竞争分布式锁的方式来决定服务的控制权。分布式锁的构建规则为：同类型主从服务的锁Key相同，不同类型的主备服务的锁不相同，且相同Key的分布式锁在集群中只存在一个，只能够被集群内的一个服务获取并使用。

每个服务根据该Key并带上锁的超时时间申请该锁，并根据申请的状态来决定服务的主备关系。在主服务申请到锁之后，它将采用定时续锁的方式维持自己对分布式锁的持有，备服务则采用定时申请锁的方式进行锁的试申请，当异常发生时开展主备切换，主服务则不能续锁，导致分布式锁过期超时，从而使得对应的备服务申请到分布式锁而升为主。

参阅图3。航天地面系统分布式软件启动运行过程中，分布式软件业务服务初始化时，服务默认为备服务，业务服务模块会通过竞争分布式锁的方式，检测内存数据库是否正常，判断内存数据库主备仲裁是否完成，是则申请分布式锁。如果内存数据库工作正常，业务服务模块申请分布式锁成功则成为主业务服务，如果申请失败则维持初始状态即备服务状态，并定时获取分布式锁。异常情况下，业务服务模块可能先于内存数据库主备关系的仲裁结果而启动，由于业务服务模块采用秒定时的方式进行分布式锁的申请，一旦内存数据库的主备关系仲裁完成，主从业务服务模块即可完成主备关系的仲裁。

参阅图4。航天地面系统分布式软件正常运行，内存数据库代理服务根据阈值时间是否有收到其他内存数据库代理服务的心跳，是则维持内存数据库状态，否则采用ping的方式检测是否与三方ip集群可达，是则切换为主内存数据库或者维持主内存数据库服务状态，否则切换为备内存数据库服务或者维持备内存数据库状态。

三方ip集群的可达是根据发送的探测包响应数量来完成，在三方ip集群中没有系统运行的关键设备时，则与三方ip集群的可靠以ip集群中多数探测包能够响应作为与三方ip集群可达，否则认为与不可达；如果三方集群中存在系统运行的关键设备不可达，则认为与三方ip集群不可达的设备，三方ip集群中的关键设备可达则认为与三方ip集群可达，否则与关键设备以外的其他多数设备可达则认为不可达，即三方ip集群中可以存在系统运行的关键设备，在关键设备存在时候，可以不遵循多数可达的规则，如果不存在关键设备则采用多数可达的规则进行三方ip集群可达性的检测。

参阅图5。航天地面系统分布式软件正常运行，分布式软件业务服务模块判断分布式锁申请或者续约是否成功，是则升为主业务服务或者维持主业务服务状态，切换为主服务，如果判断分布式锁申请不成功或者续约分布式锁失败，则维持备业务服务状态或者将主服务降为备业务服务。

Claims (6)

1.一种航天地面系统分布式软件高可用方法，具有如下技术特征：首先，建立分布式内存数据库服务代理，每个代理关联一个实际的内存数据库服务，内存数据库服务代理负责启动、停止、重启、以及仲裁内存数据库的主备；然后，内存数据库服务代理彼此通过心跳交互自身的状态，通过阈值时间是否收到对方代理心跳判断内存数据库服务代理及内存数据库状态，阈值时间收到则判定为彼此的内存数据库服务代理以及内存数据库都存活，否则认为对方或者自方的内存数据库服务代理以及内存数据库丢失；在彼此存活的情况下，根据每个内存数据库成为主服务的时间以及彼此对应物理机的ip大小仲裁出主备，在彼此不能判断多方存活，则通过判断自方与三方ip集群的通断状态仲裁出自身主备状态；将三方ip参考机集群指定为本机，在单机的应用场景下，判定出主内存数据库，并将本机切换为主内存数据库；内存数据库以外的其他业务相关服务，利用内存数据库中的分布式锁进行竞争方式仲裁主备；其次，内存数据库服务代理定时获取内存数据库服务连接状态，不能建立连接则认为本机内存数据库服务代理与内存数据库连接存在异常，内存数据库服务代理则自动进行重启内存数据库直到能够正常建立连接为止，如果重启过程能够在心跳阈值时间内完成，则内存数据库维持故障前状态，如果超过心跳阈值时间内存数据库才被重启起来，则重启之后为自动成为备内存数据库；

航天地面系统分布式软件包括：根据预先设定的部署配置策略及系统需要，将主从服务分别部署在2台服务器上，根据系统监控业务需要将负载均衡服务按情况和预先设定的部署配置策略，将多个负载均衡服务分别部署在2台服务器上，2台服务器组成分布式软件集群；

航天地面系统分布式软件启动运行过程中，分布式软件业务服务初始化时，服务默认为备服务，业务服务模块会通过竞争分布式锁的方式，检测内存数据库是否正常，判断内存数据库主备仲裁是否完成，是则申请分布式锁；如果内存数据库工作正常，业务服务模块申请分布式锁成功则成为主业务服务，如果申请失败则维持初始状态即备服务状态，并定时获取分布式锁；

航天地面系统分布式软件正常运行，内存数据库代理服务根据阈值时间是否有收到其他内存数据库代理服务的心跳，是则维持内存数据库状态，否则采用发送探测包的方式检测是否与三方ip集群可达，是则切换为主内存数据库或者维持主内存数据库服务状态，否则切换为备内存数据库服务或者维持备内存数据库状态；

三方ip集群的可达是根据发送的探测包响应数量来完成，在三方ip集群中没有系统运行的关键设备时，则与三方ip集群的可靠以ip集群中多数探测包能够响应作为与三方ip集群可达，否则认为与不可达；如果三方集群中存在系统运行的关键设备不可达，则认为与三方ip集群不可达，三方ip集群中的关键设备可达则认为与三方ip集群可达，否则与关键设备以外的其他多数设备可达则认为不可达，即三方ip集群中存在系统运行的关键设备，在关键设备存在时候，可以不遵循多数可达的规则，如果不存在关键设备则采用多数可达的规则进行三方ip集群可达性的检测。

2.如权利要求1所述的航天地面系统分布式软件高可用方法，其特征在于：在每一台服务器上部署一个内存数据库服务与代理服务，组成分布式内存数据库集群以保证系统监控数据的稳定性；数据库服务在每台系统监控服务器各部署一个保证数据库高可用组成数据集的数据库。

3.如权利要求2所述的航天地面系统分布式软件高可用方法，其特征在于：主从服务采用竞争分布式锁的方式来决定服务的控制权，分布式锁的构建规则为：同类型主从服务的锁Key相同，不同类型的主备服务的锁不相同，且相同Key的分布式锁在集群中只存在一个，只能够被集群内的一个服务获取并使用。

4.如权利要求3所述的航天地面系统分布式软件高可用方法，其特征在于：每个服务根据该Key并带上锁的超时时间申请该锁，并根据申请的状态来决定服务的主备关系；在主服务申请到锁之后，它将采用定时续锁的方式维持自己对分布式锁的持有，备服务则采用定时申请锁的方式进行锁的试申请，当异常发生时开展主备切换，主服务则不能续锁，导致分布式锁过期超时，从而使得对应的备服务申请到分布式锁而升为主。

5.如权利要求1所述的航天地面系统分布式软件高可用方法，其特征在于：异常情况下，业务服务模块先于内存数据库主备关系的仲裁结果而启动，业务服务模块采用秒定时的方式进行分布式锁的申请，一旦内存数据库的主备关系仲裁完成，主从业务服务模块完成主备关系的仲裁。

6.如权利要求1所述的航天地面系统分布式软件高可用方法，其特征在于：航天地面系统分布式软件正常运行，分布式软件业务服务模块判断分布式锁申请或者续约是否成功，是则升为主业务服务或者维持主业务服务状态，如果判断分布式锁申请不成功或者续约分布式锁失败，则维持备业务服务状态或者将主服务降为备业务服务。

Images