CN113138781B

CN113138781B - Csv配置更新方法、存储介质

Info

Publication number: CN113138781B
Application number: CN202010058279.4A
Authority: CN
Inventors: 刘德建; 林琛; 陈波; 伍张发
Original assignee: Fujian Tianyi Network Technology Co ltd
Current assignee: Fujian Tianyi Network Technology Co ltd
Priority date: 2020-01-19
Filing date: 2020-01-19
Publication date: 2022-07-26
Anticipated expiration: 2040-01-19
Also published as: CN113138781A

Abstract

本发明提供CSV配置更新方法、存储介质，方法包括：提交CSV格式配置文件至GIT服务器的配置目录；服务端加载所述CSV格式配置文件；服务端解析CSV格式配置文件为字典结构的配置文件；服务端输出配置文件至公共目录；服务端启动HTTP服务后，输出本地的配置文件的版本号至客户端，使客户端判断接收到的版本号与本地的配置文件的版本号是否一致；若不一致，则从公共目录获取所述配置文件。本发明能够实现客户端与服务端配置文件格式数据的统一，共同维护同一份配置文件的版本管理；能够实现双端配置文件版本更新的一致性，确保运行正常；还能兼容配置文件对应客户端的差异性；同时提供对客户端友好的多格式配置文件。

Description

CSV配置更新方法、存储介质

技术领域

本发明涉及配置更新领域，具体涉及CSV配置更新方法、存储介质。

背景技术

CSV配置文件大多运用于游戏领域，用于存储游戏配置数据。目前，游戏配置一般会一式两份，分别提供给客户端与服务端。分配到手后的更新配置由各自独立更新，配置结构也未统一数据格式。但要求确是需要维护两份配置文件版本更新保持一致，若出现不一致且版本之间不兼容，会导致游戏运行异常，需要花更多时间去核查版本一致性问题。因此，有必要对CSV配置文件的更新方式进行优化，以解决更新不统一的问题。

发明内容

本发明所要解决的技术问题是：提供CSV配置更新方法、存储介质，实现客户端与服务端保持配置文件版本的一致性。

为了解决上述技术问题，本发明采用的技术方案为：

CSV配置更新方法，包括：

提交CSV格式配置文件至GIT服务器的配置目录；

服务端监控到所述配置目录发生变化后，加载所述CSV格式配置文件；

服务端解析所述CSV格式配置文件为字典结构的配置文件，并存储至本地；

服务端输出所述配置文件至公共目录；

服务端启动HTTP服务后，输出本地的配置文件的版本号至客户端，使客户端判断接收到的版本号与本地的配置文件的版本号是否一致；若不一致，则从公共目录获取所述配置文件。

本发明提供的另一个技术方案为：

一种计算机可读存储介质，其上存储有计算机程序，所述程序在被处理器执行时，能够实现上述CSV配置更新方法所包含的步骤。

本发明的有益效果在于：本发明不仅统一了服务端与客户端的CSV配置文件的数据格式，减少了策划人员的管理和制作时间；并且实现了对同一份配置文件的版本管理，以及客户端和服务端的新版本检查并统一更新，保证了双端配置文件版本的一致性，确保游戏正常运行。

附图说明

图1为本发明实施例一种CSV配置更新方法的流程示意图；

图2为本发明实施例二和实施例三提供的CSV配置更新方法的流程示意图。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于：共同使用和维护同一份配置文件，客户端和服务端统一更新配置文件，确保双端配置版本的一致性。

本发明涉及的技术术语解释:

请参照图1，本发明提供CSV配置更新方法，包括：

提交CSV格式配置文件至GIT服务器的配置目录；

服务端输出所述配置文件至公共目录；

进一步地，所述CSV格式配置文件的第一行记录各列的描述说明，第二行记录包括id主键的各列的英文名称，且以特定符号标注对应的列对客户端不可见，第三行开始为配置数据。

由上述描述可知，通过统一客户端和服务端配置文件的数据格式，维护同一份配置文件，既能降低配置文件版本不兼容的概率，又能减少策划人员制作和管理配置文件的时间，从而提高开发效率。另外，上述数据格式的配置，又有利于后续的字典结构转化，以此提高配置更新效率。

