CN114780615A - 错误码管理方法及其装置 - Google Patents

Abstract

本申请公开了一种错误码管理方法及其装置，属于计算机技术领域。该错误码管理方法包括：获取用户在客户端的错误码界面输入的错误码信息；在关系型数据库和内存数据库中同步存储错误码信息；在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，客户端用于接入分布式系统的各个子系统；从内存数据库中获取与错误码查询请求对应的目标错误码信息；向客户端发送目标错误码信息。

Description

错误码管理方法及其装置

技术领域

本申请属于计算机技术领域，具体涉及一种错误码管理方法及其装置。

背景技术

错误码是一组数字(或字母与数字的结合)，它会与错误信息建立关联，并且可用来识别Windows及其他程序中的特定问题，对于每一种特定问题，开发人员会定义一个错误码，并且提供描述信息来表示错误码的含义。

相关技术中，在分布式系统场景下，分布式系统中的各个子系统由不同的开发人员来定义错误码，同时各个子系统分别管理各自的错误码，而各个子系统管理错误码的方式不统一，因此无法规范化管理所有错误码。

发明内容

本申请实施例的目的是提供一种错误码管理方法及其装置，能够解决相关技术中各个子系统管理错误码的方式不统一，无法规范化管理所有错误码的问题。

第一方面，本申请实施例提供了一种错误码管理方法，该方法包括：获取用户在客户端的错误码界面输入的错误码信息；在关系型数据库和内存数据库中同步存储错误码信息；在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，客户端用于接入分布式系统的各个子系统；从内存数据库中获取与错误码查询请求对应的目标错误码信息；向客户端发送目标错误码信息。

第二方面，本申请实施例提供了一种错误码管理装置，该装置包括：获取模块，用于获取用户在客户端的错误码界面输入的错误码信息；存储模块，用于在关系型数据库和内存数据库中同步存储错误码信息；接收模块，用于在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，客户端用于接入分布式系统的各个子系统；获取模块，还用于从内存数据库中获取与错误码查询请求对应的目标错误码信息；发送模块，用于向客户端发送目标错误码信息。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序或指令，程序或指令被处理器执行时实现如第一方面的错误码管理方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，该可读存储介质上存储程序或指令，程序或指令被处理器执行时实现如第一方面的错误码管理方法的步骤。

第五方面，本申请实施例提供了一种芯片，该芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如第一方面的错误码管理方法的步骤。

第六方面，本申请实施例提供了一种计算机程序产品，该计算机程序产品被存储在存储介质中，该计算机程序产品被至少一个处理器执行以实现如第一方面所述的错误码管理方法的步骤。

在本申请实施例中，客户端可以提供错误码界面，在该界面可以接收到所有用户的错误码录入操作，即使是负责不同子系统的开发人员，也能够在该界面录入错误码，实现错误码的统一定义。并且，服务端在获取到用户在客户端的错误码界面输入的错误码信息之后，可以在关系型数据库和内存数据库中同步存储错误码信息，避免多个子系统各自存储错误码时的存储方式不一，在服务端实现错误码信息的统一存储。基于此，通过将客户端接入分布式系统的各个子系统，在任意子系统对业务请求处理失败，需要获取错误码信息的场景下，客户端可以感知并向服务端发送错误码查询请求，服务端通过向客户端发送与错误码查询请求对应的目标错误码信息，为子系统提供错误码调用服务。如此，本申请可以在客户端实现错误码信息的统一定义，在服务端实现错误码信息的统一存储以及调用，因此能够保证错误码定义、存储以及调用方式相同，规范化管理所有错误码信息。

附图说明

图1是本申请实施例提供的错误码管理方法的应用场景的示例的架构示意图；

图2是本申请一实施例提供的错误码管理方法的流程示意图；

图3是本申请另一实施例提供的错误码管理方法的流程示意图；

图4是本申请再一实施例提供的错误码管理方法的流程示意图；

图5是本申请再一实施例提供的错误码管理方法的流程示意图；

