一种基于混合通信的分布式冗余实时数据库框架的制作方法
【专利摘要】本发明公开一种基于混合通信的分布式冗余实时数据库框架，该框架针对轨道交通监控系统中，数据规模庞大，监控数据存在内在语义关联，工作站以实时数据查询为主等特征，在冗余实时库的分布、同步和故障容错等各方面分别采用了各种适合的策略，通过混合使用单播通信和组播通信分别实时传输不同性质的数据，解决由于规模扩张带来的同步通讯数据量迅速增长等问题，通过采用合理的策略满足了监控数据内在语义关联对实时库同步的时序一致性要求，有效实现了分布式多冗余实时库框架下的故障容错，更有效的实现了监控系统中分布式实时库的多冗余，相比于常规的双冗余框架更有力的保障了实时库的可靠性和可用性，为轨道交通监控系统的稳定运行奠定基础。
【专利说明】一种基于混合通信的分布式冗余实时数据库框架
【技术领域】
[0001]本技术发明涉及轨道交通自动化领域，尤其涉及分布式监控系统领域，本技术发明可广泛适用于电气化铁路和城市轨道交通各专业监控系统以及综合监控系统等应用。
【背景技术】
[0002]随着计算机科学和自动化技术的迅速发展，在轨道交通的各个领域，例如电气化铁路和城市轨道交通等领域，监控系统已经从传统的小型桌面系统向现代的分布式复杂系统发展，其控制的地域范围，流程规模等都迅速增加。而且由于传统采用的分立监控系统模式，即存在信号、PSCADA (电力监控)、BAS (环控)等多个独立的监控系统并各有专员进行操作，具有运营成本高，多个系统的信息难以共享等问题，集各子系统功能于一身的综合监控系统逐渐成为新的发展趋势。在综合监控系统中，各个子系统通过集成或互联，实现由同一个上位系统进行监控，从而使得信息可以有效共享，并且减少工作量，降低运营成本。
[0003]分布式冗余实时数据库:无论是分立监控系统还是综合监控系统，实时数据库都是监控系统的数据核心，实时数据库，常又简称为实时库，其中存放了轨道交通运营现场的各种实时数据。监控系统通过采集或者I/o模块从设备或者子系统获得最新的现场状态数据并实时更新实时库中的相关数据(人机界面)模块从实时库获取实时数据，以人性化的方式展现给操作员；告警模块依据实时库中实时状态数据触发相应的报警；趋势模块定时从实时库获取最新数据并以曲线形式呈现；而操作员根据各种实际情况，通过实时库及时的发出指令，进行实时控制。实时库作为监控系统的实时数据中枢实现实时数据的统一管理并为系统的其它模块提供一致的实时数据访问服务，从而使得监控系统作为一个有机整体持续稳定的可靠运行，正确实现轨道交通运营的监控功能。
[0004]由于各种轨道交通应用，无论是电气化铁路还是地铁或者轻轨，都涉及大规模人身安全，因此监控系统具有严格的可靠性要求，而作为系统实时数据核心的实时库，是整个系统赖以可靠运行的基础，其可靠性无疑是重中之重。冗余是保障可靠性的有效技术。因此，轨道交通的监控系统通常在各方面采用冗余技术，从而尽可能的保障系统的可靠性和可用性。例如，常规配置中，在监控系统的局域网内，不会只运行一台服务器，而是同时运行两台互为备用的冗余服务器，并配置若干台工作站，通过合理的通信实现冗余，如图1所示。同样，冗余也是保障实时库可靠性的有效技术。常规配置中，在局域网内的双冗余服务器上会同时运行相同的实时库，确保当一台服务器上的实时库因为服务器宕机等原因失效时，另一台服务器上的实时库仍然可以为系统提供正常的实时数据访问服务，从而实现实时库的双冗余，以保障实时库的可靠性和可用性。这就意味着监控系统中的实时库采用的是分布式冗余框架。由于实时库中存放了实时数据的最新状态，并用于提供实时数据访问服务，因此，分布式冗余框架中的所有实时库必须通过合理的实时通信保持数据实时一致，这样才能保证从任一实时库访问的实时数据数值都是实时一致的，这称为同步，反之称为失步。
[0005]近来，轨道交通行业的一些重大事故，如温州动车追尾事故，以及一些严重影响轨道交通运营的大型灾害，如汶川地震等，使得人们对轨道交通应用的安全可靠更为关注，因而对轨道交通监控系统的可靠性和可用性也提出了更高的要求。这使得监控系统在一些更为关键、需要更可靠的场合采用了比常规双冗余具有更高可靠性的多冗余框架。例如在武汉等高铁中枢的调度指挥中心，监控系统往往配置多台互为备用的服务器，如图2所示，从而确保在超过一台服务器发生故障时系统仍然可以正确运行；而在很多城市，特别是地处灾害易发地区如地震带的城市，地铁监控系统除了在运营控制中心配置了双冗余服务器和若干台工作站，同时在一定距离外建有灾备中心，并提供相同的配置，如图3所示。平时通过通信维持数据一致，一旦运营控制中心因发生大型灾害而无法使用，则转移至灾备中心维持监控功能。在多冗余的配置中，系统中存在一台主服务器和多台备用的服务器，在每台服务器同时运行相同的实时库，并通过合理的实时通信保持实时同步。从而保障即使有多台服务器上的实时库因为服务器宕机等故障而失效，只要还有至少一台服务器上的实时库是有效的，就可以为系统提供实时数据访问服务，从而更大限度的实现实时库的故障容错，更有力的保障监控系统的可靠性。
【发明内容】
[0006]针对现有技术中所存在的问题，本发明提出一种适用于轨道交通监控系统的分布式冗余实时库框架，该框架针对轨道交通监控系统中，数据规模庞大，监控数据存在内在语义关联，工作站以实时数据查询为主等特征，在冗余实时库的分布、同步和故障容错等各方面分别采用了各种适合的策略，通过混合使用单播通信和组播通信分别实时传输不同性质的数据，解决由于规模扩张带来的同步通讯数据量迅速增长等问题，通过采用合理的策略满足了监控数据内在语义关联对实时库同步的要求，并以适合的方式有效实现了多冗余分布式实时库框架下的故障容错，从而更有效的实现了监控系统中实时库的多冗余，相比于常规的双冗余更有力的保障了实时库的可靠性和可用性，为系统稳定、可靠的持续运行提供了更为坚实的基础。
[0007]本发明的技术方案为:一种基于混合通信的分布式冗余实时数据库框架，包括:实时数据访问模块；分布式多冗余实时库框架；冗余实时库同步模块；分布式多冗余实时库的故障容错模块。
[0008]所述实时数据访问模块:在监控系统中，实时库中保存了轨道交通运营现场的状态信息的最新数据，并且不断实时更新以保证及时反映现场的当前状况，从而作为实时数据中枢为系统的其它模块提供实时数据访问服务；实时数据访问分为查询访问和更新访问；所述查询访问是指时库中获取实时数据的最新数值，以满足应用需求，查询访问不会改变实时库中实时数据的数值；更新访问是指依据应用需求，更新实时库中实时数据的数值，更新访问会改变实时库中的实时数据的数值。
[0009]所述分布式多冗余实时库模块:为了保障监控系统中实时库的可靠性，通常在所有冗余的服务器上同时运行相同的实时库，以实现实时库的冗余；工作站则可分为两种方式:一种是工作站上不运行实时库，而所有的实时数据访问，都通过通信由服务器上的实时库提供远程实时数据访问服务；另一种则是在工作站上运行本地实时库。文中的分布式冗余实时库框架采用了第二种方式，即在工作站上运行实时库，这样可以直接对这些查询访问提供本地服务，而不需要籍由通信提供远程服务。这一方面避免了由此带来的繁重网络通信负载，更重要的是，由于完全没有通信时延，本地提供查询访问服务的实时性能要明显优于远程服务，从而可以更为及时、流畅的向操作员显示现场的当前状况。
[0010]所述冗余实时库同步模块:监控系统中的实时库在内存中保存了所有运营现场的当前状态的实时数据，分布式冗余框架中的所有实时库必须始终维持实时同步。这里主要考虑当更新访问修改了实时库中的数据时，冗余框架中原来同步的分布式实时库如何维持同步，包括主实时库的更新访问、备实时库的更新访问和冗余实时库的工作流程。
[0011]所述分布式多冗余实时库的故障容错模块:采用多冗余的方式将比双冗余能够更有力的保障实时库的可靠性，保证了即使框架中超过一台服务器的实时库失效，只要还有不少于一台的服务器上的实时库正常运行，就仍然能够为系统提供实时数据访问服务，从而比双冗余实时库框架更有效地实现实时库的故障容错，具备更高的可靠性。
【专利附图】
【附图说明】
[0012]图1为现有技术中的双冗余服务器配置示意图。
[0013]图2为现有技术中的多冗余服务器配置示意图。
[0014]图3为现有技术中具有灾备中心的多冗余服务器配置示意图。
[0015]图4为本发明的分布式多冗余实时库框架示意图。
[0016]图5为本发明主实时库的更新访问请求的同步策略示意图。
[0017]图6为本发明备实时库的更新访问请求的同步策略示意图。
[0018]图7为本发明备实时库运行流程示意图。
【具体实施方式】
[0019]以下结合相关附图和具体实施例对本发明作进一步的详细阐述。
[0020]I)实时数据访问模块:监控系统中对实时库的实时数据访问总体可以分为两类:一类是查询访问单元，从实时库中获取实时数据的最新数值，以满足应用需求，例如=HMI模块从实时库中查询最新数据，并动态显示给操作员；告警模块从实时库中查询当前的数据，如异常则报警；趋势模块从实时库中周期性查询数据，并以曲线形式呈现。另一类是更新访问单元，依据应用需求，更新实时库中实时数据的数值，例如:采集或者I/O模块从设备或者子系统获得运营现场的最新状态数据后会对实时库中的相关数据进行实时更新，并同时更新其获得时间，而操作员做出的控制指示，常常也首先写入实时库，并经由实时库知会控制模块执行。
[0021]2)分布式多冗余实时库模块:为了保障监控系统中实时库的可靠性，通常在所有冗余的服务器上同时运行相同的实时库，以实现实时库的冗余。工作站则可分为两种方式，一种是工作站上不运行实时库，而所有的实时数据访问，都通过通信由服务器上的实时库提供远程实时数据访问服务；另一种则是在工作站上运行本地实时库。由于工作站主要用于提供界面和操作员交互，因此如HMI模块、告警界面模块、趋势模块等都需要频繁的访问实时库获得最新状态数值并刷新界面以将运营现场的状况实时展现给操作员，这些主要都依靠查询访问，只有在必要情况下，操作员做出适当的控制操作时，会涉及更新访问，可见，工作站的实时数据访问中，绝大多数为查询访问，因而本实施例中的分布式冗余实时库框架采用了第二种方式，即在工作站上运行实时库，这样可以直接对这些查询访问提供本地服务，而不需要籍由通信提供远程服务，这一方面避免了由此带来的繁重网络通信负载，更重要的是，由于完全没有通信时延，本地提供查询访问服务的实时性能要明显优于远程服务，从而可以更为及时、流畅的向操作员显示现场的当前状况。当然，为了实现这一点，必须采用适合的策略使得工作站的实时库也和服务器的实时库保持实时同步，并使用合理的通信方式避免由于工作站实时库的同步通信导致的同步通信数据量剧增的问题。
[0022]如图4所示，图4为分布式多冗余实时库模块的示意图。在本实施例的分布式多冗余实时库模块中，主服务器、所有的备服务器和工作站上均运行实时库，并且通过适合的实时通信方式保持实时同步，为了便于描述，分别将主、备服务器和工作站上的实时库称为主实时库、备实时库 和客户实时库，依次用Ra，Rs和R。表示；每一台服务器上的实时库具有自己唯一的优先级，用Pt，t=l, 2，3，…表示，t为服务器上的实时库的编号；其中，虚线表示组播通信，在所有的实时库，包括主实时库、全部的备实时库以及全部的客户实时库之间建立组播通信连接以实现组播通信，有所区别的是，主实时库和各备实时库既通过组播连接发送数据，也从组播连接接收数据，而所有的客户实时库仅从组播连接接收数据，不向组播连接发送数据；实线表示单播通信，所有的备实时库以及所有的客户实时库均分别和主实时库建立独立的单播通信连接，以实现各自的单播通信。
[0023]3)冗余实时库同步模块:监控系统中的实时库在内存中保存了所有运营现场的当前状态的实时数据，这里将其称为实时库的当前状态，用Si, i=l, 2，3，…表示，分布式冗余框架中的所有实时库必须始终维持实时同步，由于查询访问不修改实时库中的实时数据，因此不会导致实时库状态变更，仅在本地实时库执行就可以完成。这里主要考虑当更新访问修改了实时库中的数据时，冗余框架中原来同步的分布式实时库如何维持同步。
[0024]主实时库的更新访问:如图5所示，图5为主实时库的更新访问请求的同步策略示意图。假设冗余框架中所有实时库中实时数据均为运营现场的最新状态数据，实时库已经实现同步，状态均为Si,然后主服务器上的数据采集模块获得了新的状态数据，并提请更新访问请求D，以更新实时库中的相关数据到最新，为了维持分布式冗余框架中的所有实时库同步，这里采用这样一种策略，首先由主实时库执行更新访问请求D，将自身的相关数据更新，从而主实时库的状态从Si变更为Si+1 ;然后将同步信息Mi = < Ra, Pt, i+1, Di >通过通信分发给所有的备实时库和客户实时库，其中Ra表示角色为主实时库，Pt为当前主实时库的优先级，i+1为主实时库最新状态编号，Di为更新访问请求，备实时库和客户实时库在接收到同步信息后，通过执行更新访问请求Di也从状态Si变更到Si+1，从而维持和主实时库同步。所有的服务器上的实时库，即主实时库和所有备实时库，保存最后执行的k个更新请求，即Di_k至Dp
[0025]同步通信是分布式冗余框架中的实时库之间的主要通信。由于轨道交通应用地域分布广泛，监控系统的实时库数据量较大，特别是综合监控系统集成和互联了诸多专业，其实时库的数据量更是远超分立监控系统，相应的，轨道交通监控系统的实时库的同步通信涉及的通信数据量较大；由于分布式多冗余实时库框架中存在多个备实时库，并且所有的工作站上都存在客户实时库，如果采用单播通信，那么每一个备实时库和客户实时库都需要一份同步通信数据，这会导致同步通信数据随分布式冗余框架中的实时库规模增加而迅速增长，从而很容易耗尽通信带宽，严重延误自身以及其它通信中重要数据的传输，这就使得通信带宽成为实时库规模扩展的严重约束；由于同步通信中发送给备实时库和客户实时库的其实是同样的数据，因此，为了避免同步通信数据的剧增问题，这里使用组播通信替代单播通信，即主实时库使用组播通信同时向所有的备实时库和客户实时库发送同步信息；由于组播的通信量不会随着数据接收方数量的增加而迅速增长，从而避免了通信带宽对框架中实时库数量的约束，实时库数量可以依据应用的需求自如的增加，具有了良好的可扩展性；由于主实时库通过组播通信同时向所有的备实时库和客户实时库发送同步信息，因此，如果一个备实时库或者客户实时库未能成功接收或者正确处理同步信息，就不可以要求主实时库再次通过组播通信发送该同步信息，以免其它的实时库重复接收和处理，为此该实时库将单独通过单播通信以信息编号为标记从主实时库重新获取保存的同步通信信息并处理，从而维持和主实时库的同步。
[0026]备实时库的更新访问:如图6所示，图6为备实时库的更新访问请求的同步策略示意图。在一台备服务器上的更新访问请求是否可以采用和主服务器类似的模式，先由本地实时库，即对应的备实时库执行，然后分发给主实时库，其它备实时库以及所有的客户实时库执行以维持同步呢？这在轨道交通的监控系统中是不可以的。因为这样做可能造成冗余框架内各实时库中数据的更新顺序不一致，而监控系统中的数据存在内在语义关联，因此这是不允许的。举一个轨道交通应用中供电专业的示意性的例子，供电装置的电流突变数据在主服务器产生一个更新访问请求，而对应的保护装置的跳闸信号在差不多的时刻在一台备服务器产生一个更新访问请求，如果对应的主、备实时库都采取先本地执行而后分发的策略，那么由于通信时延的存在，两个更新请求在本地实时库执行完成后分发到对方执行时，对方更新请求的本地执行已经在此之前完成。因此，虽然最终这两个实时库中数据状态是一致的，但是主实时库反映的信息是电流突变导致之后的跳闸，而那个备实时库反映的情况正好相反，是跳闸后出现电流突变。由于通信的复杂性，其它备实时库和客户实时库中可能是两种情况中的任意一种。这两种情况对于监控系统的操作员而言是不同类型的故障，需要采用不同的应对措施，而责任认定也是不一样的。因此，这在轨道交通应用的监控系统中是不能接受的。为了避免这种问题，这里对于备实时库的更新访问请求采用了这样一种同步策略。被访问的备实时库将得到的更新访问请求通过单播通信转发给主实时库执行，然后执行结果也通过单播通信返回。该备实时库其实是充当了一个“二传手”的角色将请求传递给了主实时库，本身并没有本地执行，直到主实时库执行后将同步信息通过组播通信分发给所有备实时库和客户实时库时，该备实时库才执行以维持同步。这就迫使所有的更新访问请求必须首先在主实时库顺序执行而后依次分发，从而确保冗余框架中的所有实时库内的数据的更新顺序是完全一致的。
[0027]这样做不会显著增加监控系统的通信压力，这是因为主实时库向备实时库分发同步信息的通信量主要在主实时库到备实时库的方向上，而备实时库向主实时库传递更新访问请求的通信量基本集中在相反方向上，由于监控系统中的通信通道一般是全双工的，因此这样并不会造成明显的通信压力增加。这种同步策略的一个优点是备实时库通过通信透明传递了更新访问请求，从而使得备服务器上的实时数据访问就像在主服务器上一样完成，因而可以将访问实时库的模块相对均匀的分布于主服务器和多个备服务器运行。对于轨道交通监控系统这种功能复杂的大规模系统，这样可以有效的均衡负载，例如数据采集模块在主服务器运行；数据维护模块在一台备服务器运行以确保充足的CPU等计算资源；而告警模块和联动模块在另一台备服务器运行，从而在出现紧急状况时不会因为资源受限而影响及时应对。
[0028]客户实时库的更新访问请求的处理策略和备实时库一致。。
[0029]冗余实时库的工作流程:如图7所示，图7为备实时库运行流程示意图。实时库持续提供实时数据访问服务是轨道交通应用的监控系统稳定可靠运行的基础，为了实现多台服务器上实时库的冗余，每一台服务器上的实时库开始运行时首先建立组播连接，通过监听组播通信检测是否已经有主实时库在运行，如果没有则自身作为主实时库运行，如果已经存在，无论其优先级是否高于自身，自己都作为备实时库运行，这是为了维持分布式冗余框架中实时库间已建立的同步通信的稳定。服务器上的实时库作为备实时库运行时，首先建立和主实时库的单播连接，并通过单播通信获取主实时库的所有状态数据从而实现和主实时库的同步，然后在持续执行主实时库分发的同步信息以维持同步的同时，为本地的各种实时数据访问提供服务。如前所述，查询访问在本地执行，而更新访问透明传递给主实时库。
[0030]需要注意的是，备实时库虽然也和主实时库一样保存最后的k个更新访问请求，但是在执行完每一个更新访问请求后并不会通过组播通信分发，以免其它实时库重复接收和执行。正常运行时，主实时库和所有的备实时库都会周期性通过组播通信分发状态信息M' =R，Pt，i+l，D'，给其它实时库，其中R表示角色，主实时库的状态信息中为Ra，表示角色为主实时库，备实时库的状态信息中为Rs，表示角色为备实时库，t为该实时库编号，Pt为该实时库的优先级，i+1为该实时库最新状态编号，D’为状态信息，从而通知分布式冗余框架中的其它实时库，该实时库依然正常运行。客户实时库的流程与备实时库类似，但需要注意的是，客户实时库仅从组播连接接收数据，而不通过组播连接发送任何数据，既不分发同步信息，也不分发状态信息，而且客户实时库也不保存任何更新请求。
[0031]4)分布式多冗余实时库的故障容错模块:分布式冗余实时库的故障容错模块是轨道交通监控系统冗余体系的关键之一，作为监控系统的实时数据中枢的实时库一旦不能提供实时数据访问服务，整个系统将陷入瘫痪。而采用多冗余的方式将比双冗余能够更有力的保障实时库的可靠性，在分布式多冗余实时库框架中，主服务器和所有备服务器上同时运行各自的主、备实时库并保持实时同步，当主实时库失效后，多个备实时库中的一个转换作为主实时库替代原先的主实时库运行,其余备实时库保持和新的主实时库同步；如果一段时间后，新的主实时库又因为故障等原因失效，则再由其它正常运行的备实时库中的一台替代作为主实时库运行，备实时库和最新的主实时库同步。这样就保证了即使框架中超过一台服务器的实时库失效，只要还有不少于一台的服务器上的实时库正常运行，就仍然能够为系统提供实时数据访问服务，从而比双冗余实时库框架更有效地实现实时库的故障容错，具备更高的可靠性。由于在冗余框架中，客户实时库保持与主实时库同步，备实时库失效对冗余框架的影响不大，这里主要讨论主实时库的故障容错。
[0032]当分布式冗余框架中的主实时库失效后，多个备实时库中的一个将迅速接管，作为主实时库继续提供实时数据服务，而其余的备实时库和所有的客户实时库要实现并维持和新主实时库的同步。由于轨道交通监控系统中通信体系的结构复杂，故障多样，因此，当原主实时库失效时，其最后的同步信息，可能已经分发给了所有的备实时库和客户实时库，也可能只分发给了其中的一部分，或者根本没来及分发，所以当一台备实时库作为新主实时库运行后，其余的备实时库以及客户实时库与新主实时库可能是同步的，也可能是失步的，为了保证同步，其余的备实时库和所有的客户实时库必须通过单播通信获取新主实时库的所有状态数据重新实现同步，然而，这样做的一个问题是，由于轨道交通监控系统的实时库的数据量很大，获取实时库中全部状态数据会导致很大的通信负载，而故障容错过程中的同一时间段内所有备实时库和客户实时库同时通过单播通信获取全部状态数据将对监控系统的通信网络带来极为繁重的网络负载冲击，从而严重延误自身及其它通信中重要数据的传输，甚至造成通信阻塞。 [0033]为了避免这一状况，这里采用了这样一种策略，正常运行时，分布式冗余实时库框架中的主、备实时库会通过组播通信分发状态信息，从而可以确定框架中当前正常运行的主、备实时库及其对应的角色和优先级。如果主实时库由于主服务器宕机等原因失效，那么分布式冗余框架中优先级最高的备实时库将升格为主实时库，但在角色变更前，该实时库通过组播通信向框架中的其它所有实时库分发保存的最后k个更新请求，即将同步信息Mj=< Rs, Pt, j+1, Dj >，其中j = i' -k-1, -k,..., _1通过组播通信分发给其它备实时库和所有客户实时库，其中i’为该备实时库转换为主实时库之前的最终状态编号，即作为主实时库运行的初始状态编号；RS表示角色即将由备实时库转为主实时库；Pt为该备实时库的优先级％为同步信息中的更新访问请求；j+l为执行这一访问请求后该备实时库的状态编号；在发送完保存的更新请求后，该备实时库将转换为主实时库从编号为i’的状态开始运行，其它备实时库和所有的客户实时库从组播通信接收到这些同步信息后，将原主实时库失效后的自身状态编号与之进行比较，以其它备实时库和所有客户实时库的其中之一为例，例如该实时库最终状态的编号为i”，通常有P _k≤i' ' Si'。此时，通过组播接收到编号为i’ -k-ι到i”-l的同步通信报文中包含的是该实时库已从原主实时库获得并执行过的更新请求，直接丢弃。编号为i”到i’ -1的同步通信报文中包含的是该实时库在原主实时库失效时丢失的更新请求，通过依次执行这些更新访问请求使得该实时库的状态逐渐更新至编号i’，从而使得该实时库和新主实时库最初的运行状态同步，然后该实时库和新主实时库建立单播通信连接，基于混合通信维持和新主实时库的同步。
[0034]如果不满足i' _k≤i'，Si'，说明该实时库由于恰好在故障前的较长时间段内通信失效等特殊原因而无法通过这种方式和新主实时库实现同步，此时只能在和新主实时库建立单播连接之后，通过单播通信从新主实时库获取全部状态数据，重新实现同步，然后基于混合通信维持同步，不过这种情况很少发生。这样，最终原优先级最高的备实时库作为新主实时库运行，而其余的备实时库和所有的客户实时库和新主实时库新建独立的单播连接，依据上述的过程实现并维持和新主实时库同步，实现故障容错。采用这一策略，尽可能避免了其它备实时库和所有客户实时库在没有必要的情况下也通过获取全部状态数据来重新实现和新主实时库同步而产生的繁重通信负载和巨大时间开销，从而尽可能降低该过程中，大量实时库同时获取全部状态数据对监控系统的通信网络带来的短时繁重网络负载冲击，有效的实现了多冗余实时库的故障容错，充分的保障了分布式冗余框架中实时库的可靠性和可用性。
[0035]以上实施例只是对于本发明的部分功能进行描述，但实施例和附图并不是用来限定本发明的。在不脱离本发明之精神和范围内，所做的任何等效变化或润饰，同样属于本发明之保护范围，因此本发明的保护范围应当以本申请的权利要求所界定的内容为标准。
【权利要求】
1.一种基于混合通信的分布式冗余实时数据库框架，其特征在于，包括:实时数据访问模块；分布式多冗余实时库模块；冗余实时库同步模块；分布式多冗余实时库的故障容错模块。
2.根据权利要求1所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述实时数据访问模块分为查询访问单元和更新访问单元；所述查询访问单元是指从实时库中获取实时数据的最新数值，以满足应用需求，查询访问不会改变实时库中实时数据的数值；所述更新访问单元是指依据应用需求，更新实时库中实时数据的数值，更新访问会改变实时库中的实时数据的数值。
3.根据权利要求1所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述分布式多冗余实时库模块是指为了保障监控系统中实时库的可靠性，在所有冗余的服务器上同时运行相同的实时库，以实现实时库的冗余。
4.根据权利要求3所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述分布式多冗余实时库模块中，主服务器、所有的备服务器和工作站上均运行实时库，在所有的实时库，包括主实时库、全部的备实时库以及全部的客户实时库之间建立组播通信连接以实现组播通信，所有的备实时库以及所有的客户实时库均分别和主实时库建立独立的单播通信连接，以实现各自的单播通信。
5.根据权利要求1所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述冗余实时库同步模块是指分布式冗余框架中的所有实时库必须始终维持实时同步。
6.根据权利要求5所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述冗余实时库同步模块中，主实时库使用组播通信同时向所有的备实时库和客户实时库发送同步信息。
7.根据权利要求6所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述冗余实时库同步模块中，被访问的备实时库和客户实时库将得到的更新访问请求通过单播通信转发给主实时库执行，然后执行结果也通过单播通信返回。
8.根据权利要求1所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述分布式多冗余实时库的故障容错模块是指即使框架中超过一台服务器的实时库失效，只要还有不少于一台的服务器上的实时库正常运行，就仍然能够为系统提供实时数据访问服务，从而比双冗余实时库框架更有效地实现实时库的故障容错，具备更高的可靠性。
9.根据权利要求8所述的基于混合通信的分布式冗余实时数据库框架，其特征在于:所述分布式多冗余实时库的故障容错模块中，正常运行时，主实时库、备实时库会通过组播通信分发状态信息，从而确定框架中当前正常运行的主实时库、备实时库及其对应的角色和优先级；如果主实时库由于主服务器宕机原因失效，角色变更前，该主实时库将同步信息通过组播通信向框架中的其它所有实时库和所有客户实时库分发保存的更新请求，优先级最闻的备实时库将升格为主实时库，从而使得该主实时库和新主实时库最初的运行状态同步，然后该主实时库和新主实时库建立单播通信连接，基于混合通信维持和新主实时库的同步，其余的备实时库和所有的客户实时库和新主实时库新建独立的单播连接，实现并维持和新主实时库同步，实现故障容错。
【文档编号】G06F17/30GK103559104SQ201310549119
【公开日】2014年2月5日 申请日期:2013年11月7日 优先权日:2013年11月7日
【发明者】戴宏斌, 经玉健, 吴小俊 申请人:南京国电南自轨道交通工程有限公司