进一步地，所述服务端解析所述CSV格式配置文件为字典结构的配置文件，具体为：

服务端跳过所述CSV格式配置文件的第一行，读取第二行，获取字典结构的id主键；

读取第三行之后的内容，获取字典结构各id主键的值，得到配置文件。

由上述描述可知，第一行记载的是对于程序交互无用的内容，直接跳过解析，能够提高解析速度；依据预先配置好的数据格式，能快速且准确地完成转换，进一步提高配置文件的更新效率。

进一步地，所述配置文件为JSON格式或XML格式或Protobuf格式。

由上述描述可知，提供多种支持字典结构存储，又对客户端友好的配置文件格式，以此减客户端人员开发与管理配置文件的时间，从而提高开发效率。

进一步地，所述提交CSV格式配置文件至GIT服务器的配置目录，具体为：

提交CSV格式配置文件至GIT服务器后，将触发GIT客户程序；

所述GIT客户程序被触发后拉取所述CSV格式配置文件至GIT服务器的配置目录。

由上述描述可知，GIT服务器具备自动拉取最新CSV配置文件并更新至服务端可读取的本地配置目录功能，为本方案的实现提供了技术支持。

进一步地，所述存储至本地，之后，还包括：

将本地的所述配置文件持久化。

由上述描述可知，将服务端存储的最新版本的配置文件进行持久化，避免丢失。

进一步地，所述输出所述配置文件至公共目录，具体为：

过滤掉配置文件中对客户端不可见的属性后，存储至公共目录。

由上述描述可知，在更新至后续客户端获取最新配置文件的公共目录之前，能够自动过滤掉客户端不可见的属性，在统一配置文件的基础上，又兼容了客户端配置文件的差异性。

进一步地，所述服务端输出所述配置文件至公共目录，之前，还包括：

对所述配置文件进行签名；

以签名值作为所述配置文件的文件名。

由上述描述可知，通过签名，实现了对输出至公共目录的配置文件的安全保护，又能以签名值作为配置文件对外公开的唯一标识，一举两得。

进一步地，所述服务端启动HTTP服务后，输出本地的配置文件的版本号至客户端，使客户端判断接收到的版本号与本地的配置文件的版本号是否一致；若不一致，则从公共目录获取所述配置文件，具体为：

服务端启动HTTP服务；

HTTP服务启动后，访问服务端本地存储的配置文件，输出其版本号至客户端；

客户端接收所述版本号后，获取本地的配置文件的版本号；

客户端判断接收到的版本号与本地获取的版本号是否一致；

若不一致，则依据接收到的版本号请求服务端从公共目录获取对应的配置文件。

由上述描述可知，基于服务端的HTTP服务，实现了对客户端配置文件的版本检查，并能够及时地更新客户端的配置文件，实现了双端配置文件版本的统一。

本发明提供的另一个技术方案为：

一种计算机可读存储介质，其上存储有计算机程序，所述程序在被处理器执行时，能够实现下述CSV配置更新方法所包含的步骤：

提交CSV格式配置文件至GIT服务器的配置目录；

服务端输出所述配置文件至公共目录；

进一步地，所述配置文件为JSON格式或XML格式或Protobuf格式。

提交CSV格式配置文件至GIT服务器后，将触发GIT客户程序；

进一步地，所述存储至本地，之后，还包括：

将本地的所述配置文件持久化。

进一步地，所述输出所述配置文件至公共目录，具体为：

对所述配置文件进行签名；

以签名值作为所述配置文件的文件名。

服务端启动HTTP服务；

客户端接收所述版本号后，获取本地的配置文件的版本号；

客户端判断接收到的版本号与本地获取的版本号是否一致；

从上述描述可知，对应本领域普通技术人员可以理解实现上述技术方案中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来实现的，所述的程序可存储于一计算机可读取的存储介质中，该程序在执行时，可包括如上述各方法的流程，且所述流程被执行后，同样能够获取对应各方法的有益效果。

其中，所述的存储介质可以是磁盘、光碟、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

实施例一

请参照图2，本实施例提供一种CSV配置更新方法，方法包括：