图6是本申请实施例提供的一种错误码管理装置的结构示意图；

图7是本申请实施例提供的一种电子设备的结构示意图；

图8是本申请实施例的一种电子设备的硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

如背景技术，在分布式系统场景下，分布式系统中的各个子系统由不同的开发人员来定义错误码，同时各个子系统分别管理各自的错误码，而各个子系统管理错误码的方式不统一，因此无法规范化管理所有错误码。

举例来说，分布式系统中包括订单子系统和物流子系统，负责两个子系统的开发人员不同。由于不同开发人员在定义错误码时的定义规则不同，因此不同子系统之间无法统一错误码定义方式，且容易出现错误码重复定义的情况，例如对于同一错误码A，对于订单子系统将其定义为“无法提交订单”，对于物流子系统将其定义为“物流异常”，无法实现错误码的规范化定义，子系统在调用错误码时容易出错。并且，订单子系统和物流子系统分别将各自开发的错误码以代码的形式存储在不同的静态文件中，无法集中存储和规范化管理，且无法动态修改错误码信息，维护成本较高。

针对相关技术中出现的问题，本申请实施例提供了一种错误码管理方法，客户端可以提供错误码界面，在该界面可以接收到所有用户的错误码录入操作，即使是负责不同子系统的开发人员，也能够在该界面录入错误码，实现错误码的统一定义。并且，服务端在获取到用户在客户端的错误码界面输入的错误码信息之后，可以在关系型数据库和内存数据库中同步存储错误码信息，避免多个子系统各自存储错误码时的存储方式不一，在服务端实现错误码信息的统一存储。基于此，通过将客户端接入分布式系统的各个子系统，在任意子系统对业务请求处理失败，需要获取错误码信息的场景下，客户端可以感知并向服务端发送错误码查询请求，服务端通过向客户端发送与错误码查询请求对应的目标错误码信息，为子系统提供错误码调用服务。如此，本申请可以在客户端实现错误码信息的统一定义，在服务端实现错误码信息的统一存储以及调用，因此能够保证错误码定义、存储以及调用方式相同，规范化管理所有错误码信息，解决了相关技术中各个子系统管理错误码的方式不统一，无法规范化管理所有错误码的问题。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的错误码管理方法进行详细地说明。

本申请实施例所提供的错误码管理方法，可以应用于如图1的应用场景中，具体结合图1进行详细说明。

图1为本申请实施例提供的错误码管理方法的应用场景的示例的架构示意图。

如图1所示，该错误码管理方法的架构系统可包括错误码管理系统11和分布式系统12，其中，错误码管理系统包括服务端13和客户端14，分布式系统12包括多个子系统15，客户端14可以接入多个子系统15。

服务端13，用于在获取到错误码信息的情况下，统一存储和管理错误码信息，以实现错误码信息的规范化管理。

客户端14，用于接入分布式系统12的多个子系统15，与服务端13一起为各个子系统15提供错误码调用服务。

子系统15，用于通过服务端13和客户端14调用或查询错误码信息。

需要说明的是，图1仅是一种示例，实际应用中分布式系统12中子系统15数量可以根据具体需求进行设置，本申请在此不做具体限定。

图2是本申请实施例提供的一种错误码管理方法的流程示意图，该错误码管理方法的执行主体可以为服务端。需要说明的是，上述执行主体并不构成对本申请的限定。

如图2所示，本申请实施例提供的错误码管理方法可以包括步骤210-步骤250。

步骤210，获取用户在客户端的错误码界面输入的错误码信息。

具体地，客户端提供的该错误码界面可以用于接收用户输入，该用户输入可以包括错误码录入操作和错误码定义操作，客户端在接收到用户输入的错误信息后，可以将错误码信息上传至服务端，因此服务端可以获取到用户在客户端输入的错误码信息。

需要说明的是，即使是负责不同子系统的开发人员，也能够在该错误码界面通过用户输入定义错误码，由于同一错误码界面的错误码定义规则一致，因此通过该错误码界面可以实现错误码的统一定义。

