全局信息获取、处理及更新、方法、装置和系统与流程

本申请涉及互联网技术领域，特别是涉及一种全局信息获取方法和装置，一种全局信息处理方法和装置，及一种全局信息更新方法、装置和系统。

背景技术：

随着电子商务全球化的快速发展，跨区域电子商务交易越来越普及和频繁。

电子商务大规模跨区域分布式场景下部署的业务往往会面临全局信息更新需求，并且在保持服务连续条件下，要求更新过程高效且数据信息保持全局一致。例如虚拟专用网络(virtualprivatecloud，vpc)业务中ip地址translation配置数据，或者是像ebay、amazon等国际化电子商务平台的全局信息。

具体以路由表而言，在进行电子商务交易的过程中，涉及到用户对互联网数据中心(internetdatacenter,idc)的数据操作，为了快速响应用户的数据操作请求和保证全局数据一致性，像阿里巴巴、amazon和ebay这类国际化电商平台通常会在多个区域分布设置若干互联网数据中心，然后根据用户所在地点分配就近的互联网数据中心，并将用户所归属的互联网数据中心记录在路由表中，基于该路由表服务用户的数据操作请求，从而可以高效地服务各个区域范围内的用户，又能保证同一用户的全部数据操作仅针对同一个互联网数据中心。

实际生活中，用户可能会跨区域进行数据操作，如用户到其他城市出差，或移民至另外一个国家，为了快速响应用户的数据操作请求和保证全局数据一致性，需要重新分配用户归属的互联网数据中心并更新路由表。

目前路由表的更新方式中，是由电商平台的管控系统(managementcontrolsystem,mcs)将更新的新版本路由表推送至各区域的应用服务器，应用服务器接收到新版本路由表后相应返回更新确认通知至管控系统，同时暂停服务用户的数据操作请求，管控系统确认各区域的全部应用服务器收到 新版本路由表后，发送新版本路由表启用指令至应用服务器，应用服务器收到启用指令后恢复正常的服务，从而使得各个区域的应用服务器使用统一的路由表服务用户，保证了全局数据的一致性。

然而，在大规模跨区域的路由表更新场景中，应用服务器获取一个完整的、数据量较大的新版本路由表所耗费的时间较长，由于管控系统至各区域的应用服务器的网络链路、物理距离等诸多条件的差异较大，可能存在部分区域的应用服务器已经接收到新版本路由表，部分区域的应用服务器仍然处于接收中的情况，需要较长的时间才能使得全局的多个应用服务器完成路由表的更新，而为了保证路由表的全局一致性，在数据更新的整个过程中，全局的应用服务器均无法服务用户。此外，其他的全局信息在大规模跨区域的更新场景中，也会存在同样的更新效率低、长时间无法服务用户的问题。

因此，目前的全局信息更新方法更新效率较低，导致了全局系统服务在更新过程中较长时间不可用的问题。

技术实现要素：

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种全局信息获取方法和装置，一种全局信息处理方法和装置，以及一种全局信息更新方法、装置和系统。

为了解决上述问题，本申请公开了一种全局信息获取方法，所述方法包括：

从全局信息服务器获取全局信息的当前版本信息；

根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器；

根据更新后的版本信息从所述全局信息服务器获取对应的全局信息。

可选地，所述版本信息包括过渡版本信息，所述根据更新后的版本信息从所述全局信息服务器获取对应的全局信息的步骤包括：

根据更新后的过渡版本信息从所述全局信息服务器获取对应的全局信息；

在所述根据更新后的版本信息从所述全局信息服务器获取对应的全局 信息的步骤之后，所述方法还包括：

判断获取到的全局信息是否携带停写标识，若是，则暂停提供针对所述全局信息的服务。

可选地，所述方法还包括：

根据所述应用服务器与所述全局信息服务器的通讯状态更新历史版本信息的有效期。

可选地，所述根据与所述全局信息服务器的通讯状态更新当前版本信息的有效期的步骤包括：

定期向所述全局信息服务器发送第一通讯状态确认信息；

当在预设时间段内收到所述全局信息服务器返回的第二通讯状态确认信息，则重置所述当前版本信息的有效期；

当在预设时间段内没有收到所述全局信息服务器返回的第二通讯状态确认信息，则判定所述当前版本信息失效，并暂停提供针对所述全局信息的服务。

可选地，所述全局信息服务器部署在所述应用服务器所属的区域；

所述全局信息服务器包括保存有所述全局信息的全局信息缓存服务器和保存有所述版本信息的版本信息管理服务器。

可选地，在所述从全局信息服务器获取全局信息的当前版本信息的步骤之前，所述方法还包括：

订阅所述全局信息服务器中全局信息的版本信息；

所述从全局信息服务器获取全局信息的当前版本信息的步骤包括：

当接收到所述全局信息服务器发送的版本信息更新通知时，从所述全局信息服务器下载所述全局信息的当前版本信息。

为了解决上述问题，本申请还公开了一种全局信息处理方法，所述方法包括：

从全局信息更新管控设备获取全局信息以及对应的版本信息，并将所述版本信息发送至所述应用服务器；

收集所述应用服务器返回的更新确认通知；

接收所述应用服务器提交的全局信息获取请求；

在所述全局信息获取请求携带的版本信息对应的全局信息中，查找所述应用服务器请求的全局信息并返回至所述应用服务器。

为了解决上述问题，本申请还公开了一种全局信息更新方法，所述方法包括：

将全局信息及对应的版本信息发送至全局信息服务器；

通过所述全局信息服务器收集所述应用服务器在获取所述版本信息后返回的更新确认通知；

当收集到全部应用服务器返回的更新确认通知时，标记当前的全部应用服务器的版本信息更新完毕。

可选地，在将全局信息及对应的版本信息发送至全局信息服务器之前还包括：

针对全局信息中有更新的全局信息添加停写标识并生成过渡全局信息及对应的过渡版本信息；

所述将全局信息及对应的版本信息发送至全局信息服务器的步骤包括：

将所述过渡全局信息及所述过渡版本信息发送至所述全局信息服务器。

可选地，所述将全局信息及对应的版本信息发送至全局信息服务器的步骤包括：

