本说明书实施例涉及区块链技术领域，尤其涉及一种定位异常系统的方法及装置和电子设备。
背景技术：
在相关技术中，网站的架构一般采用的是面向服务(service-orientedarchitecture，soa)的架构。采用soa架构时，一个完整的业务可以由多个不同的服务对应的系统来共同完成。按照业务流程的顺序，可以由这些不同的系统构成一条业务链路。即实现一个完整的业务，可以从该业务链路最下游的系统开始，依次执行相关服务，当该业务链路执行完最上游系统的服务器后，整个业务执行完毕。当业务链路上任一系统执行的服务出现异常不能正常执行时，就会导致后续系统的服务也不能正常执行，如此该最初异常的系统及后续系统都会向运维平台发送报警日志；一般的，业务链路越长，发送的报警日志数量越多。
技术实现要素：
本说明书实施例提供的一种定位异常系统的方法及装置和电子设备：
根据本说明书实施例的第一方面，提供一种定位异常系统的方法，所述方法包括：
接收来自同一业务链路中至少一个系统上报的报警日志；
从其中一个报警日志开始，将该报警日志确定为第一报警日志；
获取所述第一报警日志中记录的关联的系统；其中，所述关联的系统为所述业务链路中相连的系统；
根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
可选的，所述方法还包括：
根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
根据所述错误码确定对应的错误原因。
可选的，所述方法还包括：
根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
根据本说明书实施例的第二方面，提供一种定位异常系统的方法，所述方法包括：
接收来自同一业务链路中至少一个系统上报的报警日志；
从其中一个报警日志开始，将该报警日志确定为第一报警日志；
获取所述第一报警日志中记录的关联的系统和服务；其中，所述关联的系统为所述业务链路中相连的系统，所述关联的服务为所述关联的系统执行的服务；
在所述关联的服务与所述第一报警日志对应的系统执行的服务相同的情况下，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统和服务，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
可选的，所述方法还包括：
根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
根据所述错误码确定对应的错误原因。
可选的，所述方法还包括：
根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
根据本说明书实施例的第三方面，提供一种定位异常系统的装置，所述装置包括：
接收单元，接收来自同一业务链路中至少一个系统上报的报警日志；
确定单元，从其中一个报警日志开始，将该报警日志确定为第一报警日志；
第一获取单元，获取所述第一报警日志中记录的关联的系统；其中，所述关联的系统为所述业务链路中相连的系统；
第二获取单元，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
循环单元，将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
可选的，所述装置还包括：
获取子单元，根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
确定子单元，根据所述错误码确定对应的错误原因。
可选的，所述装置还包括：
推送子单元，根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
根据本说明书实施例的第四方面，提供一种定位异常系统的装置，所述装置包括：
接收单元，接收来自同一业务链路中至少一个系统上报的报警日志；
确定单元，从其中一个报警日志开始，将该报警日志确定为第一报警日志；
第一获取单元，获取所述第一报警日志中记录的关联的系统和服务；其中，所述关联的系统为所述业务链路中相连的系统，所述关联的服务为所述关联的系统执行的服务；
第二获取单元，在所述关联的服务与所述第一报警日志对应的系统执行的服务相同的情况下，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
循环单元，将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统和服务，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
可选的，所述装置还包括：
获取子单元，根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
确定子单元，根据所述错误码确定对应的错误原因。
可选的，所述装置还包括：
推送子单元，根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
根据本说明书实施例的第四方面，提供一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为实现如上述实施例中任一所述的定位异常系统的方法。
本说明书提供一种定位异常系统的方案，通过设置一个定位系统，所述定位系统在接收到同一业务链路中至少一个系统上报的报警日志后，可以根据系统之间的关联关系进行反向的推导，一层层的向最根本的异常系统进行上溯，即查询当前报警日志中是否记录有关联的系统，如果有上溯到该关联的系统上报的报警日志；循环执行查询当前报警日志中是否记录有关联的系统；直到当前报警日志没有关联的系统(即关联的系统为空)时，说明此时的报警日志是最根本的异常系统上传的报警日志，(因为最先出现异常的系统没有其它系统会向其发送错误通知，因此上报的报警日志中也不会有关联的系统)。如此可以直接定位到出现异常的系统。
附图说明
图1是本说明书一实施例提供的一具体业务的流程图；
图2是本说明书一实施例提供的定位异常系统的方法的流程图；
图3是本说明书一实施例提供的另一具体业务的流程图；
图4是本说明书一实施例提供的报警日志中记录的数据的示意图；
图5是本说明书一实施例提供的定位异常系统的方法的流程图；
图6是本说明书一实施例提供的定位异常系统的装置的模块示意图；
图7是本说明书一实施例提供的定位异常系统的装置的模块示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
如前所述，采用soa架构时，一个完整的业务可以由多个不同的服务对应的系统来共同完成。按照业务流程的顺序，可以由这些不同的系统构成一条业务链路。即实现一个完整的业务，可以从该业务链路最下游的系统开始，依次执行相关服务，当该业务链路执行完最上游系统的服务后，整个业务执行完毕。当业务链路上任一系统执行的服务出现错误不能正常执行时，该系统就会向下游的系统发送错误通知，并向运维平台发送包含本系统出现错误信息的报警日志；而下游的系统在接收到上游系统发送的错误通知后，同样会向下游系统发送错误通知，并向运维平台发送包含本系统出现错误信息的报警日志；以此类推，直到最下游的系统接收到错误通知后，向业务请求方返回错误以及向运维平台发送包含本系统出现的错误信息的报警日志。如此该最初错误的系统及其下游所有的系统都会向运维平台发送各自的报警日志(这些报警日志中记录的错误信息都不相同)；一般的，业务链路越长，发送的报警日志数量越多。
如图1所示的一个具体的业务流程的示意图，在充值业务场景下，存在有用户客户端、充值系统、收银台系统，支付系统以及运维平台。
1：用户客户端首先向充值系统发起充值请求；
2：所述充值系统接收并处理该充值请求，调用上游的收银台系统执行相关服务；
3：所述收银台系统进行内部收银处理，调用上游的支付系统执行相关服务；
4：所述支付系统根据充值信息发起支付；当支付系统进行支付时发生内部错误时，会向下游的收银台系统发送错误通知，以及向运维平台发送包含支付错误的报警日志；
5：所述收银台系统在接收到支付系统发送的错误通知后，同样会向下游的充值系统发送错误通知，以及向运维平台发送包含收银错误的报警日志；
6：所述充值系统在接收到收银台系统发送的错误通知后，可以会向用户客户端下发错误页面，以及向报警平台发送包含充值错误的报警日志。
可以看出，在支付系统执行服务出现错误时，支付系统及其下游其它系统均会向运维平台发送报警日志，并且每个报警日志指出的错误信息也都不相同。对于运维平台，会突发接收大量报警日志，但是这些报警日志中其实只有一条是真正出现问题的系统，因此运维人员往往需要从大量报警日志中找到这个真正指出问题的报警日志。这不仅会耗费大量时间、还需要运维人员具有一定的经验；因此，现有技术中存在无法准确定位异常系统的问题。
为了解决上述问题，本说明书提供了一种可以实现定位异常系统的方案。图2所示的例子介绍本说明书一种实现定位异常系统的方法的实施例，如图2所示，所述方法可以包括以下步骤：
步骤110：接收来自同一业务链路中至少一个系统上报的报警日志；
步骤120：从其中一个报警日志开始，将该报警日志确定为第一报警日志；
步骤130：获取所述第一报警日志中记录的关联的系统；其中，所述关联的系统为所述业务链路中相连的系统；
步骤140：根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
步骤150：将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
以下以图3所示的一个具体的业务流程的示意图，在充值业务场景下，存在有用户客户端、充值系统、收银台系统，支付系统以及运维平台。在一个可选的实施例中，所述定位系统可以集成在运维平台(图3所示)。在另一个可选的实施例中，所述定位系统也可以独立于运维平台，所述定位系统与所述运维平台之间可以进行数据交互，即定位系统可以将定位的异常系统结果提供给运维平台，以供所述运维平台进行处理。与图1相比，图3中定位系统可以收集来自该充值业务链路中支付系统、收银台系统和充值系统上报的报警日志；然后，该定位系统可以根据这些报警日志定位根本问题所在的系统，也就是定位异常系统。
在一实施例中，所述报警日志中可以记录有上报这个报警日志的系统所关联的另一个系统。
依然以图3所示的示例为例加以说明，结合图4所示的充值系统、收银台系统和支付系统上报的报警日志。可以看出报警日志中至少可以包括系统(上报报警日志的系统)、关联的系统。假设充值系统上报了报警日志a；收银台系统上报了报警日志b；支付系统上报了报警日志c；其中，所述报警日志a记录的关联的系统为收银台系统；所述报警日志b记录的关联的系统为支付系统；所述报警日志c记录的关联的系统为null(空)。如果定位系统首先将报警日志a确定为第一报警日志的话，那么可以获取到所述报警日志a记录的关联的收银台系统；进而，获取所述收银台系统上报的报警日志b(即此时的第二报警日志)；将报警日志b确定为第一报警日志，由于所述报警日志b存在关联的支付系统；进而，获取所述支付系统上报的报警日志c(此时的第二报警日志)；将报警日志c确定为第一报警日志，由于报警日志c关联的系统为空，因此可以将报警日志c对应的系统即支付系统确定为出现异常的系统。
通过本实施例中，通过设置一个定位系统，所述定位系统在接收到同一业务链路中至少一个系统上报的报警日志后，可以根据系统之间的关联关系进行反向的推导，一层层的向最根本的异常系统进行上溯，即查询当前报警日志中是否记录有关联的系统，如果有上溯到该关联的系统上报的报警日志；循环执行查询当前报警日志中是否记录有关联的系统；直到当前报警日志没有关联的系统(即关联的系统为空)时，说明此时的报警日志是最根本的异常系统上传的报警日志，(因为最先出现异常的系统没有其它系统会向其发送错误通知，因此上报的报警日志中也不会有关联的系统)。如此可以直接定位到出现异常的系统。
在一个实施例中，所述步骤150之后，所述方法还可以包括：
根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
根据所述错误码确定对应的错误原因。
其中，所述报警日志中还记录有错误码。所述错误码用于指示系统发生错误的类型。例如图4中所示的，错误码可以包括fails_1(可以表示充值错误)、fails_2(可以表示收银错误)、fails_3(可以表示支付错误)。由于最终确定的异常的系统为支付系统，因此可以获取支付系统上报的报警日志中记录的错误码即fails_3，由于fails_3代表的错误原因是支付错误，因此可以确定是支付错误引起的异常。
在一个实施例中，在所述确定对应的错误原因之后，所述方法还可以包括：
根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
在实际应用中，运维平台具有分配处理任务的能力，主要是将出现异常的系统以及出现的问题等信息推送给相关的运维人员。一般的，运维人员通常可以根据擅长处理的问题类型进行分类，也就是说运维平台可以根据异常系统的错误原因，将处理该异常系统的处理任务推送给删除处理这类错误原因的运维人员；如此可以提高异常系统的处理效率。
为了解决上述问题，本说明书提供了一种可以实现定位异常系统的方案。图5所示的例子介绍本说明书一种实现定位异常系统的方法的实施例，如图5所示，所述方法可以包括以下步骤：
步骤210：接收来自同一业务链路中至少一个系统上报的报警日志；
步骤220：从其中一个报警日志开始，将该报警日志确定为第一报警日志；
步骤230：获取所述第一报警日志中记录的关联的系统和服务；其中，所述关联的系统为所述业务链路中相连的系统，所述关联的服务为所述关联的系统执行的服务；
步骤240：在所述关联的服务与所述第一报警日志对应的系统执行的服务相同的情况下，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
步骤250：将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统和服务，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
本实施例与图1所示实施例不同之处在于，报警日志中还记录有关联的服务，所述关联的服务为所述关联的系统执行的服务。在实际应用中，同一业务链路可以执行相似但并不相同的业务，例如同样是资金流转的业务，就可以细分为转账、汇款、还款、支付等。因此，定位系统还需要识别报警日志中记录的关联的服务是否一致。
依然以图3所示的示例并且结合图4所示的充值系统、收银台系统和支付系统上报的报警日志为例加以说明。可以看出报警日志中至少可以包括系统(上报报警日志的系统)、关联的系统以及关联的服务。假设充值系统上报了报警日志a；收银台系统上报了报警日志b；支付系统上报了报警日志c。如果定位系统首先从报警日志a开始的话，那么可以获取到所述报警日志a记录的关联的收银台系统、关联的服务为充值服务；由于报警日志a对应的充值系统执行的是充值服务与关联的服务一致，因此可以获取所述收银台系统上报的报警日志b中记录的关联的系统为支付系统、关联的服务为充值服务；由于报警日志b对应的收银台系统执行的是充值服务与关联的服务一致，因此可以获取所述收银台系统上报的报警日志c；由于报警日志c关联的系统为null(空)，因此可以将报警日志c对应的系统即支付系统确定为出现异常的系统。
在一个实施例中，所述步骤250之后，所述方法还可以包括：
根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
根据所述错误码确定对应的错误原因。
其中，所述报警日志中还记录有错误码。所述错误码用于指示系统发生错误的类型。例如图4中所示的，错误码可以包括fails_1(可以表示充值错误)、fails_2(可以表示收银错误)、fails_3(可以表示支付错误)。由于最终确定的异常的系统为支付系统，因此可以获取支付系统上报的报警日志中记录的错误码即fails_3，由于fails_3代表的错误原因是支付错误，因此可以确定是支付错误引起的异常。
在一个实施例中，在所述确定对应的错误原因之后，所述方法还可以包括：
根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
在实际应用中，运维平台具有分配处理任务的能力，主要是将出现异常的系统以及出现的问题等信息推送给相关的运维人员。一般的，运维人员通常可以根据擅长处理的问题类型进行分类，也就是说运维平台可以根据异常系统的错误原因，将处理该异常系统的处理任务推送给删除处理这类错误原因的运维人员；如此可以提高异常系统的处理效率。
与前述定位异常系统的方法实施例相对应，本说明书还提供了定位异常系统的装置的实施例。所述装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，本说明书定位异常系统的装置所在设备的一种硬件结构可以包括处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该定位异常系统的实际功能，还可以包括其他硬件，对此不再赘述。
请参见图6，为本说明书一实施例提供的定位异常系统的装置的模块图，所述装置对应了图2所示实施例，所述装置包括：
接收单元310，接收来自同一业务链路中至少一个系统上报的报警日志；
确定单元320，从其中一个报警日志开始，将该报警日志确定为第一报警日志；
第一获取单元330，获取所述第一报警日志中记录的关联的系统；其中，所述关联的系统为所述业务链路中相连的系统；
第二获取单元340，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
循环单元350，将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
在一个可选的实施例中：
所述装置还包括：
获取子单元，根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
确定子单元，根据所述错误码确定对应的错误原因。
在一个可选的实施例中：
所述装置还包括：
推送子单元，根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
请参见图7，为本说明书一实施例提供的定位异常系统的装置的模块图，所述装置对应了图5所示实施例，所述装置包括：
接收单元410，接收来自同一业务链路中至少一个系统上报的报警日志；
确定单元420，从其中一个报警日志开始，将该报警日志确定为第一报警日志；
第一获取单元430，获取所述第一报警日志中记录的关联的系统和服务；其中，所述关联的系统为所述业务链路中相连的系统，所述关联的服务为所述关联的系统执行的服务；
第二获取单元440，在所述关联的服务与所述第一报警日志对应的系统执行的服务相同的情况下，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
循环单元450，将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统和服务，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
在一个可选的实施例中：
所述装置还包括：
获取子单元，根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
确定子单元，根据所述错误码确定对应的错误原因。
在一个可选的实施例中：
所述装置还包括：
推送子单元，根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上图6描述了报表生成装置的内部功能模块和结构示意，其实质上的执行主体可以为一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
接收来自同一业务链路中至少一个系统上报的报警日志；
从其中一个报警日志开始，将该报警日志确定为第一报警日志；
获取所述第一报警日志中记录的关联的系统；其中，所述关联的系统为所述业务链路中相连的系统；
根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
可选的，还包括：
根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
根据所述错误码确定对应的错误原因。
可选的，还包括：
根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
以上图7描述了报表生成装置的内部功能模块和结构示意，其实质上的执行主体可以为一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
接收来自同一业务链路中至少一个系统上报的报警日志；
从其中一个报警日志开始，将该报警日志确定为第一报警日志；
获取所述第一报警日志中记录的关联的系统和服务；其中，所述关联的系统为所述业务链路中相连的系统，所述关联的服务为所述关联的系统执行的服务；
在所述关联的服务与所述第一报警日志对应的系统执行的服务相同的情况下，根据所述记录的关联的系统，获取该关联的系统上报的第二报警日志；
将所述第二报警日志确定为第一报警日志后，重复执行所述获取所述第一报警日志中记录的关联的系统和服务，直到所述第一报警日志中记录的关联的系统为空时，将该第一报警日志对应的系统确定为出行异常的系统。
可选的，还包括：
根据所确定的异常的系统，获取该异常的系统上报的报警日志中记录的错误码；
根据所述错误码确定对应的错误原因。
可选的，还包括：
根据所述异常的系统的错误原因，将所述异常的系统的处理任务推送给处理该类错误原因的运维人员。
在上述电子设备的实施例中，应理解，该处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，而前述的存储器可以是只读存储器(英文：read-onlymemory，缩写：rom)、随机存取存储器(英文：randomaccessmemory，简称：ram)、快闪存储器、硬盘或者固态硬盘。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。