步骤220，在关系型数据库和内存数据库中同步存储错误码信息。

步骤230，在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，客户端用于接入分布式系统的各个子系统。

步骤240，从内存数据库中获取与错误码查询请求对应的目标错误码信息。

具体地，服务端从内存数据库存储的所有错误码信息中，查询并获取与错误码查询请求对应的目标错误码信息。

步骤250，向客户端发送目标错误码信息。

具体地，服务端向客户端发送目标错误码信息，以使客户端向接入的子系统返回目标错误码信息，为子系统提供错误码调用服务。

本申请实施例提供的错误码管理方法，客户端可以提供错误码界面，在该界面可以接收到所有用户的错误码录入操作，即使是负责不同子系统的开发人员，也能够在该界面录入错误码，实现错误码的统一定义。并且，服务端在获取到用户在客户端的错误码界面输入的错误码信息之后，可以在关系型数据库和内存数据库中同步存储错误码信息，避免多个子系统各自存储错误码时的存储方式不一，在服务端实现错误码信息的统一存储。基于此，通过将客户端接入分布式系统的各个子系统，在任意子系统对业务请求处理失败，需要获取错误码信息的场景下，客户端可以感知并向服务端发送错误码查询请求，服务端通过向客户端发送与错误码查询请求对应的目标错误码信息，为子系统提供错误码调用服务。如此，本申请可以在客户端实现错误码信息的统一定义，在服务端实现错误码信息的统一存储以及调用，因此能够保证错误码定义、存储以及调用方式相同，规范化管理所有错误码信息。

下面结合实施例，详细说明上述步骤210-步骤250的具体实现方式。

涉及步骤210，获取用户在客户端的错误码界面输入的错误码信息。

在本申请的一些实施例中，为了保证错误码的规范性，避免子系统调用错误码时出错，在步骤210之前，该方法还包括下述步骤：获取用户在客户端的错误码界面输入的第一错误码；在内存数据库中检索到第一错误码的情况下，输出第一提示信息，第一提示信息用于提示用户第一错误码重复录入；在第一错误码满足预设错误码条件的情况下，输出第二提示信息，第二提示信息用于提示用户第一错误码不合规。

其中，错误码界面可以对应第一错误码定义规则，预设错误码条件可以包括第一错误码符合第二错误码定义规则，第二错误码定义规则为除第一错误码定义规则以外的错误码定义规则。

在一个实施例中，错误码定义规则可以包括但不限于：基于大写英文全称定义、基于大写英文简称定义、基于小写英文全称定义、基于小写英文简称定义、基于阿拉伯数字定义、基于英文和阿拉伯数字混合定义。

示例性地，若第一错误码定义规则为基于阿拉伯数字定义，则除基于阿拉伯数字定义以外的错误码定义规则均为第二错误码定义规则，在用户输入的第一错误码符合基于大写英文简称定义的情况下，确定第一错误码符合第二错误码定义规则，满足预设错误码条件，因此服务端可以输出“该错误码定义不合规”的提示信息，以提示用户进行修改，保证在错误码界面录入的所有错误码均符合同一定义规则。

在本申请实施例中，服务端在获取到用户在客户端的错误码界面输入的第一错误码的情况下，可以对其进行检索和校验，通过在内存数据库中检索第一错误码，能够避免错误码的重复录入和重复定义，保证每个错误码具有唯一定义，避免子系统调用错误码时出错；通过校验第一错误码是否满足预设错误码条件，可以保证在错误码界面录入的所有错误码均符合界面的同一定义规则，保证错误码的录入规范性和定义规范性。同时，用户在错误码录入界面可以直接手动录入和定义第一错误码，无需通过开发代码的形式定义错误码，因此能够缓解子系统中管理错误码的代码急剧膨胀的现象。

在本申请的一些实施例中，该方法还可以包括：客户端接收用户对错误码界面的第一输入；响应于第一输入，在内存数据库中对输入的第二错误码进行检索；在内存数据库中检索到第二错误码的情况下，显示第二错误码的编辑界面；基于用户在编辑界面的编辑操作，更新第二错误码的错误码信息。

