本申请要求在2021年9月14日提交新加坡知识产权局、申请号为10202110093V的新加坡专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及存储技术，涉及但不限于一种配置更新方法及装置、设备、存储介质。
背景技术
在一些游戏场景中，为了满足对不同游戏桌上的游戏币的分析、识别的需求，应用程序需要能够读取不同游戏桌的配置信息，包括游戏桌的桌面布局和游戏桌配备的相机的参数等。
这些配置信息通常具备以下特点：包含的参数多，所以储存参数的文件大；不同的游戏桌需要完全不同的参数，所以需要的配置文件数量众多、更新频繁。
因此，导致更新配置信息(即配置文件)缓慢，并且容易因人为因素造成错误，并最终导致游戏桌上的游戏币不能被正确的识别。
技术实现要素：
有鉴于此，本申请实施例提供一种配置更新方法及装置、设备、存储介质。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供一种配置更新方法，应用于边端设备，所述方法包括：获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件。
通过上述方式，能够将云端存储的配置文件版本与本地存储的配置文件版本进行比对，从而缩短游戏区域对应的相关参数的更新时间，减少手动更新可能出现的人为错误。
在一些实施例中，所述方法还包括：在确定所述边端设备上不存在所述配置文件的情况下，向所述云端服务器发送下载请求；所述下载请求指示：下载位于所述云端服务器上的所述配置文件；接收所述云端服务器发送的所述配置文件，将所述配置文件存储在所述边端设备上。
通过上述方式，能够在本地不存在配置文件的情况下，从云端服务器下载最新版本的配置文件存储在本地，供相关的程序、设备使用，从而解决本地设备出现故障时因缺少参数而不能运行的问题，增加系统的可用性。
在一些实施例中，所述获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息，包括：响应于所述边端设备上特定服务的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；或，响应于所述边端设备的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息。
通过上述方式，能够在边端设备启动时，或者边端设备上的特定服务启动时，将云端存储的配置文件版本与本地存储的配置文件版本进行比对，从而缩短游戏区域对应的相关参数的更新时间，减少手动更新可能出现的人为错误。
在一些实施例中，所述基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息，包括：基于所述标识信息，通过特定接口获取位于云端服务器上的配置文件的第二版本信息；其中，所述特定接口至少包括以下接口之一：RESTful接口、gRPC接口；对应地，所述方法还包括：在无法访问所述特定接口的情况下，利用所述第一版本信息的配置文件对所述特定服务进行处理。
通过上述方式，能够利用特定接口去获取云端服务器上配置文件的版本信息，同时，在云端服务器无法使用的情况下，利用本地存储的配置文件来对特定服务进行处理。
在一些实施例中，所述利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件之后，所述方法还包括：将所述配置文件的第二版本信息存储在所述配置文件中；或，将所述配置文件的第二版本信息与所述配置文件的标识信息进行关联，得到所述配置文件的关联信息；将所述关联信息存储在版本号文件中。
通过上述方式，能够选择将所有版本号集中缓存至一个单独的文件的方式，也可以选择分开缓存的方式，来实现版本号的存储。
在一些实施例中，所述方法还包括：确定位于所述边端设备上的每一配置文件的最后一次的被使用时间；按所述被使用时间，对位于所述边端设备上的配置文件进行排序，得到第一排序结果；在位于所述边端设备上的配置文件对应的游戏区域的数量超过第一预设数量的情况下，按所述第一排序结果对位于所述边端设备上的配置文件进行删除。
通过上述方式，能够节省本地存储空间，利用使用时间对缓存下来的配置文件进行选择性的删除。
在一些实施例中，所述方法还包括：确定位于所述边端设备上的每一配置文件的被使用次数；按所述被使用次数，对位于所述边端设备上的配置文件进行排序，得到第二排序结果；在位于所述边端设备上的配置文件对应的游戏区域的数量超过第二预设数量的情况下，按所述第二排序结果对位于所述边端设备上的配置文件进行删除。
通过上述方式，能够节省本地存储空间，利用使用次数对缓存下来的配置文件进行选择性的删除。
第二方面，本申请实施例提供一种配置更新装置，所述装置包括：第一版本获取单元，用于获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；第二版本获取单元，用于基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；文件获取单元，用于在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；更新单元，用于利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件。
第三方面，本申请实施例提供一种边端设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。
第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。
本申请实施例提供一种配置更新方法及装置、设备、存储介质，通过获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件，如此，能够将云端存储的配置文件版本与本地存储的配置文件版本进行比对，从而缩短游戏区域对应的相关参数的更新时间，减少手动更新可能出现的人为错误。
附图说明
图1A为本申请实施例配置更新方法对应的系统架构示意图；
图1B为本申请实施例配置更新方法的实现流程示意图一；
图2为本申请实施例配置更新方法的实现流程示意图二；
图3为本申请实施例配置更新方法的实现流程示意图三；
图4为本申请实施例配置更新方法的实现流程示意图四；
图5为本申请实施例配置更新装置的组成结构示意图；
图6为本申请实施例边端设备的一种硬件实体示意图。
具体实施方式
下面结合附图和实施例对本申请的技术方案进一步详细阐述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本申请的说明，其本身没有特定的意义。因此，“模块”、“部件”或“单元”可以混合地使用。
需要指出，本申请实施例所涉及的术语“第一\\第二\\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\\第二\\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
图1A为本申请实施例配置更新方法对应的系统架构示意图，如图1A所示，该系统架构可以包括：云端服务器101、第一边端设备102、第二边端设备103以及第三边端设备104。
云端服务器101可以分别与第一边端设备102、第二边端设备103以及第三边端设备104通信。在实施过程中，云端服务器101与任一边端设备在通信的过程中，云端服务器101可以采用有线通信方式和/或无线通信方式与任一边端设备进行通信。其中，第一边端设备102可以对第一游戏桌1021上的游戏币等进行分析识别，第二边端设备103可以对第二游戏桌1031上的游戏牌等进行分析识别，第三边端设备104可以对第三游戏桌1041上的游戏币等进行分析识别。进而，所述第一边端设备102需要获取第一游戏桌1021的配置信息(包括第一图像采集装置1022采集的所述第一游戏桌1021的桌面布局，以及所述第一图像采集装置1022的参数)，所述第二边端设备103需要获取第二游戏桌1031的配置信息(包括第二图像采集装置1032采集的所述第二游戏桌1031的桌面布局，以及所述第二图像采集装置1032的参数)，所述第三边端设备104需要获取第三游戏桌1041的配置信息(包括第三图像采集装置1042采集的所述第三游戏桌1041的桌面布局，以及所述第三图像采集装置1042的参数)。并且，上述图像采集装置可以为相机、摄像头等，一个游戏桌对应至少一个图像采集装置，例如，不同游戏桌的不同方向对应多个摄像头，负责拍摄游戏桌的桌面布局图像。
本申请实施例不限于此，云端服务器可以与其它数量的边端设备进行通信，其它数量例如是1个、2个或者大于或等于3个的整数等。例如，其它数量可以是一个娱乐场或多个娱乐场中所有的游戏桌的数量；其中，所有的游戏桌中的一个游戏桌可以对应一个边端设备，也可以是多个游戏桌对应一个边端设备，本申请实施例对此并不做限制。
在一些实施方式中，任一边端设备可以直接与云端服务器进行通信。在另一些实施方式中，任一边端设备可以通过娱乐场中的服务器与云端服务器进行通信，从而娱乐场中的服务器可以实现：对云端服务器与任一边端设备之间的通信数据的监控。
基于此，本申请实施例提供一种配置更新方法，该方法应用于所述边端设备，该方法所实现的功能可以通过所述边端设备中的处理器调用程序代码来实现，当然程序代码可以保存在所述边端设备的存储介质中。图1B为本申请实施例配置更新方法的实现流程示意图一，如图1B所示，所述方法包括：
步骤S101、获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
这里，所述边端设备可以为各种类型的具有信息处理能力的设备，例如手机、PDA(Personal Digital Assistant，个人数字助理)、平板电脑、导航仪、一体机等。所述边端设备可以为连接云端服务器和游戏桌对应的相机的桥梁设备，可以将相机拍摄的图片经过AI(Artificial Intelligence，人工智能)处理后上传到云端。
本申请实施例中，同一配置文件，具有唯一的标识信息，以及不同的版本信息。例如，配置文件A中包括位于某一方向的相机A所拍摄的游戏区域A的图像，以及所述相机A的参数，则所述配置文件A具有唯一的标识信息，在第一时刻所述配置文件A具有第一版本信息，第二时刻所述游戏区域A上的游戏币、游戏牌、或者所述游戏区域A的布局发生了改变、或者所述相机A的参数发生了变化，则所述第二时刻所述配置文件A具有第二版本信息。所述版本信息可以用版本号表示，也可以用配置文件的时间戳信息来表示，本申请实施例对此并不做限制。
当然，所述游戏区域可以是游戏桌上的某个区域，也可以是游戏桌上的全部区域。可以在不同游戏桌的不同方向设置多个摄像头，来拍摄游戏桌的桌面布局图像，此时，每个摄像头拍摄的游戏桌的桌面布局图像以及相机参数都不相同。可以按任意方式，将同一游戏桌的布局图像及相机参数存储在一个或多个配置文件中。
在一些实施例中，可以从所述待更新的配置文件中获取所述配置文件的第一版本信息(即所述第一版本信息可以存储在所述配置文件中)，也可以从特定的版本号文件中获取所述配置文件的第一版本信息，即所述配置文件的标识信息和对应的第一版本信息以键值的方式存储在所述特定的版本号文件中。
步骤S102、基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；
这里，获取的边端设备上的配置文件和获取的位于云端服务器上的配置文件具有相同的标识信息，版本信息可能相同也可能不同。
步骤S103、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
这里，如果位于云端服务器上的配置文件的版本高于位于边端设备上的配置文件的版本，即位于云端服务器上的配置文件的版本较新，则下载位于所述云端服务器上的配置文件，以更新本地的配置文件，如此，能够将云端存储的配置文件版本与本地存储的配置文件版本进行比对，从而缩短游戏区域对应的相关参数的更新时间，减少手动更新可能出现的人为错误。
步骤S104、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件。
在一些实施例中，所述步骤S104、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件之后，所述方法还包括：将所述配置文件的第二版本信息存储在所述配置文件中。
这里，在利用云端服务器存储的配置文件更新边端设备上的配置文件后，可以将更新后的配置文件的版本信息直接存储在所述配置文件中。
在一些实施例中，所述步骤S104、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件之后，所述方法还包括：
步骤S11、将所述配置文件的第二版本信息与所述配置文件的标识信息进行关联，得到所述配置文件的关联信息；
步骤S12、将所述关联信息存储在版本号文件中。
这里，在利用云端服务器存储的配置文件更新边端设备上的配置文件后，可以将多个更新后的配置文件的版本信息与其对应的配置文件的标识信息进行关联，得到多个关联信息，然后将所述多个关联信息存储在专门的版本号文件中。
基于前述的实施例，本申请实施例再提供一种配置更新方法，该方法应用于所述边端设备，所述方法包括：
步骤S111、获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
步骤S112、基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；
步骤S113、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
步骤S114、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件；
步骤S115、在确定所述边端设备上不存在所述配置文件的情况下，向所述云端服务器发送下载请求；所述下载请求指示：下载位于所述云端服务器上的所述配置文件；
这里，如果所述边端设备上不存在所述配置文件，无法进行比对，则直接下载位于云端服务器上的配置文件到本地进行存储，供相关的程序、设备使用，从而解决本地设备出现故障时因缺少参数而不能运行的问题，增加系统的可用性。
步骤S116、接收所述云端服务器发送的所述配置文件，将所述配置文件存储在所述边端设备上。
在一些实施例中，所述步骤S111、获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息，包括：响应于所述边端设备上特定服务的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息。
在一些实施例中，所述步骤S111、获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息，包括：响应于所述边端设备的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息。
基于前述的实施例，本申请实施例再提供一种配置更新方法，该方法应用于所述边端设备，所述方法包括：
步骤S121、响应于所述边端设备上特定服务的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
这里，可以在边端设备上的特定服务开启时，或者边端设备启动时，将云端存储的配置文件版本与本地存储的配置文件版本进行比对，从而缩短游戏区域对应的相关参数的更新时间，减少手动更新可能出现的人为错误。
步骤S122、基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；
步骤S123、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
步骤S124、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件；
步骤S125、利用位于所述边端设备上的配置文件对所述特定服务进行处理。
这里，在利用云端服务器上的配置文件更新位于本地的配置文件后，可以利用更新后的配置文件对所述特定服务进行处理。
基于前述的实施例，本申请实施例再提供一种配置更新方法，该方法应用于所述边端设备，图2为本申请实施例配置更新方法的实现流程示意图二，如图2所示，所述方法包括：
步骤S201、响应于所述边端设备上特定服务的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
步骤S202、基于所述标识信息，通过特定接口获取位于云端服务器上的配置文件的第二版本信息；其中，所述特定接口至少包括以下接口之一：RESTful接口、gRPC接口；
这里，RESTful是一种网络应用程序的设计风格和开发方式，基于HTTP(Hyper Text Transfer Protocol，超文本传输协议)，可以使用XML(Extensible Markup Language，可扩展标记语言)格式定义或JSON(JavaScript Object Notation，JS对象简谱)格式定义。RESTful适用于移动互联网厂商作为业务接口的场景，实现第三方调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。gRPC是一款语言中立、平台中立、开源的远程过程调用系统。在gRPC里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法，能够更容易地创建分布式应用和服务。如此，本申请实施例中可以利用特定接口来获取云端配置文件的版本信息。
步骤S203、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
步骤S204、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件；
步骤S205、在无法访问所述特定接口的情况下，利用所述第一版本信息的配置文件对所述特定服务进行处理。
这里，在云端服务器无法使用的情况下，利用本地存储的配置文件来对特定服务进行处理。
基于前述的实施例，本申请实施例再提供一种配置更新方法，该方法应用于所述边端设备，所述方法包括：
步骤S211、响应于所述边端设备上特定服务的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
步骤S212、基于所述标识信息，通过特定接口获取位于云端服务器上的配置文件的第二版本信息；其中，所述特定接口至少包括以下接口之一：RESTful接口、gRPC接口；
步骤S213、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
步骤S214、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件；
步骤S215、将所述配置文件的第二版本信息存储在所述配置文件中；
这里，可以选择执行所述步骤S215，也可以选择执行所述步骤S216至所述步骤S217，来实现版本号的存储。其中，所述步骤S215为分开缓存的方式，所述步骤S216至所述步骤S217为将所述版本号集中缓存至一个单独的文件的方式。
步骤S216、将所述配置文件的第二版本信息与所述配置文件的标识信息进行关联，得到所述配置文件的关联信息；
步骤S217、将所述关联信息存储在版本号文件中。
步骤S218、在无法访问所述特定接口的情况下，利用所述第一版本信息的配置文件对所述特定服务进行处理。
基于前述的实施例，本申请实施例再提供一种配置更新方法，该方法应用于所述边端设备，图3为本申请实施例配置更新方法的实现流程示意图三，如图3所示，所述方法包括：
步骤S301、获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
步骤S302、基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；
步骤S303、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
步骤S304、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件；
步骤S305、确定位于所述边端设备上的每一配置文件的最后一次的被使用时间；
这里，可以设置为将所述配置文件的最后一次的被使用时间存储在所述配置文件中，或者将所述配置文件的最后一次的被使用时间与所述配置文件的标识信息进行关联，将关联信息存储到一个特定文件中。
步骤S306、按所述被使用时间，对位于所述边端设备上的配置文件进行排序，得到第一排序结果；
这里，可以按被使用时间从前到后(例如被使用时间为2010年、2012年、2015年、2021年)对位于所述边端设备上的配置文件进行排序，然后根据排序结果，删除长时间未使用的配置文件，从而节省本地存储空间。
步骤S307、在位于所述边端设备上的配置文件对应的游戏区域的数量超过第一预设数量的情况下，按所述第一排序结果对位于所述边端设备上的配置文件进行删除。
基于前述的实施例，本申请实施例再提供一种配置更新方法，该方法应用于所述边端设备，所述方法包括：
步骤S311、获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
步骤S312、基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；
步骤S313、在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
步骤S314、利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件；
步骤S315、确定位于所述边端设备上的每一配置文件的被使用次数；
步骤S316、按所述被使用次数，对位于所述边端设备上的配置文件进行排序，得到第二排序结果；
这里，可以按被使用次数从少到多(例如被使用次数为20次、30次、50次、100次)对位于所述边端设备上的配置文件进行排序，然后根据排序结果，删除使用次数少的配置文件，从而节省本地存储空间。
步骤S317、在位于所述边端设备上的配置文件对应的游戏区域的数量超过第二预设数量的情况下，按所述第二排序结果对位于所述边端设备上的配置文件进行删除。
目前，在娱乐游戏等场景中，为了满足对不同游戏桌上的游戏币、游戏牌等元素的识别、分析的需求，应用程序需要能够读取不同游戏桌的配置信息，包括游戏桌的桌面布局、游戏桌配备的相机的参数等。此类配置信息对应的配置文件具备以下特点：
1)参数多，所以储存参数的文件大。2)不同游戏桌需要完全不同的参数，所以需要的配置文件数量众多。3)参数更新频繁。
由于相关的参数存在以上的特点，所以导致更新参数时缓慢，并且容易因人为因素造成错误，并最终导致游戏桌上的游戏币、游戏牌等不能被正确的识别。
基于此，本申请实施例提出一种配置更新方法，主要为对游戏场景中不同游戏桌以及其所配备的相机的参数在正常以及故障情况下的本地缓存策略。通过对配置文件进行缓存处理，将缩短配置文件更新时间，减少人工更新的错误率。
首先，可以对于同一配置文件的不同版本设定一个版本号，边端设备通过比对本地已有，或者没有的配置文件来判断是否文件需要更新，如果遇到故障，边端设备将加载本地已有的缓存。
图4为本申请实施例配置更新方法的实现流程示意图四，如图4所示，在正常情况下，本申请实施例提供的配置更新方法，可以通过以下步骤实现：
步骤S401、对每一配置文件的不同版本，设定版本号；
这里，每一配置文件中可以包括至少一个参数，对于同一个配置文件，将会有一个唯一的ID(Identity document，身份标识号)。对于每一个版本的配置文件，将会有一个对应其版本的版本号，并且对于更新的版本，其版本号将会更大。比如，如果当前版本号为1，而配置文件更新后的版本号则为2。当然，还可以以配置文件的时间戳来区分同一配置文件的不同版本。
本申请实施例中，所有配置文件的不同版本会在云端统一管理，并通过HTTP协议被边端设备下载。除此以外，云端服务器也会提供一个RESTful接口供边端设备检查配置文件的最新版本。
步骤S402、当边端设备上的检测程序启动时，程序会首先读取当前游戏桌所需要的一系列配置文件的ID；
步骤S403、程序会逐个通过ID来访问云端服务器提供的接口，以获取所述ID对应的配置文件的最新版本号；
这里，所述接口可以是RESTful接口，也可以是gRPC接口。此接口会返回该ID所对应的配置文件的最新版本号。
步骤S404、当程序接收到所有需要的配置文件的最新版本号时，会将接收到的最新版本号与本地之前缓存的版本号进行比对，得到比对结果；
这里，所述本地而之前的缓存会被集中储存在versions.json的文件中。如果程序能够找到之前缓存的配置文件版本号，会逐一对每个程序所需要的配置文件的缓存版本号以及最新版本号进行比对。
步骤S405、根据所述比对结果，确定是否需要从云端服务器上下载最新的配置文件；
这里，比对配置文件版本号将以最新为准。比如，如果AAA配置文件的缓存版本号为2，而接口返回得到的最新版本号为3，则比对结果为3，得到版本号的比对结果之后，程序会访问步骤S403中的接口尝试下载最新的配置文件。
步骤S406、如果需要则从所述云端服务器上下载最新的配置文件，以更新本地缓存的配置文件。
以上为正常情况下的配置更新策略，如果出现故障，则所述配置更新方法可以通过以下的方式实现：
1)若上述步骤S403中的提供最新版本号的接口出现无法访问的情况，则程序将会跳过以上所有步骤，并使用现有的本地缓存来正常执行。若本地没有缓存过的文件，则程序将无法执行。
2)若上述步骤S404中程序无法找到本地之前缓存的版本号，则会将利用其接收到的最新配置文件版本号创建新的缓存versions.json，并使用新的版本号作为步骤S404中的比对结果。
3)若上述步骤S406中下载最新配置文件失败，则versions.json中的版本号不会产生变动。
当然，在一些实施例中，还可以存在一些替换方案，举例来说，所述替换方案如下：
1)对于同一个配置文件，其版本号未必需要将大小作为判断新旧的标准。任何能够清晰标注版本号新旧的方式，如数字，符号，字母等都可以作为版本号。例如，可以通过配置文件的时间戳信息，作为版本号。
2)提供最新配置文件版本号的接口除RESTful外，还可以利用如gRPC等RPC(Remote Procedure Call，远程过程调用)协议对应的接口；提供最新配置文件下载的接口除HTTP外，还可以利用FTP(File Transfer Protocol，文件传输协议)等协议。
3)可以将每一配置文件的版本号存储在所述配置文件中，也可以将多个配置文件的版本号存储在一个单独的版本号文件中。并且，缓存于本地的所述版本号文件可以为任意文件名，任意格式的文件如yaml，xml等。
4)为节省空间，被缓存在本地的配置文件可以被选择性的删除。删除的标准可以有以下几种：
第一种，只缓存N个不同类型的游戏桌所对应的配置文件，若缓存的游戏桌的类型超过N，则可以删除最后一次使用时间最早的配置文件，所述N为大于等于2的自然数。
第二种，只缓存M个不同类型游戏桌所对应的配置文件。若缓存的游戏桌的类型超过M，则可以删除曾经使用次数最少的配置文件，所述M为大于等于2的自然数。
当然，如上所述，如果需要使用时间或者使用次数等信息，该信息也可以被写入versions.json或者类似的缓存文件当中。
本申请实施例提供的配置更新方法，能够缩短游戏桌及其相机等相关参数的更新时间，并且减少了手动更新游戏桌及其相机等相关参数更新中可能出现的由人为导致的错误。同时，本申请实施例中的配置更新方法解决了在游戏桌出现故障时因缺少参数而不能运行的问题，增加了系统的可用性，使用本方法描述的端上缓存策略来管理游戏桌所需参数，并以此来缩短参数更新时间，减少手动更新过程中可能出现的错误。
基于前述的实施例，本申请实施例提供一种配置更新装置，该装置包括所包括的各单元、以及各单元所包括的各模块、以及各模块所包括的各部件，可以通过生物特征识别设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为CPU(Central Processing Unit，中央处理器)、MPU(Microprocessor Unit，微处理器)、DSP(Digital Signal Processing，数字信号处理器)或FPGA(Field Programmable Gate Array，现场可编程门阵列)等。
图5为本申请实施例配置更新装置的组成结构示意图，如图5所示，所述装置500包括：
第一版本获取单元501，用于获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；所述配置文件中至少包括采集装置采集的游戏区域的图像和所述采集装置的参数；
第二版本获取单元502，用于基于所述标识信息，获取位于云端服务器上的配置文件的第二版本信息；
文件获取单元503，用于在所述第二版本信息高于所述第一版本信息的情况下，从所述云端服务器获取所述第二版本信息的配置文件；
更新单元504，用于利用所述第二版本信息的配置文件更新位于所述边端设备上的所述配置文件。
在一些实施例中，所述装置还包括：
下载单元，用于在确定所述边端设备上不存在所述配置文件的情况下，向所述云端服务器发送下载请求；所述下载请求指示：下载位于所述云端服务器上的所述配置文件；
存储单元，用于接收所述云端服务器发送的所述配置文件，将所述配置文件存储在所述边端设备上。
在一些实施例中，所述第一版本获取单元501，包括：
第一版本获取子单元，用于响应于所述边端设备上特定服务的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息；或，
所述第一版本获取子单元，还用于响应于所述边端设备的开启，获取位于所述边端设备上的待更新的配置文件的标识信息和所述配置文件的第一版本信息。
在一些实施例中，所述第二版本获取单元502，包括：
第二版本获取子单元，用于基于所述标识信息，通过特定接口获取位于云端服务器上的配置文件的第二版本信息；其中，所述特定接口至少包括以下接口之一：RESTful接口、gRPC接口；
对应地，所述装置还包括：
处理单元，用于在无法访问所述特定接口的情况下，利用所述第一版本信息的配置文件对所述特定服务进行处理。
在一些实施例中，所述装置还包括：
第一版本存储单元，用于将所述配置文件的第二版本信息存储在所述配置文件中；或，
关联单元，用于将所述配置文件的第二版本信息与所述配置文件的标识信息进行关联，得到所述配置文件的关联信息；
第二版本存储单元，用于将所述关联信息存储在版本号文件中。
在一些实施例中，所述装置还包括：
时间确定单元，用于确定位于所述边端设备上的每一配置文件的最后一次的被使用时间；
第一排序单元，用于按所述被使用时间，对位于所述边端设备上的配置文件进行排序，得到第一排序结果；
第一删除单元，用于在位于所述边端设备上的配置文件对应的游戏区域的数量超过第一预设数量的情况下，按所述第一排序结果对位于所述边端设备上的配置文件进行删除。
在一些实施例中，所述装置还包括：
次数确定单元，用于确定位于所述边端设备上的每一配置文件的被使用次数；
第二排序单元，用于按所述被使用次数，对位于所述边端设备上的配置文件进行排序，得到第二排序结果；
第二删除单元，用于在位于所述边端设备上的配置文件对应的游戏区域的数量超过第二预设数量的情况下，按所述第二排序结果对位于所述边端设备上的配置文件进行删除。
以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的配置更新方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备(可以是个人计算机、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、ROM(Read Only Memory，只读存储器)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。
对应地，本申请实施例提供一种生物特征识别设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中提供的配置更新方法中的步骤。
对应地，本申请实施例提供一种可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述配置更新方法中的步骤。
这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
需要说明的是，图6为本申请实施例边端设备的一种硬件实体示意图，如图6所示，该边端设备600的硬件实体包括：处理器601、通信接口602和存储器603，其中
处理器601通常控制边端设备600的总体操作。
通信接口602可以使边端设备600通过网络与其他电子设备或服务器通信。
存储器603配置为存储由处理器601可执行的指令和应用，还可以缓存待处理器601以及边端设备600中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过FLASH(闪存)或RAM(Random Access Memory，随机访问存储器)实现。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本申请各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。
本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。
本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。