将所述全局信息和所述版本信息对应发送至所述全局信息服务器的全局信息缓存系统和版本信息管理系统。

为了解决上述问题，本申请还公开了一种全局信息获取装置，所述装置包括：

当前版本信息获取模块，用于从全局信息服务器获取全局信息的当前版本信息；

历史版本信息更新模块，用于根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器；

全局信息获取模块，用于根据更新后的版本信息从所述全局信息服务器获取对应的全局信息。

可选地，所述版本信息包括过渡版本信息，所述全局信息获取模块包括：

过渡全局信息获取子模块，用于根据更新后的过渡版本信息从所述全局信息服务器获取对应的全局信息；

所述装置还包括：

停写标识判断模块，用于判断获取到的全局信息是否携带停写标识，若是，则暂停提供针对所述全局信息的服务。

可选地，所述装置还包括：

有效期更新模块，用于根据所述应用服务器与所述全局信息服务器的通讯状态更新历史版本信息的有效期。

可选地，所述有效期更新模块包括：

第一通讯状态确认信息发送子模块，用于定期向所述全局信息服务器发送第一通讯状态确认信息；

有效期重置子模块，用于当在预设时间段内收到所述全局信息服务器返回的第二通讯状态确认信息，则重置所述当前版本信息的有效期；

版本信息失效判定子模块，用于当在预设时间段内没有收到所述全局信息服务器返回的第二通讯状态确认信息，则判定所述当前版本信息失效，并暂停提供针对所述全局信息的服务。

可选地，所述全局信息服务器部署在所述应用服务器所属的区域；

所述全局信息服务器包括保存有所述全局信息的全局信息缓存服务器和保存有所述版本信息的版本信息管理服务器。

可选地，所述装置还包括：

版本信息订阅模块，用于订阅所述全局信息服务器中全局信息的版本信息；

所述当前版本信息获取模块包括：

当前版本信息下载子模块，用于当接收到所述全局信息服务器发送的版本信息更新通知时，从所述全局信息服务器下载所述全局信息的当前版本信息。

为了解决上述问题，本申请还公开了一种全局信息处理装置，所述装置 包括：

全局信息及版本信息获取模块，用于从全局信息更新管控设备获取全局信息以及对应的版本信息，并将所述版本信息发送至所述应用服务器；

第一更新确认通知收集模块，用于收集所述应用服务器返回的更新确认通知；

全局信息获取请求接收模块，用于接收所述应用服务器提交的全局信息获取请求；

全局信息查找模块，用于在所述全局信息获取请求携带的版本信息对应的全局信息中，查找所述应用服务器请求的全局信息并返回至所述应用服务器。

为了解决上述问题，本申请还公开了一种全局信息更新装置，所述装置包括：

全局信息及版本信息发送模块，用于将全局信息及对应的版本信息发送至全局信息服务器；

第二更新确认通知收集模块，用于通过所述全局信息服务器收集所述应用服务器在获取所述版本信息后返回的更新确认通知；

版本信息更新完毕标记模块，用于当收集到全部应用服务器返回的更新确认通知时，标记当前的全部应用服务器的版本信息更新完毕。

可选地，所述装置还包括：

过渡全局信息及过渡版本信息生成模块，用于针对全局信息中有更新的全局信息添加停写标识并生成过渡全局信息及对应的过渡版本信息；

所述全局信息及版本信息发送模块包括：

过渡全局信息及过渡版本信息发送子模块，用于将所述过渡全局信息及所述过渡版本信息发送至所述全局信息服务器。

可选地，所述全局信息及版本信息发送模块包括：

全局信息及版本信息对应发送子模块，用于将所述全局信息和所述版本信息对应发送至所述全局信息服务器的全局信息缓存系统和版本信息管理系统。

为了解决上述问题，本申请还公开了一种全局信息更新系统，所述系统包括：

应用服务器、全局信息服务器和全局信息更新管控设备；

所述应用服务器包括：

当前版本信息获取模块，用于从全局信息服务器获取全局信息的当前版本信息；

历史版本信息更新模块，用于根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器；

全局信息获取模块，用于根据更新后的版本信息从所述全局信息服务器获取对应的全局信息；

所述全局信息服务器包括：

全局信息及版本信息获取模块，用于从全局信息更新管控设备获取全局信息以及对应的版本信息，并将所述版本信息发送至所述应用服务器；

第一更新确认通知收集模块，用于收集所述应用服务器返回的更新确认通知；

全局信息获取请求接收模块，用于接收所述应用服务器提交的全局信息获取请求；

全局信息查找模块，用于在所述全局信息获取请求携带的版本信息对应的全局信息中，查找所述应用服务器请求的全局信息并返回至所述应用服务器；

所述全局信息更新管控设备包括：

全局信息及版本信息发送模块，用于将全局信息及对应的版本信息发送至全局信息服务器；

第二更新确认通知收集模块，用于通过所述全局信息服务器收集所述应用服务器在获取所述版本信息后返回的更新确认通知；

版本信息更新完毕标记模块，用于当收集到全部应用服务器返回的更新确认通知时，标记当前的全部应用服务器的版本信息更新完毕。

本申请实施例包括以下优点：

相比起目前的由应用服务器获取一个完整的、数据量较大的全局信息并相应返回更新确认通知，本申请实施例的应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，全局信息服务器本身独立地接收全局信息更新管控设备推送的各版本的全局信息，通过对全局信息与版本信息更新过程的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新。

同时，通过引入过渡全局信息以及相应的过渡版本信息，全局系统不可服务时间被极大地压缩，全局信息的更新效率也得到了极大的提升，避免了更新时全局系统服务长时间不可用的问题。

此外，应用服务器与全局信息服务器之间维持通讯状态确认，在通讯状态异常的情况下停止应用服务器提供服务，避免了应用服务器使用过期的全局信息而导致全局数据不一致的情况。

进一步，如果将本申请实施例应用到全局路由表的更新场景中，相比起目前的路由表更新方式中应用服务器需要获取一个完整的、数据量较大的路由表，本申请实施例通过对路由表与路由表版本信息的解耦，使得应用服务器仅需要获取数据量较小的版本信息，利用版本信息从全局信息服务器针对性地获取当前需要的路由数据，则可以满足用户的服务需求，从而提升全局路由表更新的效率。