其中，第二错误码的错误码信息可以包括第二错误码及其描述信息。

在本申请实施例中，客户端可以提供错误码界面，在该错误码界面输入第二错误码后，服务端可对其进行检索，并在检索到的情况下，显示第二错误码的编辑界面供用户操作，以在该编辑界面实现第二错误码及其描述信息的修改，相较于将错误码以代码形式存储在静态文件时无法动态修改错误码及错误码描述信息，本申请可以在客户端实现错误码的动态修改和灵活调整。

涉及步骤220，在关系型数据库和内存数据库中同步存储错误码信息。

在本申请的一些实施例中，关系型数据库可以包括主数据库和备用数据库，步骤220可以具体包括：在主数据库和备用数据库中同步存储错误码信息；在主数据库故障或宕机的情况下，确定备用数据库为主数据库。

具体地，服务端的关系型数据库采用一主库一备库架构，当错误码信息在主数据库保存成功后，主数据库会自动将错误码信息同步保存至备用数据库中。若主数据库发生故障/宕机，则备用数据库会作为新的主数据库。

在本申请实施例中，服务端通过在关系型数据库部署主从架构，在主数据库发生故障/宕机导致不可用时，基于备用数据库能够保证错误码的正常存储和调用，通过存储空间换取了容灾性。

在本申请的一些实施例中，为了缓解关系型数据库和内存数据库的存储压力，错误码信息包括错误码和错误码描述信息，图3是本申请另一实施例提供的错误码管理方法的流程示意图，步骤220可以包括图3所示的步骤310和步骤320。

步骤310，对错误码和错误码描述信息进行哈夫曼编码(Huffman Coding)。

步骤320，在关系型数据库和内存数据库中存储编码后的错误码和错误码描述信息。

示例性地，错误码为“ABCACCDAEAE”，经过哈夫曼编码处理后，各个字母的编码为：A＝11，B＝010，C＝10，D＝011，E＝00，则编码后的错误码为“110101011101001111001100”。

在本申请实施例中，当错误码数量逐渐增多时，服务端的关系型数据库和内存数据所需的存储空间将会随之增大，因此在存储错误码及其描述信息之前，服务端结合哈夫曼编码将错误码及其对应的描述信息进行压缩，在使用到错误码的场景对其进行解压，以此降低错误码及其描述信息的存储空间，实现存储空间的优化。

在本申请的一些实施例中，在步骤220之后，该方法还可以包括：在内存数据库的内存空间小于预设空间阈值的情况下，删除内存数据库中的至少部分错误码信息。

其中，该至少部分错误码信息可以为满足预设删除条件的错误码信息，该预设删除条件例如可以为存储时间在预设时间段内，或者占用内存空间大于预设值等。预设空间阈值可以在实际应用中根据具体需求进行设置，本申请在此不做具体限定。

在本申请实施例中，可以为Redis内存数据库设置内存空间限制，在内存数据库的内存空间过小的情况下，清除内存数据库中的至少部分错误码信息，保证内存数据库可用。由于关系型数据库本身的性能瓶颈难以支撑在高并发场景下的频繁访问，因此通过保证内存数据库可用，且在接收到错误码查询请求时优先由内存数据库提供查询服务，能够提升服务端在高并发场景下的整体性能。

涉及步骤230，在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求。

分布式系统中的子系统可以接收用户终端发送的业务请求，并基于业务请求为用户提供业务服务，当子系统对业务请求处理失败，即无法提供业务服务时，此时需向用户终端返回错误码信息，以使用户终端基于错误码信息向用户输出“商品库存不足”、“无法提交订单”、“物流异常”等提示信息。

在分布式系统的子系统对业务请求处理失败的情况下，由于错误码管理系统的客户端接入了子系统，因此可以及时感知“子系统对业务请求处理失败”，并向服务端发起错误码查询请求，以向服务端请求获取错误码信息。