S1：配置CSV格式配置文件，并提交至GIT服务器；

S2：GIT服务器的GIT客户程序更新CSV配置文件至配置目录，即config目录；

S3：服务端监控config目录文件变化，有变化后则触发重新加载CSV配置文件；

S4：服务端解析加载的CSV配置文件，将其转换为字典结构的配置文件，并存储在本地缓存的字典对象中；所述配置文件可以是JSON格式、XML或Protobuf等其他支持字典结构的格式。优选JSON格式，其具备通用性。

S5：将字典对象持久化，并输出配置文件至公共目录，即public目录下。

S6：服务端提供HTTP服务，支持访问本地的配置文件和从public目录下载配置文件。

S7：服务端通过HTTP服务输出本地最新的配置文件的版本号至客户端，客户端据此判断自身是否需要进行配置更新，若需要，则通过访问HTTP服务，获取最新版本的配置文件。

实施例二

请参照图2，本实施例在实施例一的基础上做进一步限定，所述方法具体包括：

S1：配置CSV格式配置文件；

其中，第一行表示列的描述说明；第二行表示列的英文名称，且必须包含id主键列，名称以“_”下划线开始的表示对客户端不开放的列(不可见)；从第三行开始表示实现配置数据，每一类配置作为单独一份文件(同数据库的一张表)，配置数据类型如：物品(item)、地图(map)等，它们的配置单独存储为一份的csv文件，如：item.csv、map.csv；与数据库表结构类似：如item表、map表。

策划制作好数值配置后，将CSV格式配置文件提交至GIT服务器。

S2：提交后会触发服务端位于服务器中的GIT客户程序拉取最新CSV格式配置文件，并同步到服务端可读取的本地config目录；

S3：服务端程序运行时，会实时监控config目录下所有文件的变化，当GIT客户端程序拉取到新文件时，将会引发服务端程序重新读取CSV格式配置文件；

S4：服务端程序从config目录读取最新CSV格式配置文件，开始解析CSV格式配置内容为JSON格式配置文件。

CSV配置也可以解析成别的格式，如XML或Protobuf等支持字典结构存储的格式，在转换时CSV配置文件的每一行以键值对的方式存储即可。具体的，针对不同的开发语言如JAVA、C#、PYTHON等，统一采用以字典结构存储，它们原生支持字典结构；同时也方便以主键ID列来获得对应行的记录，每行中可以通过列名来获得各个字段的值。

需要说明的是，字典结构存储获取数据的效率接近为0的消耗，虽然其占用内存空间相对于数组存储比较多，但是针对于配置类型的数据，它的增长率比较可控，占用的内存的成本在可接受范围。

通过提供对客户端友好的多种格式，即可以与客户端友好地进行数据交互，也可以过虑些敏感类型的数据信息给客户端，增加数据安全性；还可以实现自动化升级新配置，减少客户端人员的开发与管理配置文件的时间，进而提高开发效率。

本实施例以转换为JSON格式为例进行说明，因为采用JSON格式是通用的做法，目前应用的项目是以NODEJS语言编写，采用JSON结构表示一个对象数据。

具体的解析过程为：

CSV配置的第一行记录表示列的描述说明，将会被跳过不处理，这是因为列的描述，对于程序之间的交互是没有具体用途的，描述比较多时反而占用内存造成浪费，它只针对于策划人员制作配置数据时具有比较友好的提示作用，但CSV配置必须记录的原因是如果只保留第二行是英文表示的列名，将比较不方便理解具体列的含义。

读取第二行(列名)作为JSON属性名；从第三行开始，行数据作为JSON属性的值，每一行产生一个JSON对象，并将每个JSON对象添加到在本地缓存的字典对象中，以JSON对象的id作为字典的键值。

S5：解析完CSV格式配置文件后，将字典对象持久化；

S6：过滤对客户端不可见的属性名后，将配置文件输出至public目录；

对照上述CVS格式配置文件的配置，若JSON对象属性名以“_”下划线开始，此属性将被排除不会输出。

S7：对JSON配置文件进行签名，输出签名后的JSON配置文件时，以签名值作为文件名，存储在public目录下；同时会将签名值作为JSON配置文件的版本号，也一并存储在本地缓存的字典版本对象中。