而且，因为应用服务器数量庞大，目前的路由表全局更新方法中，这些数量庞大的应用服务器同时获取路由表，会造成对宽带的占用。而根据本申请实施例，仅由少量的全局信息服务器获取新版本的路由表，应用服务器仅仅针对性地从新版本的路由表中获取当前需要的路由数据，从而减少了对带宽的占用。

并且，通过引入路由表的过渡版本信息以及带有停写标识的过渡版本路由表，路由表更新过程被分成两个步骤。首先由旧版本的版本信息更新至过渡版本信息，待过渡版本信息更新完成，再开始更新至新版本 的版本信息。该更新方式可以使得应用服务器在接收版本信息的时间不一、且不需要全面暂停服务的前提下，保证了路由表数据的全局一致性。

附图说明

图1是本申请的一种全局信息获取方法实施例一的步骤流程图；

图2是本申请的一种全局信息获取方法实施例二的步骤流程图；

图3是本申请的一种全局信息获取方法实施例三的步骤流程图；

图4是本申请的一种全局信息处理方法实施例的步骤流程图；

图5是本申请的一种全局信息更新方法实施例的步骤流程图；

图6是本申请的一种全局信息获取装置实施例的结构框图；

图7是本申请的一种全局信息处理装置实施例的结构框图；

图8是本申请的一种全局信息更新装置实施例的结构框图；

图9是本申请的一种全局信息更新流程示意图；

图10是本申请的一种用于路有表的版本更新示意图；

图11是本申请的客户端与服务端sessiontimeout协商原理示意图；

图12是本申请的session注册的流程示意图；

图13是本申请的一种全局信息更新系统实施例的结构框图；

图14是本申请的一种全局信息更新系统架构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种全局信息获取方法实施例一的步骤流程图，所述方法应用于应用服务器，所述方法具体可以包括如下步骤：

步骤101，从全局信息服务器获取全局信息的当前版本信息。

需要说明的是，全局信息可以为vpc业务中的ip地址translation配置数据，或者是全局路由表，或者是任何的需要全局范围内进行更新以保证全局数据一致性的信息，本领域技术人员可以根据实际需要和本申请所提供的核心构思，应用于多种全局信息更新的场景中。

在电商平台的全局信息更新系统中，可以包含有全局信息更新管控设备，全局信息服务器和应用服务器。

全局信息更新管控设备负责协调全局信息更新过程，具体可以是由全局信息更新管控设备主动将更新的全局信息以及对应的版本信息推送至多个区域的全局信息服务器，或者将更新的全局信息推送至多个区域的全局信息服务器后，相应修改全局信息服务器的版本信息。需要说明的是，因为传输数据量较大的全局信息的过程耗时较长，全局信息更新管控设备可以仅仅将全局信息推送至全局信息服务器，而不触发全局信息的更新升级。在全局信息更新管控设备将数据量较小的版本信息推送至全局信息服务器后，则可以触发全局的更新升级。实际应用中，上述的全局信息更新管控设备可以为管控系统(managementcontrolsystem,mcs)。

全局信息服务器可以部署在应用服务器所属的区域。实际应用中，全局信息服务器可以分别设有全局信息缓存系统和版本信息管理系统。全局信息缓存系统可以缓存有全局信息更新管控设备推送的各个版本的全局信息。版本信息管理系统可以缓存有全局信息更新管控设备推送的各个版本全局信息的版本信息，或接受全局信息更新管控设备对其保存的版本信息的修改，此外还负责协调本区域内各个应用服务器的全局信息的版本信息更新过程，以维护全局信息的数据一致性。

当然，本领域技术人员也可以将全局信息缓存系统和版本信息管理系统分别应用于两个服务器上，即在每个区域分别设置全局信息缓存服务器和版本信息管理服务器。全局信息缓存服务器负责缓存来自于全局信息更新管控设备推送的全局信息，版本信息管理服务器负责保存有各个版本全局信息的版本信息以及协调本区域内各个应用服务器的版本信息更新过程。在实际应用中，可以将数据量较大、传输耗时较长的全局信息预先推送至全局信息缓存服务器，在将全局信息推送完毕后，再开始触发版本信息管理服务器对本区域内各个应用服务器自身记录的版本信息的更新工作，从而实现了全局信息与版本信息的分离。

应用服务器可以为电商平台上各类应用程序所对应的各个应用服务器, 其可以从本区域的全局信息服务器的版本信息管理系统中，通过订阅新的全局信息的版本信息的方式，以感知全局信息更新管控设备推送给全局信息服务器的新的版本信息或者对版本信息的修改，并从全局信息服务器获取新的全局信息的版本信息。

作为本申请实施例的优选示例，可以在所述步骤101之前，订阅全局信息服务器中全局信息的版本信息；当接收到全局信息服务器发送的版本信息更新通知时，从全局信息服务器下载全局信息的当前版本信息。通过应用服务器订阅全局信息服务器的方式，有助于应用服务器及时获取到需要更新的全局信息，提升了全局信息更新的效率。

步骤102，根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器。

在具体的实现中，应用服务器从全局信息服务器获取其当前全局信息的版本信息，根据获取到的版本信息，更新应用服务器原本记录有的历史版本信息，在更新完毕后，可以返回更新确认通知至全局信息服务器，以便于全局信息服务器收集更新确认通知并返回给全局信息更新管控设备。

步骤103，根据更新后的版本信息从所述全局信息服务器获取对应的全局信息。

应用服务器根据自身更新后的版本信息，从全局信息服务器获取该版本信息对应的全局信息，从而获取到更新后的全局信息。实际应用中可以获取一个完整的新版本的全局信息，也可以只获取有更新的部分全局信息。

相比起目前的由应用服务器获取一个完整的、数据量较大的全局信息并相应返回更新确认通知，本申请实施例的应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，全局信息服务器本身独立地接收全局信息更新管控设备推送的各版本的全局信息，通过对全局信息与版本信息更新过程的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新。