在一些实施例中，在分布式系统的子系统对业务请求处理失败的情况下，子系统可以向客户端发送错误码查询请求，以使客户端向服务端转发该错误码查询请求。

涉及步骤240，从内存数据库中获取与错误码查询请求对应的目标错误码信息。

在本申请的一些实施例中，图4是本申请再一实施例提供的错误码管理方法的流程示意图，步骤240可以包括图4所示的步骤410-步骤430。

步骤410，在内存数据库中查询目标错误码信息。

具体地，服务端在接收到客户端发送的错误码查询请求的情况下，服务端优先从内存数据库中进行查询。

在一个实施例中，错误码查询请求可以包括业务请求失败信息，服务端可以从内存数据库中获取与业务请求失败信息对应的错误码信息，得到与错误码查询请求对应的目标错误码信息。

示例性地，内存数据库可以为远程字典服务(Remote Dictionary Server，Redis)。

步骤420，在内存数据库中未查询到的情况下，从关系型数据库中获取目标错误码信息。

步骤430，基于目标错误码信息更新内存数据库。

具体地，在内存数据库中存储目标错误码信息。

在本申请实施例中，由于在关系型数据库本身的性能瓶颈难以支撑在高并发场景下的频繁访问，因此所有对服务端发起的错误码查询请求，服务端可以优先由内存数据库提供服务，从内存数据库中获取与错误码查询请求对应的目标错误码信息，仅在内存数据库中未查询到目标错误码信息的情况下，才会调用关系型数据库提供查询服务，减少对关系型数据库的访问次数，提升服务端在高并发场景下的整体性能。同时，在内存数据库中未存储目标错误码信息时，还可以基于关系型数据库中查询到的目标错误码信息更新内存数据库，以此提升内存数据库的数据完整性，提高内存数据库的查询命中率。

涉及步骤250，向客户端发送目标错误码信息。

在本申请的一些实施例中，在关系型数据库和内存数据库中存储编码后的错误码和错误码描述信息的情况下，步骤250可以具体包括：在向客户端发送解码后的目标错误码信息。

在本申请的一些实施例中，为了降低服务端及分布式系统国际化部署成本，错误码查询请求包括子系统的语言环境信息，图5是本申请再一实施例提供的错误码管理方法的流程示意图，如图5所示，在步骤240之后，该方法还可以包括步骤510，步骤250可以包括图5所示的步骤520。

步骤510，基于语言环境信息，对目标错误码信息进行翻译；

步骤520，向客户端发送翻译后的目标错误码信息。

示例性地，若错误码查询请求包括子系统的语言环境信息“英语”，则服务端在获取到目标错误码信息后，可以将目标错误码信息翻译为英语语种，并向客户端返回英语语种的目标错误码信息。

在本申请实施例中，服务端通过基于语言环境信息对目标错误码信息进行翻译，可以实现跨国环境下的错误码调用，因此服务端可以仅在国内机房部署一套服务，分布式系统可以在不同的国家、不同的公有云上访问国内的服务端，以此降低服务端的部署成本。

在本申请的另一些实施例中，为了减轻服务端侧的处理压力，客户端可以基于错误码查询请求中的语言环境信息对目标错误码信息进行翻译，并将翻译后的目标错误码信息返回给子系统。

在本申请的一些实施例中，不同的公有云在跨国环境下，对国内的服务端进行访问时存在网络延迟，服务端可以基于预设周期向客户端发送关系型数据库中存储的错误码信息，客户端可以通过系统进程缓存错误码信息。

如此，服务端与客户端可以通过定期同步错误码信息实现数据一致性，客户端支持系统进程级别的内存缓存，当分布式系统中的子系统请求错误码信息时，客户端可以无需访问服务端，直接将错误码信息返回给子系统，减少访问服务端的次数，避免访问服务端时的网络延迟导致错误码信息返回速度较慢。

在本申请的一些实施例中，客户端与服务端之间的信息交互可以采用标准超文本传输协议(Hyper Text Transfer Protocol，HTTP)。