采用签名加密的主要用途为版本管理，同时也能保护输出至public目录的配置文件的数据安全。可以采用SHA1签名或者MD5签名加密方式，它们签名的效率比较高，能将大量的内容数据加密压缩成比较固定长度的字符串；当配置内容数据发生变化时，如增加空格或空行，它都会产生新的版本，但如果只是改变了CSV文件的修改时间或创建时间属性，它是不会产生新的版本的；由于CSV配置文件需要在不同人员的机器之前传递交互来审查，保证配置文件的正确性，因而CSV文件的修改时间或创建时间属性将频繁发生变化，由此，上述两种签名方式正好符合需求。另外，对配置文件内容签名加密的方式是一种自动化的版本控制方式，不需要人员介入管理提升版本号，能够降低版本号发生出错概率。

此处以public目录命名，是表示公开的静态文件存储位置，只是个约定规范，也可以采用static命名。

S8：服务端程序提供HTTP服务，它提供访问public目录的权限，因此可以访问或下载JSON配置文件。

生产环境中可以采用CDN访问方式，配置CDN站的源地址指向到此HTTP服务地址，加速JSON配置文件的访问效率；

S9：服务端程序通过上一步骤提供的检查JSON配置版本的HTTP服务，访问服务端本地缓存的字典版本对象，将当前最新配置的版本号输出给客户端；客户端程序获得此版本号，通过读取客户端的本地字典版本文件(config_version.json)，判断本地字典版本文件中的版本号与服务端获取的版本号是否一致，若不一致则通过服务端输出的最新的版本号，向服务端获取相应的JSON配置文件(具体通过访问JSON配置文件接口从public目录下载)，存储在自身config目录下，同时更新本地字典版本文件中的版本号，完成客户端的配置更新。

实施例三

本实施例对应实施例一或实施例二，提供一具体运用场景：

1、制作CSV格式配置文件。

如物品CSV配置文件(文件名：item.csv)：

编号,物品名称,物品类型,点券价格,金币价格,最大堆叠数量,物品时效计算类型,物品时效时间；

id,name,type,emoney,money,max_num,_expire_type,_expire_time；

101,生命药水,1,0,100,99,0,0；

102,能量药水,1,0,200,99,0,0；

201,掘金道具,2,0,600,1,1,3600。

其中的id将作为缓存字典的键值，_expire_type与_expire_time列表示对客户端不可见的列，它的属性值将被过虑掉，不会输出JSON配置文件；

2、将item.csv配置文件放到config目录下，并提交到GIT服务器；

3、在服务端程序所在的服务器上的config目录下，执行GIT客户端拉取最新的item.csv配置文件；

其中，服务端程序目录结构如下：

-/服务端程序根目录

|--/config

|--|--/item.csv

|--/public

|--|--/item/2bf0fb2ce8b12226574f68553f261423fb48a1dc.json。

4、读取item.csv配置文件，并转换为JSON格式存储在本地缓存中，本地缓存的结构如下所示：

在服务端程序本地缓存的字典对象中，_expire_type与_expire_time列是可见的，它只是针对客户端不可见。

5、将服务端程序本地缓存的字典对象持久化，并输出到public目录下；

具体而言，该步骤包括：

5.1对应步骤3的目录结构，输出时会过滤对客户端不可见的属性名；

输出后的JSON配置内容如下：

5.2对过滤后的JSON配置内容以SHA1签名后，得到签名值“2bf0fb2ce8b12226574f68553f261423fb48a1dc”，以此签名值作为文件名保存至public/item/2bf0fb2ce8b12226574f68553f261423fb48a1dc.json，即public目录下。

6、服务端程序提供HTTP服务访问JSON配置文件，如访问地址：

http://conf.abc.com/public/item/2bf0fb2ce8b12226574f68553f261423fb48a1dc.j son

生产环境则配置CDN方式:

http://cdn-conf.abc.com/public/item/2bf0fb2ce8b12226574f68553f261423fb48a1dc.json。

如果访问cdn-conf.abc.com网站没有找到2bf0fb2ce8b12226574f68553f261423fb48a1dc.json文件，它会转向到conf.abc.com网站获取文件，并在各个cdn的子节点缓存提供高效访问；