为了便于本领域技术人员理解本申请实施例，以下将以路由表作为全局信息作进一步解释说明。在全局路由表的更新场景中，可以根据跨境电商平台对用户访问记录的分析，分析出用户在一段时间内在哪个区域使用电商平台，从而确定用户实际归属的区域以及对应的互联网数据中心。当用户实际归属的互联网数据中心与历史版本全局信息中记录的不一致时，则需要更新全局信息的该条路由数据，从而产生了全局信息的更新需求。

应用服务器可以为电商平台上各类应用程序所对应的各个应用服务器，针对用户提交的服务获取请求，应用服务器从服务获取请求中提取出用户标识，根据用户标识和应用服务器自身记录的当前使用的全局信息的版本信息，向全局信息服务器请求查询该用户所归属的互联网数据中心，以访问该互联网数据中心获取相关的数据服务。

在针对路由表的全局信息更新场景中，应用服务器可以从全局信息服务器获取路由表的当前版本信息，并根据获取到的版本信息相应更新自身原有的历史版本信息，返回更新确认通知至本区域的全局信息服务器。

用户可以向电商平台提交基于某个应用程序的服务获取请求，该服务获取请求可以为对互联网数据中心中的数据库进行相关数据的增加、删除、修改等数据操作。电商平台可以将该服务获取请求发送至应用服务器进行具体处理。

应用服务器在接收到服务获取请求后，可以从服务获取请求中提取出用户标识，并结合自身更新后的版本信息，生成一个路由数据获取请求并发送至全局信息服务器。全局信息服务器可以根据其中的版本信息，查找到对应版本的全局信息，并在全局信息中查找到对应于用户标识的路由数据，将查找到的路由数据返回至应用服务器。

因为路由数据可以指示用户所归属的互联网数据中心，即，应用服务器所应该对应访问的互联网数据中心，因此，应用服务器按照该路由数据的指示，访问对应的互联网数据中心，并根据服务获取请求，在所访问的互联网数据中心中针对该用户的数据进行相关的数据操作，以满足用户的服务需求。

从上述可见，如果将本申请实施例应用到全局路由表的更新场景中，相比起目前的路由表更新方式中应用服务器需要获取一个完整的、数据量较大的路由表，本申请实施例通过对路由表与路由表版本信息的解耦，使得应用服务器仅需要获取数据量较小的版本信息，利用版本信息从全局信息服务器针对性地获取当前需要的路由数据，则可以满足用户的服务需求，从而提升全局路由表更新的效率。

而且，因为应用服务器数量庞大，目前的路由表全局更新方法中，这些数量庞大的应用服务器同时获取路由表，会造成对宽带的占用。而根据本申请实施例，仅由少量的全局信息服务器获取新版本的路由表，应用服务器仅仅针对性地从新版本的路由表中获取当前需要的路由数据，从而减少了对带宽的占用。

并且，通过引入路由表的过渡版本信息以及带有停写标识的过渡版本路由表，路由表更新过程被分成两个步骤。首先由旧版本的版本信息更新至过渡版本信息，待过渡版本信息更新完成，再开始更新至新版本的版本信息。该更新方式可以使得应用服务器在接收版本信息的时间不一、且不需要全面暂停服务的前提下，保证了路由表数据的全局一致性。

参照图2，示出了本申请的一种全局信息获取方法实施例二的步骤流程图，所述方法应用于应用服务器，所述方法具体可以包括如下步骤：

步骤201，从全局信息服务器获取全局信息的过渡版本信息；

步骤202，根据获取的过渡版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器。

步骤203，根据更新后的过渡版本信息从所述全局信息服务器获取对应的全局信息。

步骤204，判断获取到的全局信息是否携带停写标识，若是，则暂停提供针对所述全局信息的服务。

需要说明的是，在电商平台的全局信息更新系统中，由于全局信息服务器至本区域内的各个应用服务器的网络链路、物理距离等条件差异较大，可 能会造成部分应用服务器已经接收到了新的版本信息，而部分应用服务器还在接收当中；而且，无论外部条件再理想，也无法完全保证应用服务器同时接收到新的版本信息，如果应用服务器使用不同版本的全局信息提供服务，有可能造成全局数据不一致。而为了保证全局数据一致性，则必须全局都使用统一的全局信息，由此，部分获取到了新的版本信息的应用服务器需要处于等待的状态，无法继续服务用户，从而影响了电商平台的用户体验。

为了解决上述的技术问题，可以在历史版本全局信息更新至新版本的全局信息之间，插入一个过渡版本的全局信息。

在实际应用中，并非所有的全局信息都进行更新，因此，可以针对有更新的全局信息所涉及的服务进行暂停，其余的全局信息可以继续用于服务用户。

可以由全局信息更新管控设备针对全局信息中有变化或者待变化的全局信息添加停写标识，该停写标识用于暂停针对于该全局信息所相关的服务。全局信息更新管控设备可以将过渡版本全局信息及对应的过渡版本信息推送至全局信息服务器，应用服务器可以通过订阅的方式获取到过渡版本信息，利用过渡版本信息更新历史版本信息，并返回更新确认通知至全局信息服务器。

应用服务器将历史版本信息更新至过渡版本信息后，根据过渡版本信息从全局信息服务器获取对应的过渡版本的全局信息。应用服务器对获取到的全局信息进行判断，当全局信息携带有停写标识，则暂停提供携带有停写标识的全局信息所相关的服务。由此，在全局信息的整个更新过程中，即使旧版本的版本信息与过渡版本信息、或者过渡版本信息与新版本的版本信息同时存在于全局的应用服务器中，也不会影响全局的数据一致性，所影响到的用户服务，仅限于过渡版本的全局信息中待更新的部分全局信息所涉及的用户服务。因此，在旧版本的版本信息更新到新版本的版本信息中引入过渡版本的版本信息，先从旧版本更新到过渡版本，再由过渡版本更新至新版本，两个更新过程中均能在保证全局数据一致性的前提下，降低了全局信息更新对用户服务的影响，保持了服务的连续性，避免了全局信息更新过程中需要 全面暂停用户服务、影响用户体验的问题。