在本申请的一些实施例中，错误码管理系统可以采用kubernetes，即K8S容器化技术部署。

在本申请的一些实施例中，本申请实施例不仅可以应用于分布式系统，还可以应用于单体应用或嵌入式应用。

需要说明的是，本申请实施例提供的错误码管理方法，执行主体可以为错误码管理装置，或者该错误码管理装置中的用于执行错误码管理的方法的控制模块。本申请实施例中以错误码管理装置执行错误码管理方法为例，说明本申请实施例提供的错误码管理装置。下面对错误码管理装置进行详细介绍。

图6是本申请实施例提供的一种错误码管理装置的结构示意图。

如图6所示，本申请实施例提供一种错误码管理装置600，该错误码管理装置600可以应用于服务端，该错误码管理装置600包括：获取模块610、存储模块620、接收模块630和发送模块640。

其中，获取模块610，用于获取用户在客户端的错误码界面输入的错误码信息；存储模块620，用于在关系型数据库和内存数据库中同步存储错误码信息；接收模块630，用于在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，客户端用于接入分布式系统的各个子系统；获取模块610，还用于从内存数据库中获取与错误码查询请求对应的目标错误码信息；发送模块640，用于向客户端发送目标错误码信息。

本申请实施例提供的错误码管理装置，客户端可以提供错误码界面，在该界面可以接收到所有用户的错误码录入操作，即使是负责不同子系统的开发人员，也能够在该界面录入错误码，实现错误码的统一定义。并且，服务端在获取到用户在客户端的错误码界面输入的错误码信息之后，可以在关系型数据库和内存数据库中同步存储错误码信息，避免多个子系统各自存储错误码时的存储方式不一，在服务端实现错误码信息的统一存储。基于此，通过将客户端接入分布式系统的各个子系统，在任意子系统对业务请求处理失败，需要获取错误码信息的场景下，客户端可以感知并向服务端发送错误码查询请求，服务端通过向客户端发送与错误码查询请求对应的目标错误码信息，为子系统提供错误码调用服务。如此，本申请可以在客户端实现错误码信息的统一定义，在服务端实现错误码信息的统一存储以及调用，因此能够保证错误码定义、存储以及调用方式相同，规范化管理所有错误码信息。

在本申请的一些实施例中，获取模块610包括：查询单元，用于在内存数据库中查询目标错误码信息；获取单元，用于在内存数据库中未查询到的情况下，从关系型数据库中获取目标错误码信息；更新单元，用于基于目标错误码信息更新内存数据库。

在本申请的一些实施例中，装置还包括：删除模块，用于在关系型数据库和内存数据库中同步存储错误码信息之后，在内存数据库的内存空间小于预设空间阈值的情况下，删除内存数据库中的至少部分错误码信息。

在本申请的一些实施例中，装置还包括：获取模块610，用于获取用户在客户端的错误码界面输入的第一错误码；输出模块，用于在内存数据库中检索到第一错误码的情况下，输出第一提示信息，第一提示信息用于提示用户第一错误码重复录入；输出模块，还用于在第一错误码满足预设错误码条件的情况下，输出第二提示信息，第二提示信息用于提示用户第一错误码不合规。

在本申请的一些实施例中，存储模块620包括：编码单元，用于对错误码和错误码描述信息进行哈夫曼编码；存储单元，用于在关系型数据库和内存数据库中存储编码后的错误码和错误码描述信息。

在本申请的一些实施例中，错误码查询请求包括子系统的语言环境信息，装置还包括：翻译模块，用于在从内存数据库中获取与错误码查询请求对应的目标错误码信息之后，基于语言环境信息，对目标错误码信息进行翻译；发送模块640具体用于：向客户端发送翻译后的目标错误码信息。

在本申请的一些实施例中，关系型数据库包括主数据库和备用数据库，存储模块620包括：存储单元，用于在主数据库和备用数据库中同步存储错误码信息；确定单元，用于在主数据库故障或宕机的情况下，确定备用数据库为主数据库。