7、客户端程序首先访问服务端程序检查JSON配置版本的HTTP服务，访问地址如：

http://conf.abc.com/route/conf/confHandler/check

返回格式：

{

"item":"2bf0fb2ce8b12226574f68553f261423fb48a1dc"

}

接着，客户端程序读取本地字典版本文件config_version.json，它的内容如下：

{

"item":""

}

若客户端本地字典版本文件中的item版本号如上为空，或者是与服务端程序检查获取最新的item版本号不一致，将通过步骤6的方式去下载获得最新的item配置文件，同时更新本地字典版本文件中的item版本号，更新后的字典版本文件如下：

{

"item":"2bf0fb2ce8b12226574f68553f261423fb48a1dc"

}

最后，客户端本地config目录下可以找到items配置文件(2bf0fb2ce8b12226574f68553f261423fb48a1dc.json)；

客户端目录结构如下：

-/客户端程序根目录

|--/config_version.json

|--/config

|--|--/item/2bf0fb2ce8b12226574f68553f261423fb48a1dc.json。

实施例四

本实施例对应实施例一至实施例三，提供一种计算机可读存储介质，其上存储有计算机程序，所述程序在被处理器执行时，能够实现上述实施例一至实施例三任意一项所述的CSV配置更新方法所包含的步骤。具体的步骤内容在此不进行复述，详情请参阅实施例一至实施例三的记载。

综上所述，本发明提供的CSV配置更新方法、存储介质，不仅能够实现客户端与服务端配置文件格式数据的统一，共同维护同一份配置文件的版本管理；而且能够实现双端配置文件版本更新的一致性，确保游戏运行正常；进一步地，还能兼容配置文件对应客户端的差异性，更好地满足实际要求；再进一步地，同时提供对客户端友好的多格式配置文件，有利于与客户端友好地进行数据交互；另外，本发明还具有易于实施且成本不高、实用性强等优点。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims

1.CSV配置更新方法，其特征在于，包括：

提交CSV格式配置文件至GIT服务器的配置目录；

服务端输出所述配置文件至公共目录；

服务端启动HTTP服务后，输出本地的配置文件的版本号至客户端，使客户端判断接收到的版本号与本地的配置文件的版本号是否一致；若不一致，则从公共目录获取所述配置文件；

所述CSV格式配置文件的第一行记录各列的描述说明，第二行记录包括id主键的各列的英文名称，且以特定符号标注对应的列对客户端不可见，第三行开始为配置数据。

2.如权利要求1所述的CSV配置更新方法，其特征在于，所述服务端解析所述CSV格式配置文件为字典结构的配置文件，具体为：

3.如权利要求1所述的CSV配置更新方法，其特征在于，所述配置文件为JSON格式或XML格式或Protobuf格式。

4.如权利要求1所述的CSV配置更新方法，其特征在于，所述提交CSV格式配置文件至GIT服务器的配置目录，具体为：

提交CSV格式配置文件至GIT服务器后，将触发GIT客户程序；

5.如权利要求1所述的CSV配置更新方法，其特征在于，所述存储至本地，之后，还包括：

将本地的所述配置文件持久化。

6.如权利要求1所述的CSV配置更新方法，其特征在于，所述输出所述配置文件至公共目录，具体为：

7.如权利要求1所述的CSV配置更新方法，其特征在于，所述服务端输出所述配置文件至公共目录，之前，还包括：

对所述配置文件进行签名；

以签名值作为所述配置文件的文件名。

8.如权利要求7所述的CSV配置更新方法，其特征在于，所述服务端启动HTTP服务后，输出本地的配置文件的版本号至客户端，使客户端判断接收到的版本号与本地的配置文件的版本号是否一致；若不一致，则从公共目录获取所述配置文件，具体为：

服务端启动HTTP服务；

客户端接收所述版本号后，获取本地的配置文件的版本号；

客户端判断接收到的版本号与本地获取的版本号是否一致；

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序在被处理器执行时，能够实现上述权利要求1-8任意一项所述的CSV配置更新方法所包含的步骤。