根据本申请实施例，通过在历史版本全局信息更新至新版本全局信息的过程中插入过渡版本全局信息，应用服务器根据过渡版本信息获取全局信息，仅在获取到携带有停写标识的全局信息时，才需要暂停部分服务，全局系统不可服务时间被极大地压缩，避免了更新时全局系统服务长时间不可用的问题，从而在保证了全局数据一致性的前提下，提升了电商平台服务的连续性，降低了全局信息更新时对用户的影响。

当全局信息为路由表时，可以从全局信息服务器获取路由表的当前版本信息，根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器。在接收到用户提交的服务获取请求后，根据更新后的过渡版本信息从所述全局信息服务器获取对应的路由数据。判断获取到的路由数据是否携带停写标识，若是，则返回拒绝所述服务获取请求的提示通知至所述用户。

因为在实际的应用当中，并非全部用户归属的互联网数据中心会发生变化。因此，可以由全局信息更新管控设备针对全局信息中有变化的或待变化的路由数据添加停写标识，该停写标识用于暂停用户针对实际归属或原归属的互联网数据中心进行写入数据等可能会导致全局数据不一致的操作。参见图10，示出了一种用于路由表的版本更新示意图，在过渡版本的路由表中，每条路由数据可以包含有用户id(userid)，对应每一个用户id的归属idc，及该用户针对其归属idc是否可写的标志。

在具体的实现中，针对获取到的路由数据，判断其是否携带有停写标识，若该路由数据携带有停写标识，表示该用户所处的区域已经发生变更，用户实际归属的互联网数据中心与原归属的互联网数据中心不一致，如果继续允许用户访问原归属的互联网数据中心，用户在针对原归属互联网数据中心写入数据后会造成全局数据不一致，因此，可以返回一个拒绝用户提交的服务获取请求的提示通知给用户，暂时拒绝用户访问原归属的互联网数据中心。

应用服务器在获取到过渡版本信息后可以立即继续服务用户，仅仅在从全局信息服务器中获取到携带有停写标识的路由数据时，才需要拒绝用户对 该用户实际归属或原归属的互联网数据中心的访问，即，应用服务器处于过渡版本信息时仅需要暂停部分用户的部分服务，对于其他用户则完全没有影响。

参照图3，示出了本申请的一种全局信息获取方法实施例三的步骤流程图，所述方法应用于应用服务器，所述方法具体可以包括如下步骤：

步骤301，从全局信息服务器获取全局信息的当前版本信息。

步骤302，根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器。

步骤303，根据更新后的版本信息从所述全局信息服务器获取对应的全局信息。

步骤304，根据所述应用服务器与所述全局信息服务器的通讯状态更新历史版本信息的有效期。

需要说明的是，在实际应用中，跨境电商平台数量庞大的应用服务器可能会因为网络异常或者更新进程“假死”等原因，造成全局信息更新管控设备在通过全局信息服务器确认应用服务器针对版本信息的更新情况时，可能会遗漏了部分应用服务器，误以为全部应用服务器已经获取了更新后的版本信息，并发起启用新版本的全局信息的指令给应用服务器，而因为网络异常或者更新进程“假死”的部分应用服务器则错过了版本信息的更新，这部分应用服务器不知道自己使用的版本信息已过期，继续使用历史版本信息服务用户，最终可能会导致全局数据不一致。

为了解决上述的技术问题，本申请实施例提出了基于有效期的全局信息版本信息分布式协调管理机制。

在具体的实现中，可以先确定应用服务器与全局信息服务器的通讯状态，当通讯状态正常，则可以重置正在使用的历史版本信息的有效期，在该有效期之内可以正常使用历史版本信息服务用户。当出现通讯状态异常，例如应用服务器在一段时间内都无法连接全局信息服务器，则判定该历史版本信息失效，因为在这一段时间内，可能有新版本的全局信息的更新，如果继 续使用历史版本信息服务用户，可能会导致全局数据不一致，因此需要暂停使用历史版本信息服务用户。

本领域技术人员可以通过多种方式确定通讯状态的方式，例如通过互相发送心跳包的方式确定。本领域技术人员也可以根据实际情况确定版本信息的有效期，例如由应用服务器与全局信息服务器自动协商以确定有效期。

作为本申请实施例的优选示例，所述步骤304可以包括以下子步骤：

子步骤s11，定期向所述全局信息服务器发送第一通讯状态确认信息。

子步骤s12，当在预设时间段内收到所述全局信息服务器返回的第二通讯状态确认信息，则重置所述当前版本信息的有效期。

子步骤s13，当在预设时间段内没有收到所述全局信息服务器返回的第二通讯状态确认信息，则判定所述当前版本信息失效，并暂停提供针对所述全局信息的服务。

在具体的实现中，应用服务器可以定期向全局信息服务器发送第一通讯状态确认信息，如果通讯状态正常，全局信息服务器可以在预设时间段内收到第一通讯状态确认信息并相应返回第二通讯状态确认信息。当应用服务器收到第二通讯状态确认信息，则表示当前与全局信息服务器的通讯状态正常，可以重置当前使用的全局信息的版本信息的有效期，继续使用该版本信息处理用户的服务获取请求。

当在预设时间段内没有收到全局信息服务器返回的第二通讯状态确认信息，则表示与其的通讯出现异常，在该时间段内有可能需要更新全局信息的版本信息，针对这种不确定性，应用服务器可以判定当前的版本信息失效，不再使用其服务用户，以保证全局数据一致性。

为了便于理解，以下详细解释一种基于有效期的全局信息版本信息分布式协调管理机制的应用实施例。

可以将应用服务器作为全局信息版本信息分布式协调管理机制中的客户端，将全局信息服务器作为其中的服务端。客户端与服务端通过session(会话)表示之间连接状态的有效期，客户端向服务端注册session时，需要指定一个clientsessiontimeout(客户端会话失效时间值)，服务端会据此 计算出对应的serversessiontimeout(服务端会话失效时间值)。客户端和服务端通过心跳互相确认session的有效性，如果其中一端的sessiontimeout时间内没有收到另一端的心跳回复，则可以主动判断该session过期。