本申请实施例提供的错误码管理装置能够实现图1-图5的方法实施例中电子设备所实现的各个过程，为避免重复，这里不再赘述。

本申请实施例中的错误码管理装置可以是电子设备，也可以是电子设备中的部件、集成电路、或芯片。该电子设备可以是终端，也可以为除终端之外的其他设备。示例性的，电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、移动上网装置(Mobile Internet Device，MID)、增强现实(augmented reality，AR)/虚拟现实(virtualreality，VR)设备、机器人、可穿戴设备、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，还可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personalcomputer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的错误码管理装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为iOS操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

可选地，如图7所示，本申请实施例还提供一种电子设备700，包括处理器701，存储器702，存储在存储器702上并可在处理器701上运行的程序或指令，该程序或指令被处理器701执行时实现上述错误码管理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要注意的是，本申请实施例中的电子设备包括上述的移动电子设备和非移动电子设备。

图8为本申请实施例的一种电子设备的硬件结构示意图。

该电子设备800包括但不限于：射频单元801、网络模块802、音频输出单元803、输入单元804、传感器805、显示单元806、用户输入单元807、接口单元808、存储器809、以及处理器810等部件。

本领域技术人员可以理解，电子设备800还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器810逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图8中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

其中，处理器810，用于获取用户在客户端的错误码界面输入的错误码信息；存储器809用于在关系型数据库和内存数据库中同步存储错误码信息；射频单元801，用于在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，客户端用于接入分布式系统的各个子系统；处理器810，还用于从内存数据库中获取与错误码查询请求对应的目标错误码信息；射频单元801，用于向客户端发送目标错误码信息。

在本申请实施例中，客户端可以提供错误码界面，在该界面可以接收到所有用户的错误码录入操作，即使是负责不同子系统的开发人员，也能够在该界面录入错误码，实现错误码的统一定义。并且，电子设备在获取到用户在客户端的错误码界面输入的错误码信息之后，可以在关系型数据库和内存数据库中同步存储错误码信息，避免多个子系统各自存储错误码时的存储方式不一，在电子设备实现错误码信息的统一存储。基于此，通过将客户端接入分布式系统的各个子系统，在任意子系统对业务请求处理失败，需要获取错误码信息的场景下，客户端可以感知并向电子设备发送错误码查询请求，电子设备通过向客户端发送与错误码查询请求对应的目标错误码信息，为子系统提供错误码调用服务。如此，本申请可以在客户端实现错误码信息的统一定义，在电子设备实现错误码信息的统一存储以及调用，因此能够保证错误码定义、存储以及调用方式相同，规范化管理所有错误码信息。

应理解的是，本申请实施例中，输入单元804可以包括图形处理器(GraphicsProcessing Unit，GPU)8041和麦克风8042，图形处理器8041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元806可包括显示面板8061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板8061。用户输入单元807包括触控面板8071以及其他输入设备8072中的至少一种。触控面板8071，也称为触摸屏。触控面板8071可包括触摸检测装置和触摸控制器两个部分。其他输入设备8072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

存储器809可用于存储软件程序以及各种数据。存储器809可主要包括存储程序或指令的第一存储区和存储数据的第二存储区，其中，第一存储区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器809可以包括易失性存储器或非易失性存储器，或者，存储器809可以包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请实施例中的存储器809包括但不限于这些和任意其它适合类型的存储器。

处理器810可包括一个或多个处理单元；可选地，处理器810集成应用处理器和调制解调处理器，其中，应用处理器主要处理涉及操作系统、用户界面和应用程序等的操作，调制解调处理器主要处理无线通信信号，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器810中。

本申请实施例还提供一种可读存储介质，可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述错误码管理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，处理器为上述实施例中的电子设备中的处理器。可读存储介质，包括计算机可读存储介质，计算机可读存储介质的示例包括非暂态计算机可读存储介质，如计算机只读存储器(ROM)、随机存取存储器(RAM)、磁碟或者光盘等。

本申请实施例另提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现上述错误码管理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

