客户端拉取配置数据的方法及装置的制造方法
【技术领域】
[0001] 本发明涉及通信领域，具体而言，涉及一种客户端拉取配置数据的方法及装置。
【背景技术】
[0002] 配置（Configuration)是在软件开发或系统实现中将一些可能变化的数据封装 成结构实体，并不依赖软件更新或发布而实现功能调整或控制行为的方式，配置的主要特 点是可以直接更新而不依赖于重新发布程序。
[0003] 在软件架构中，客户端软件会需要各种类型的配置数据。一般情况下，这些配置数 据存储在客户端本地，例如，数据库或可扩展标记语言（XML)文件中。在一般运营型的项目 中，配置要求不依赖于新版本客户端的发布而去维护和更新，则通常会将配置信息存储在 服务器上，由相应的人员去维护进行更新。
[0004] 对于这些变更不是很频繁的数据，客户端需要与服务器进行通信来获取。如果客 户端每次都在相应的触发点（例如程序启动，登录等时机）进行一次强制拉取，会增加没必 要的数据流量和服务器的压力，但是如果同步的较慢，也不利于配置数据的维护和更新，在 这两者之间存在一定的矛盾。那么如何在两者之间找到一个平衡点，设计一种更新同步策 略成为开发中需要解决的问题。此外，针对各种配置类型采用不同的更新策略和存储方式， 提供更高的抽象层次也是亟待解决的问题。
【发明内容】
[0005] 本发明的主要目的在于公开了一种客户端拉取配置数据的方法及装置，以至少解 决相关技术中采用的客户端配置策略，无法平衡流量和及时性的问题。
[0006] 根据本发明的一个方面，提供了 一种客户端拉取配置数据的方法。
[0007] 根据本发明的客户端拉取配置数据的方法包括：客户端获取向服务器同步配置的 最大时间间隔（Timetolive，简称为TTL)，以及上一次向服务器拉取配置数据的时间戳； 客户端根据时间戳确定TTL是否已经过期；在TTL已经过期的情况下，客户端向服务器拉 取配置域数据；客户端将从配置域数据中获取配置表的令牌值与本地存储的令牌值进行对 比；如果获取的令牌值与本地存储的令牌值不一致，则向服务器拉取获取的令牌值对应的 配置表数据。
[0008] 根据本发明的另一方面，提供了 一种客户端拉取配置数据的装置。
[0009] 根据本发明的客户端拉取配置数据的装置包括：获取模块，用于获取向服务器同 步配置的最大时间间隔TTL，以及上一次向服务器拉取配置数据的时间戳；确定模块，用于 根据时间戳确定TTL是否已经过期；第一拉取模块，用于在TTL已经过期的情况下，向服务 器拉取配置域数据；对比模块，用于将从配置域数据中获取的配置表的令牌值与本地存储 的令牌值进行对比；第二拉取模块，用于在获取的令牌值与本地存储的令牌值不一致时，向 服务器拉取获取的令牌值对应的配置表数据。
[0010] 通过本发明，在设置的TTL已经过期的情况下，客户端向服务器拉取配置域数据， 在获取的令牌值与本地存储的令牌值不一致的情况下，向服务器拉取获取的令牌值对应的 配置表数据，由此可见，对配置的使用进行了详细的分类，提供了优化的更新机制和策略来 解决流量和及时性的平衡。
【附图说明】
[0011] 图1是根据本发明实施例的客户端拉取配置数据的方法的流程图；
[0012] 图2是根据本发明优选实施例的客户端拉取配置域数据的方法的流程图；
[0013] 图3是根据本发明优选实施例的客户端拉取配置表数据的方法的流程图；
[0014] 图4是根据本发明优选实施例的客户端拉取配置数据的方法的流程图；
[0015] 图5是根据本发明实施例的客户端拉取配置数据的装置的结构框图；以及
[0016] 图6是根据本发明优选实施例的客户端拉取配置数据的装置的结构框图。
【具体实施方式】
[0017] 下面结合说明书附图对本发明的具体实现方式做一详细描述。
[0018] 图1是根据本发明实施例的客户端拉取配置数据的方法的流程图。如图1所示， 该客户端拉取配置数据的方法包括：
[0019] 步骤S101:客户端获取向服务器同步配置的最大时间间隔（TTL)，以及上一次向 上述服务器拉取配置数据的时间戳；
[0020] 步骤S103:上述客户端根据上述时间戳确定上述TTL是否已经过期；
[0021] 步骤S105:在上述TTL已经过期的情况下，上述客户端向上述服务器拉取配置域 数据；
[0022] 步骤S107:上述客户端将从上述配置域数据中获取配置表的令牌值与本地存储 的令牌值进行对比；
[0023] 步骤S109:如果上述获取的令牌值与上述本地存储的令牌值不一致，则向上述服 务器拉取上述获取的令牌值对应的配置表数据。
[0024] 通过本发明，在设置的TTL已经过期的情况下，上述客户端向上述服务器拉取配 置域数据，在上述获取的令牌值与上述本地存储的令牌值不一致的情况下，向上述服务器 拉取上述获取的令牌值对应的配置表数据，由此可见，对配置的使用进行了详细的分类，提 供了优化的更新机制和策略来解决流量和及时性的平衡。
[0025] 其中，上述TTL根据当前配置域承载的配置信息的需求情况动态设置。即TTL的 时间长短可根据目前ConfigField承载的配置信息需要的及时性来进行配置，如果需要及 时性较高（频率较高）则配置TTL短一些，如果不是很及时（频率较低）的就可以长一些， 以减少服务器请求的压力和流量。
[0026] 优选地，步骤S101中，上述客户端获取向服务器同步配置的上述TTL可以进一步 包括：上述客户端查找本地的XML文件；如果在本地没查找到XML文件，则上述客户端使用 资源文件中的XML文件，并下载上述XML文件保存到本地；上述客户端解析上述XML文件中 得到上述TTL。
[0027] 优选地，步骤S105中上述客户端向上述服务器拉取配置域数据之后，还可以包 括：上述客户端记录拉取时间，将拉取到的配置域数据保存在本地并解析上述配置域数据。
[0028] 优选地，在步骤S109向上述服务器拉取配置表数据之后，还可以包括以下处理： 上述客户端将本地保存的配置表数据全量更新为上述拉取到的配置表数据。
[0029] 其中，针对各种配置数据，本方案抽象出配置域和配置表两种数据结构来维护和 管理配置：
[0030] 配置域数据主要以键值对的形式存在，一般用一个整数作为键，以一个字符串作 为值，如果存储的是一个数值型配置那么需要程序代码在使用时自行从字符串转换为数 值；以及
[0031] 配置表数据主要是以表格的形式存在，表格中的每一条代表配置项目，例如国家 码，区域码等。
[0032] 以上两种抽象可以承载几乎所有的配置数据，也包括上述的配置域的更新TTL和 配置表的更新令牌（TOKEN)等。
[0033] 对于配置数据的拉取方式，本发明实施例采用两种机制。
[0034] 第一种，对于配置数据中的配置域数据，基于TTL的更新机制，客户端本地判断上 次拉取服务器配置的时间与本次拉取时间的间隔是否大于某一时长（TTL值），如果大于该 时长，则向服务器重新拉取配置域数据，否则流程结束。具体的TTL的更新机制如图2所示。
[0035] 图2是根据本发明优选实施例的客户端拉取配置域数据的方法的流程图。如图2 所示，该客户端拉取配置域数据的方法包括：
[0036] 步骤S201:客户端解析本地路径下的XML文件，如果该XML文件不存在，则解析资 源包中的XML文件。
[0037] 步骤S203:客户端获取TTL以及上一次向上述服务器拉取配置数据的时间戳，根 据上述时间戳确定上述TTL已经过期。
[0038] 步骤S205:客户端向服务器拉取配置域数据。
[0039] 步骤S207 :服务器返回上述配置域数据。
[0040] 步骤S209:服务器记录拉取时间，将结果存储在本地路径下并解析。
[0041] 第二种，对于配置数据中的配置表数据，基于令牌（TOKEN)的更新机制，客户端向 服务器查询TOKEN字段，与本地配置的TOKEN进行对比，如果有变化则向服务器拉取新的配 置，否则流程结束。具体的TOKEN的更新机制如图3所示。
[0042] 图3是根据本发明优选实施例的客户端拉取配置表数据的方法的流程图。如图3 所示，该客户端拉取配置表数据的方法包括：
[0043] 步骤S301:客户端从服务器拉取更新配置TOKEN。
[0044] 步骤S303:客户端将拉取的TOKEN与本地TOKEN进行对比。如果相同，则流程结 束，如果不相同，则执行步骤S305。
[0045] 步骤S305:客户端向服务器拉取配置表数据。
[0046] 由此可见，基于TOKEN的更新方式每次都向服务器拉取一次TOKEN数据，浪费了一 定的流量但是实时性较好，两种更新机制的对比：
[0047]<