客户端与服务端互相协商出来的sessiontimeout，能够保证服务端根据serversessiontimeout判断某个session过期时，相对的，客户端根据自身的clientsessiontimeout(cst)也可以提前判断某个session是否过期。图11展示了两端的sessiontimeout协商原理。客户端的sessiontimeout被拆分成确定session正常的mp(maintainingperiod，保持连接期)，以及发现连接异常后重新连接服务端的rp(reconnectingperiod，重新连接期)。对于极不理想的情况，服务端立即受到了客户端发送的心跳包，在第二个mp结束后没有接受到心跳包回复，可以认为客户端与服务端的连接状态出现异常，进入重新连接其他服务端的rp阶段，并同时判定该session过期。而一直在等待心跳包的服务端此时也需要判断该session过期。因此，clientsessiontimeout可以设置为mp+rp，而serversessiontimeout则至少为mp*2+rp或cst*2，从而协商出的sessiontimeout可以使得客户端与服务端双方对session过期的判断保持一致性。

对于全局信息版本信息分布式协调管理机制，每个应用服务器可以基于代表关联数据有效期的租约lease值确定clientsessiontimeout，向本区域的全局信息服务器注册session。图12展示了session注册的具体流程，应用服务器注册session成功后即可进入connected(已连接)状态，并开始本地全局信息的版本信息关联的lease有效期。然后，应用服务器与本区域的全局信息服务器的版本信息管理系统维持定期的相互心跳确认，并根据心跳回复，重置本地版本信息对应的lease有效期。如果应用服务器没有收到心跳回复，可以重新回到connecting(连接中)状态，并尝试重新注册session，如果在clientsessiontimeout内没有注册成功，则可以判定session过期，即本地全局信息的版本信息对应的lease有效期失效，拒绝所有和该版本信息有关的操作，从而维持全局数据一致性。

根据本申请实施例，在对全局信息与版本信息的解耦的基础上，通过根 据应用服务器与全局信息服务器的通讯状态更新历史版本信息的有效期，在通讯状态异常的情况下停止应用服务器提供服务，避免了应用服务器会因为网络异常或者更新进程“假死”等原因造成的全局数据不一致的问题。

参照图4，示出了本申请的一种全局信息处理方法实施例的步骤流程图，所述方法应用于全局信息服务器，所述方法具体可以包括如下步骤：

步骤401，从全局信息更新管控设备获取全局信息以及对应的版本信息，并将所述版本信息发送至所述应用服务器。

步骤402，收集所述应用服务器返回的更新确认通知。

在本申请实施例的电商平台全局信息更新系统中，全局信息服务器从全局信息更新管控设备获取新版本的全局信息以及对应的版本信息。

实际应用中，全局信息服务器可以分别设有全局信息缓存系统和版本信息管理系统。全局信息缓存系统可以保存有各个版本的全局信息。版本信息管理系统可以保存有从全局信息更新管控设备获取到的各个版本全局信息的版本信息，或接受全局信息更新管控设备对其保存的版本信息的修改。当然，全局信息服务器也可以根据获取到的全局信息自行生产对应的版本信息。实际应用中，本领域技术人员也可以将全局信息缓存系统和版本信息管理系统分别设置于两个服务器上，即分设分布式缓存服务器和分布式协调服务器，分布式缓存服务器负责缓存来自于全局信息更新管控设备推送的全局信息，分布式协调服务器负责协调本区域内各个应用服务器的全局信息的版本信息更新过程。

可以将新版本的全局信息的版本信息发送至本区域内的应用服务器。应用服务器根据新版本的全局信息的版本信息更新其原本的历史版本信息，并返回更新确认通知。全局信息服务器从本区域的多个应用服务器收集全局信息的版本信息的更新确认通知，以便于将本区域的版本信息的更新情况反馈给全局信息更新管控设备。

步骤403，接收所述应用服务器提交的全局信息获取请求。

步骤404，在所述全局信息获取请求携带的版本信息对应的全局信息中， 查找所述应用服务器请求的全局信息并返回至所述应用服务器。

应用服务器可以根据自身需要向全局信息服务器提交一个携带有当前的版本信息的全局信息获取请求，全局信息服务器在接收该全局信息获取请求后，可以根据请求中携带的版本信息，查找对应版本的全局信息，并将查找到的全局信息返回给应用服务器。

当全局信息为路由表时，应用服务器在接收到用户提交的服务获取请求后，可以从服务获取请求中提取出用户标识，并结合自身更新后的版本信息，生成一个路由数据获取请求并发送至全局信息服务器。全局信息服务器可以根据其中的版本信息，查找到对应版本的全局信息，并在全局信息中查找到对应于用户标识的路由数据，将查找到的路由数据返回至应用服务器，以供应用服务器可以访问对应的互联网数据中心。

本申请实施例通过对全局信息与全局信息版本信息的解耦，使得全局信息服务器仅需要将版本信息发送至应用服务器，利用版本信息从全局信息中查找并返回相应的路由数据，则可以满足用户的服务需求，因此，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新，提升了全局信息的更新效率，避免了更新时全局系统服务长时间不可用的问题。

参照图5，示出了本申请的一种全局信息更新方法实施例的步骤流程图，所述方法应用于全局信息更新管控设备，所述方法具体可以包括如下步骤：

步骤501，将全局信息及对应的版本信息发送至全局信息服务器。

需要说明的是，在电商平台的全局信息更新系统中，全局信息更新管控设备负责协调全局的全局信息更新过程，可以根据收集到的更新确认通知，确认是否在全局启用新版本的全局信息并下发相应的指示。

全局信息更新管控设备可以根据针对更新的全局信息生成一个新版本的全局信息及对应的版本信息，并将其推送至各个区域的全局信息服务器。

作为本申请实施例的优选示例，所述步骤501可以包括以下子步骤：

子步骤s21，将所述全局信息和所述版本信息对应发送至所述全局信息服务器的全局信息缓存系统和版本信息管理系统。