本申请实施例提供一种计算机程序产品，该计算机程序产品被存储在存储介质中，该计算机程序产品被至少一个处理器执行以实现如上述错误码管理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种错误码管理方法，其特征在于，所述方法包括：

获取用户在客户端的错误码界面输入的错误码信息；

在关系型数据库和内存数据库中同步存储所述错误码信息；

在分布式系统的子系统对业务请求处理失败的情况下，接收所述客户端发送的错误码查询请求，所述客户端用于接入所述分布式系统的各个子系统；

从所述内存数据库中获取与所述错误码查询请求对应的目标错误码信息；

向所述客户端发送所述目标错误码信息。

2.根据权利要求1所述的方法，其特征在于，所述从所述内存数据库中获取与所述错误码查询请求对应的目标错误码信息，包括：

在所述内存数据库中查询所述目标错误码信息；

在所述内存数据库中未查询到的情况下，从所述关系型数据库中获取所述目标错误码信息；

基于所述目标错误码信息更新所述内存数据库。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取用户在所述客户端的错误码界面输入的第一错误码；

在所述内存数据库中检索到所述第一错误码的情况下，输出第一提示信息，所述第一提示信息用于提示用户所述第一错误码重复录入；

在所述第一错误码满足预设错误码条件的情况下，输出第二提示信息，所述第二提示信息用于提示用户所述第一错误码不合规。

4.根据权利要求1所述的方法，其特征在于，所述错误码信息包括错误码和错误码描述信息，所述在关系型数据库和内存数据库中同步存储所述错误码信息，包括：

对所述错误码和错误码描述信息进行哈夫曼编码；

在所述关系型数据库和内存数据库中存储编码后的所述错误码和错误码描述信息。

5.根据权利要求1所述的方法，其特征在于，所述关系型数据库包括主数据库和备用数据库，所述在关系型数据库和内存数据库中同步存储所述错误码信息，包括：

在所述主数据库和所述备用数据库中同步存储所述错误码信息；

在所述主数据库故障或宕机的情况下，确定所述备用数据库为主数据库。

6.一种错误码管理装置，其特征在于，所述装置包括：

获取模块，用于获取用户在客户端的错误码界面输入的错误码信息；

存储模块，用于在关系型数据库和内存数据库中同步存储所述错误码信息；

接收模块，用于在分布式系统的子系统对业务请求处理失败的情况下，接收客户端发送的错误码查询请求，所述客户端用于接入所述分布式系统的各个子系统；

所述获取模块，还用于从所述内存数据库中获取与所述错误码查询请求对应的目标错误码信息；

发送模块，用于向所述客户端发送所述目标错误码信息。

7.根据权利要求6所述的装置，其特征在于，所述获取模块包括：

查询单元，用于在所述内存数据库中查询所述目标错误码信息；

获取单元，用于在所述内存数据库中未查询到的情况下，从所述关系型数据库中获取所述目标错误码信息；

更新单元，用于基于所述目标错误码信息更新所述内存数据库。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

获取模块，用于获取用户在所述客户端的错误码界面输入的第一错误码；

输出模块，用于在所述内存数据库中检索到所述第一错误码的情况下，输出第一提示信息，所述第一提示信息用于提示用户所述第一错误码重复录入；

所述输出模块，还用于在所述第一错误码满足预设错误码条件的情况下，输出第二提示信息，所述第二提示信息用于提示用户所述第一错误码不合规。

9.根据权利要求6所述的装置，其特征在于，所述存储模块包括：

编码单元，用于对所述错误码和错误码描述信息进行哈夫曼编码；

存储单元，用于在所述关系型数据库和内存数据库中存储编码后的所述错误码和错误码描述信息。

10.根据权利要求6所述的装置，其特征在于，所述关系型数据库包括主数据库和备用数据库，所述存储模块包括：

存储单元，用于在所述主数据库和所述备用数据库中同步存储所述错误码信息；

确定单元，用于在所述主数据库故障或宕机的情况下，确定所述备用数据库为主数据库。

Images