在实际应用中，全局信息服务器可以分别设有全局信息缓存系统和版本信息管理系统。全局信息缓存系统可以缓存有全局信息更新管控设备推送的各个版本的全局信息，版本信息管理系统可以缓存有全局信息更新管控设备推送的各个版本全局信息的版本信息。因此，全局信息更新管控设备可以对应于两个系统分别发送全局信息和版本信息，当然，本领域技术人员可以根据实际需要，提前一定时间发送全局信息至全局信息缓存系统，在全局信息发送完毕后再发送版本信息至版本信息管理系统，使得全局信息与版本信息分离。

步骤502，通过所述全局信息服务器收集所述应用服务器在获取所述版本信息后返回的更新确认通知。

在实际应用中，可以由全局信息服务器收集应用服务器返回的更新确认通知，全局信息更新管控设备从全局信息服务器中统一收集这些更新确认通知，或者全局信息更新管控设备订阅全局信息服务器对更新确认通知的收集情况，又或者，由全局信息服务器根据收集到的更新确认通知，生成一个更新确认通知汇总并反馈给全局信息更新管控设备。本领域技术人员可以根据实际情况采用其他的更新确认通知收集方式。

相比起目前的全局信息更新管控设备直接从数量庞大的应用服务器收集更新确认通知，本申请实施例对更新确认通知的收集方法中，全局信息更新管控设备仅需要与少量的全局信息服务器进行信息交互即可了解到全局的全局信息更新情况，节省了全局信息更新管控设备的处理资源。

步骤503，当收集到全部应用服务器返回的更新确认通知时，标记当前的全部应用服务器的版本信息更新完毕。

全局信息更新管控设备通过全局信息服务器收集到全部应用服务器的更新确认通知，可以说明全局的应用服务器已经做好启用新版本的全局信息的准备，可以当前的全局应用服务器的版本信息更新完毕，指示全局启用新版本的全局信息。

本申请实施例的应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，通过对全局信息与版本信息的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新，提升了全局信息的更新效率，避免了更新时全局系统服务长时间不可用的问题。

作为本申请实施例的优选示例，在所述步骤501之前，所述方法可以还包括以下步骤：针对全局信息中有更新的全局信息添加停写标识并生成过渡全局信息及对应的过渡版本信息。

在具体的实现中，全局信息更新管控设备可以针对全局信息中有更新的全局信息添加停写标识。该停写标识用于暂停针对于该全局信息所相关的服务。全局信息更新管控设备可以将过渡版本全局信息及对应的过渡版本信息推送至全局信息服务器，应用服务器可以通过订阅的方式获取到过渡版本信息，利用过渡版本信息更新历史版本信息，并返回更新确认通知至全局信息服务器。

当全局信息为路由表时，该停写标识用于暂停用户针对实际归属或原归属的互联网数据中心进行写入数据等可能会导致全局数据不一致的操作。全局信息更新管控设备将过渡版本全局信息及对应的过渡版本信息推送至全局信息服务器，由全局信息服务器发送至应用服务器，应用服务器在获取到过渡版本信息后可以立即继续服务用户。

为了便于本领域技术人员理解本申请实施例，图9示出了一个全局信息更新流程示意图。

从图9可见，一个跨区域电商平台可以设置有一个管控系统，管控系统负责协调多个区域的全局信息更新过程，其中每个区域可以设置一个包含全局信息缓存系统和版本信息管理系统的全局信息服务器，每个全局信息服务器负责多个应用服务器的版本信息更新和服务其对路由数据的获取请求。管控系统将新版本的全局信息推送至全局信息服务器的全局信息缓存系统，并修改版本信息管理系统的全局信息的版本信息。应用服务器通过订阅全局信 息服务器的版本信息管理系统中的版本信息，感知管控系统对版本信息的修改。应用服务器更新自身的版本信息后，返回更新确认通知至全局信息服务器的版本信息管理系统。管控系统通过订阅版本信息管理系统的方式，确认应用服务器的版本信息更新完成。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图6，示出了本申请的一种全局信息获取装置实施例的结构框图，所述装置应用于应用服务器，所述装置具体可以包括如下模块：

当前版本信息获取模块601，用于从全局信息服务器获取全局信息的当前版本信息。

历史版本信息更新模块602，用于根据获取的版本信息相应更新历史版本信息，返回更新确认通知至所述全局信息服务器。

全局信息获取模块603，用于根据更新后的版本信息从所述全局信息服务器获取对应的全局信息。

停写标识判断模块604，用于判断获取到的全局信息是否携带停写标识，若是，则暂停提供针对所述全局信息的服务。

有效期更新模块605，用于根据所述应用服务器与所述全局信息服务器的通讯状态更新历史版本信息的有效期。

作为本申请实施例的优选示例，所述版本信息包括过渡版本信息，所述全局信息获取模块603可以包括以下子模块：

过渡全局信息获取子模块，用于根据更新后的过渡版本信息从所述全局信息服务器获取对应的全局信息。

作为本申请实施例的优选示例，所述装置可以还包括：

版本信息订阅模块，用于订阅所述全局信息服务器中全局信息的版本信 息。

作为本申请实施例的优选示例，所述当前版本信息获取模块601可以包括以下子模块：

当前版本信息下载子模块，用于当接收到所述全局信息服务器发送的版本信息更新通知时，从所述全局信息服务器下载所述全局信息的当前版本信息。

作为本申请实施例的优选示例，所述有效期更新模块605可以包括以下子模块：

第一通讯状态确认信息发送子模块，用于定期向所述全局信息服务器发送第一通讯状态确认信息。

有效期重置子模块，用于当在预设时间段内收到所述全局信息服务器返回的第二通讯状态确认信息，则重置所述当前版本信息的有效期。

版本信息失效判定子模块，用于当在预设时间段内没有收到所述全局信息服务器返回的第二通讯状态确认信息，则判定所述当前版本信息失效，并暂停提供针对所述全局信息的服务。

相比起目前的由应用服务器获取一个完整的、数据量较大的全局信息并相应返回更新确认通知，本申请实施例的应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，全局信息服务器本身独立地接收全局信息更新管控设备推送的各版本的全局信息，通过对全局信息与版本信息更新过程的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新。

同时，通过引入过渡全局信息以及相应的过渡版本信息，全局系统不可服务时间被极大地压缩，全局信息的更新效率也得到了极大的提升，避免了更新时全局系统服务长时间不可用的问题。

此外，应用服务器与全局信息服务器之间维持通讯状态确认，在通讯状态异常的情况下停止应用服务器提供服务，避免了应用服务器使用 过期的全局信息而导致全局数据不一致的情况。

参照图7，示出了本申请的一种全局信息处理装置实施例的结构框图，所述装置应用于全局信息服务器，所述装置具体可以包括如下模块：

全局信息及版本信息获取模块701，用于从全局信息更新管控设备获取全局信息以及对应的版本信息，并将所述版本信息发送至所述应用服务器。

第一更新确认通知收集模块702，用于收集所述应用服务器返回的更新确认通知。

全局信息获取请求接收模块703，用于接收所述应用服务器提交的全局信息获取请求。

全局信息查找模块704，用于在所述全局信息获取请求携带的版本信息对应的全局信息中，查找所述应用服务器请求的全局信息并返回至所述应用服务器。

本申请实施例的应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，通过对全局信息与版本信息的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新，提升了全局信息的更新效率，避免了更新时全局系统服务长时间不可用的问题。

参照图8，示出了本申请的一种全局信息更新装置实施例的结构框图，所述装置应用于全局信息更新管控设备，所述装置具体可以包括如下模块：

全局信息及版本信息发送模块801，用于将全局信息及对应的版本信息发送至全局信息服务器。

第二更新确认通知收集模块802，用于通过所述全局信息服务器收集所述应用服务器在获取所述版本信息后返回的更新确认通知。

版本信息更新完毕标记模块803，用于当收集到全部应用服务器返回的更新确认通知时，标记当前的全部应用服务器的版本信息更新完毕。

作为本申请实施例的优选示例，所述装置可以还包括以下模块：

过渡全局信息及过渡版本信息生成模块804，用于针对全局信息中有更新的全局信息添加停写标识并生成过渡全局信息及对应的过渡版本信息。

作为本申请实施例的优选示例，所述全局信息及版本信息发送模块801可以包括以下子模块：

过渡全局信息及过渡版本信息发送子模块，用于将所述过渡全局信息及所述过渡版本信息发送至所述全局信息服务器。

作为本申请实施例的优选示例，所述全局信息及版本信息发送模块801可以包括以下子模块：

全局信息及版本信息对应发送子模块，用于将所述全局信息和所述版本信息对应发送至所述全局信息服务器的全局信息缓存系统和版本信息管理系统。

本申请实施例的应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，通过对全局信息与版本信息的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新，提升了全局信息的更新效率，避免了更新时全局系统服务长时间不可用的问题。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

参照图13，示出了本申请的一种全局信息更新系统实施例的结构框图，所述系统具体可以包括：

应用服务器1301，全局信息服务器1302和全局信息更新管控设备1303。

所述应用服务器1301可以包括以下模块：

当前版本信息获取模块，用于从全局信息服务器获取全局信息的当前版本信息。

历史版本信息更新模块，用于根据获取的版本信息相应更新历史版本信 息，返回更新确认通知至所述全局信息服务器。

全局信息获取模块，用于根据更新后的版本信息从所述全局信息服务器获取对应的全局信息。

所述全局信息服务器1302可以包括以下模块：

全局信息及版本信息获取模块，用于从全局信息更新管控设备获取全局信息以及对应的版本信息，并将所述版本信息发送至所述应用服务器。

第一更新确认通知收集模块，用于收集所述应用服务器返回的更新确认通知。

全局信息获取请求接收模块，用于接收所述应用服务器提交的全局信息获取请求。

全局信息查找模块，用于在所述全局信息获取请求携带的版本信息对应的全局信息中，查找所述应用服务器请求的全局信息并返回至所述应用服务器。

所述全局信息更新管控设备1303可以包括以下模块：

全局信息及版本信息发送模块，用于将全局信息及对应的版本信息发送至全局信息服务器。

第二更新确认通知收集模块，用于通过所述全局信息服务器收集所述应用服务器在获取所述版本信息后返回的更新确认通知。

版本信息更新完毕标记模块，用于当收集到全部应用服务器返回的更新确认通知时，标记当前的全部应用服务器的版本信息更新完毕。

本申请实施例的全局信息更新系统中，应用服务器在获取到数据量较小的版本信息后即可返回更新确认通知，并根据更新后的版本信息从全局信息服务器获取相应的全局信息，全局信息服务器本身独立地接收全局信息更新管控设备推送的各版本的全局信息，通过对全局信息与版本信息更新过程的解耦，即使存在网络链路、物理距离等诸多条件的差异，各应用服务器获取版本信息所耗费时间的差距也会相对较小，由此可以在较短的一个时间段内完成全局版本信息的更新。

为了便于本领域技术人员理解本申请实施例，图14示出了一种全局信 息更新系统架构示意图。

从图中可见，全局信息更新系统架构中设置有一个全局更新管控设备，负责协调全局多个区域的全局信息更新过程。可以是由全局信息更新管控设备主动将更新的全局信息以及对应的版本信息推送至多个区域的全局信息服务器，或者将更新的全局信息推送至多个区域的全局信息服务器后，相应修改全局信息服务器的版本信息。

全局信息服务器可以部署在应用服务器所属的区域。全局信息服务器可以分别设有全局信息缓存系统和版本信息管理系统。全局信息缓存系统可以缓存有全局信息更新管控设备推送的各个版本的全局信息。版本信息管理系统可以缓存有全局信息更新管控设备推送的各个版本全局信息的版本信息，或接受全局信息更新管控设备对其保存的版本信息的修改，此外还负责协调本区域内各个应用服务器的全局信息的版本信息更新过程，以维护全局信息的数据一致性。

应用服务器可以为各类应用程序所对应的各个应用服务器,其可以从本区域的全局信息服务器的版本信息管理系统中，通过订阅新的全局信息的版本信息的方式，以感知全局信息更新管控设备推送给全局信息服务器的新的版本信息或者对版本信息的修改，并从全局信息服务器获取新的全局信息的版本信息。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设 备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种全局信息获取方法和装置，一种全局信息处理方法和装置，及一种全局信息更新方法和装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。