本申请涉及计算机
技术领域：
：，具体而言，涉及一种信息采集方法、装置、服务器及计算机可读存储介质。
背景技术：
：：目前，元数据信息的采集及更新主要采用“全量采集，增量写入”的方式。服务器通过查询业务数据库中最新的所有元数据信息(全量采集)，并将元数据信息库中存储的老的元数据信息与业务数据库中新的元数据信息进行逐表逐行对比，找出新增、删除以及修改的增量行信息，最后将增量的元数据行信息写入元数据信息库中(增量写入)。然而，在信息爆炸的今天，用户业务逐渐复杂，元数据信息也日益庞大，业务数据库涉及的业务表数量可能达到成千上万甚至更多，且随着用户业务的扩展，业务数据库中业务表的元数据信息随时可能发生变化。因此，在业务数据库元数据信息较大且采集周期内部分业务表的信息变动频繁的情况下，上述通过“全量采集，增量写入”的方式进行元数据信息的采集及更新，将会出现元数据信息采集效率较慢、服务器处理时间较长的问题。技术实现要素：有鉴于此，本申请的目的在于提供一种信息采集方法、装置、服务器及计算机可读存储介质，以提高元数据信息采集效率，降低服务器的处理时间。为了实现上述目的，本申请实施例采用的技术方案如下：第一方面，本申请实施例提供了一种信息采集方法，应用于服务器，所述方法包括：从存放业务数据库的数据源端读取预设采集状态表记录的所述业务数据库中发生数据变化的业务表的名称和所述业务表对应的更新操作；其中，所述业务表的名称和所述业务表对应的更新操作由所述数据源端在监听到所述业务数据库中的业务表发生数据变化时，添加到所述预设采集状态表中；根据所述业务表对应的更新操作确定所述业务表处于新增状态、删除状态或修改状态；若所述业务表处于新增状态或修改状态，则根据所述业务表的名称从所述业务数据库中获取所述业务表的元数据信息；若所述业务表处于删除状态，则不从所述业务数据库中获取所述业务表的元数据信息。第二方面，本申请实施例还提供了一种信息采集装置，应用于服务器，所述装置包括：读取模块，用于从存放业务数据库的数据源端读取预设采集状态表记录的所述业务数据库中发生数据变化的业务表的名称和所述业务表对应的更新操作；其中，所述业务表的名称和所述业务表对应的更新操作由所述数据源端在监听到所述业务数据库中的业务表发生数据变化时，添加到所述预设采集状态表中；状态确定模块，用于根据所述业务表对应的更新操作确定所述业务表处于新增状态、删除状态或修改状态；信息获取模块，用于若所述业务表处于新增状态或修改状态，则根据所述业务表的名称从所述业务数据库中获取所述业务表的元数据信息；若所述业务表处于删除状态，则不从所述业务数据库中获取所述业务表的元数据信息。第三方面，本申请实施例还提供了一种服务器，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的计算机程序，所述计算机程序被所述处理器执行时实现上述第一方面所述的方法。第四方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。相对现有技术，本申请实施例提供的信息采集方法、装置、服务器及计算机可读存储介质，服务器从存放业务数据库的数据源端读取预设采集状态表记录的业务数据库中发生数据变化的业务表的名称和业务表对应的更新操作，该业务表的名称和业务表对应的更新操作由数据源端在监听到业务数据库中的业务表发生数据变化时，添加到预设采集状态表中，该服务器根据业务表对应的更新操作确定业务表处于新增状态、删除状态或修改状态，若业务表处于新增状态或修改状态，则根据业务表的名称从业务数据库中获取业务表的元数据信息，若业务表处于删除状态，则不从业务数据库中获取业务表的元数据信息。如此，服务器只需从业务数据库中获取处于新增状态及修改状态的业务表的元数据信息，对于处于删除状态或者没有发生数据变化的业务表的元数据信息则不用从业务数据库中获取，实现了从数据源端增量采集元数据信息，相比现有技术需从业务数据库采集最新的所有元数据信息的方式，有效降低了元数据信息的传输时间，从而提升了元数据信息采集效率；对于服务器来说，只需读取预设采集状态表并解析出业务表当前处于新增、删除或者修改状态，与现有技术相比，有效减少了大数据量下对新、老元数据信息进行对比这一耗时步骤，从而降低了服务器的处理时间。为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。附图说明为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。图1示出了本申请实施例提供的信息采集方法及装置的应用环境示意图。图2示出了预设采集状态表的一种示意图。图3示出了更新后的预设采集状态表的示意图。图4示出了本申请实施例提供的元数据信息采集方法的一种流程示意图。图5示出了本申请实施例提供的元数据信息采集方法的另一种流程示意图。图6示出了本申请实施例提供的一种元数据信息采集装置的功能模块示意图。图7示出了可以实现本申请实施例提供的服务器的一种结构框图。图标：100-服务器；200-数据源端；410-读取模块；420-状态确定模块；430-信息获取模块；440-信息更新模块；110-存储器；120-处理器；130-通信模块。具体实施方式下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。请参照图1，为本申请实施例提供的信息采集方法及装置的应用环境示意图。服务器100与数据源端200通信连接，服务器100中创建有元数据信息库，数据源端200中创建有业务数据库，元数据信息库及业务数据库均用于存储表的元数据信息，例如表名、表类型、条目数等。需要说明的是，为了便于描述，元数据信息库中的表和业务数据库中的表在本实施例中均称为业务表。服务器100在业务数据库中存储的元数据信息发生变化时，通过采集业务数据库中业务表的元数据信息，并在元数据信息库中对相应业务表的元数据信息进行新增、覆盖或删除操作，达到更新元数据信息的目的，便于服务器100进行数据质量分析以及元数据管理。在本实施例中，该数据源端200中存放有预设采集状态表，该预设采集状态表用于存放业务数据库中的所有发生数据变化的业务表的名称和该业务表对应的更新操作。在本实施例中，该数据源端200可以实时监听业务数据库中的业务表是否发生数据变化，该预设采集状态表中记录的业务表的名称和该业务表对应的更新操作由该数据源端200在每次监听到业务数据库中的业务表发生数据变化时，添加到该预设采集状态表中。需要说明的是，本实施例中的业务表发生数据变化可以包括以下几种情形：业务数据库中新增了业务表、业务数据库中的业务表的数据被修改、业务数据库中的业务表的数据被删除等。如图2所示，为预设采集状态表的一种示意图。该预设采集状态表可以包括两个列，即表名称列tablename和表状态列status。其中，该表名称列tablename是用于记录业务数据库中业务表的表名称的，而表状态列status是用于存储业务表对应的更新操作的；其中，业务表每次发生数据变化所对应的更新操作都会被记录到该业务表对应的表状态列status中，因此该表状态列status记录的更新操作可以表征业务表的连续变化情况。例如，业务表table1对应的更新操作为“delete,add,modify,delete”，业务表table2对应的更新操作为“add,modify,modify,modify,modify”，业务表table3对应的更新操作为“delete,add”，业务表table4对应的更新操作为“add”。在本实施例中，可以利用业务数据库的触发器来监听业务数据库中的业务表是否发生数据变化。该触发器通过主动地监听一些与业务数据库相关的事件，实现对业务数据库中业务表的变化状态的监控，在用户对业务数据库进行更新时，筛选出有效的更新操作，同时根据业务表的名称和业务表对应的更新操作更新预设采集状态表。其中，当业务数据库中的业务表是首次发生数据变化时，触发器需要将发生数据变化的业务表的名称和该业务表对应的更新操作添加到预设采集状态表中，此时该业务表对应的表状态列status中包括一个更新操作；当该业务表再次发生数据变化时，由于该业务表的名称已经添加到预设采集状态表中，此时只需要在表状态列status中将该业务表再次发生数据变化时对应的更新操作添加到前一个更新操作的后面。需要说明的是，在本实施例中，该更新操作可以包括新增操作(add)、修改操作(modify)和删除操作(delete)；其中，定义重复新增、重复删除和重复修改为无效的更新操作，也即是说，触发器在监听业务数据库的过程中，若检测到用户输入的更新指令是重复新增、重复删除或重复修改指令，则判定用户对业务数据库的更新操作为无效的操作；反之，若检测到用户输入的更新指令不是重复新增、重复删除或重复修改指令，则判定用户对业务数据库的更新操作是有效的操作。以图2所示的预设采集状态表为例，假设触发器监听到业务数据库中新增了一个业务表，则在预设采集状态表中新增一行，将新增的业务表的名称(例如，table5)和新增操作(add)添加到预设采集状态表中，如图3所示，此时预设采集状态表中table5对应的更新操作为“add”，若触发器监听到预设采集状态表中的table4被删除，则在table4对应的表状态列status中将删除操作(delete)添加到新增操作(add)的后面，此时预设采集状态表中table4对应的更新操作已由图2中的“add”更新为图3所示的“add,delete”。服务器100通过从数据源端200读取预设采集状态表存放的所有业务表的名称和业务表对应的更新操作，并根据业务表对应的更新操作确定业务表当前处于新增状态、删除状态或修改状态，进而确定是否从业务数据库获取业务表的元数据信息。下面，将对服务器100读取预设采集状态表、解析所有业务表的当前所处状态以及从业务数据库增量获取业务表的元数据信息的过程进行详细阐述。请参照图4，为本申请实施例所提供的一种元数据信息采集方法的流程示意图。需要说明的是，本申请实施例的元数据信息采集方法并不以图4以及以下的具体顺序为限制，应当理解，在其他实施例中，本申请实施例的元数据信息采集方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该元数据信息采集方法可以应用于图1所示的服务器100中，下面将对图4所示的具体流程进行详细阐述。步骤s301，从存放业务数据库的数据源端读取预设采集状态表记录的业务数据库中发生数据变化的业务表的名称和业务表对应的更新操作；其中，业务表的名称和业务表对应的更新操作由数据源端在监听到业务数据库中的业务表发生数据变化时，添加到预设采集状态表中。在本实施例中，服务器100可以周期性地从数据源端200读取预设采集状态表，且数据源端200在服务器100每次读取预设采集状态表后，需要置空该预设采集状态表，触发器则继续监控业务数据库中业务表的变化状态，同时更新该预设采集状态表。可以理解，服务器100每次读取的预设采集状态表中记录的更新操作，实际上是业务表在服务器100的一个采集间隔时间内的连续变化情况。步骤s302，根据业务表对应的更新操作确定业务表处于新增状态、删除状态或修改状态。在本实施例中，当业务表对应的更新操作为一个时，若业务表对应的更新操作为新增操作，则可确定该业务表处于新增状态，若业务表对应的更新操作为删除操作，则可确定该业务表处于删除状态，若业务表对应的更新操作为修改操作，则可确定该业务表处于修改状态。在本实施例中，当业务表对应的更新操作为多个时，根据多个更新操作中的第一个更新操作和最后一个更新操作确定业务表处于新增状态、删除状态或修改状态。具体地，当第一个更新操作为新增操作、最后一个更新操作为新增操作或修改操作时，确定业务表处于新增状态；当第一个更新操作为删除操作或修改操作、最后一个更新操作为删除操作时，确定业务表处于删除状态；当第一个更新操作为删除操作或修改操作、最后一个更新操作为新增操作或修改操作时，确定业务表处于修改状态。需要说明的是，在实际应用中，当多个更新操作中的第一个更新操作为新增操作、最后一个更新操作为删除操作时，则确定业务表处于其他状态。由于业务表对应的第一个更新操作是新增操作，且该业务表对应的最后一个更新操作是删除操作，表明该业务表一开始在业务数据库中是不存在的，而最后在业务数据库中也不存在，该业务表不符合上述的新增状态、删除状态和修改状态中的任意一种，故本实施例中定义符合此情况的业务表处于其他状态。在一个示例中，服务器100在读取出预设采集状态表存放的所有业务表的名称和对应的更新操作后，将每个业务表对应的更新操作转换为状态数组(statuslist)，该状态数组中的每个元素表示一个更新操作，服务器100根据该状态数组中的第一个元素和最后一个元素可以解析出该业务表处于新增状态、删除状态、修改状态或其它状态。具体地，如果某个业务表对应的状态数组的第一个元素为新增操作，最后一个元素为新增操作或修改操作，则确定该业务表处于新增状态，例如statuslist：[add,……,add/modify]；如果某个业务表对应的状态数组的第一个元素为删除操作或修改操作，最后一个元素为删除操作，则确定该业务表处于删除状态，例如statuslist：[delete/modify,……,delete]；如果某个业务表对应的状态数组的第一个元素为删除操作或修改操作，最后一个元素为新增操作或修改操作，则确定该业务表处于修改状态，例如statuslist：[delete/modify,……,add/modify]；如果某个业务表对应的状态数组的第一个元素为新增操作，最后一个元素为删除操作，则确定该业务表处于其他状态，例如statuslist：[add,……,delete]。以图3所示的预设采集状态表为例，服务器100从数据源端200读取出该预设采集状态表后，将每个业务表对应的更新操作转换为状态数组，则可得到业务表table1对应的状态数组为statuslist1：[delete,add,modify,delete]，业务表table2对应的状态数组为statuslist2：[add,modify,modify,modify,modify]，业务表table3对应的状态数组为statuslist3：[delete,add]，业务表table4对应的状态数组为statuslist4：[add,delete]，业务表table5对应的状态数组为statuslist5：[add]。由于statuslist1的第一个元素为删除操作(delete)，最后一个元素为删除操作(delete)，则可确定业务表table1处于删除状态；statuslist2的第一个元素为新增操作(add)，最后一个元素为修改操作(modify)，则可确定业务表table2处于新增状态；statuslist3的第一个元素为删除操作(delete)，最后一个元素为新增操作(add)，则可确定业务表table3处于修改状态；statuslist4的第一个元素为新增操作(add)，最后一个元素为删除操作(delete)，则可确定业务表table4处于其他状态；statuslist5的第一个元素为新增操作(add)，最后一个元素为新增操作(add)，则可确定业务表table5处于新增状态。步骤s303，若业务表处于新增状态或修改状态，则根据业务表的名称从业务数据库中获取业务表的元数据信息。步骤s304，若业务表处于删除状态，则不从业务数据库中获取业务表的元数据信息。也即是说，服务器100在解析出预设采集状态表中的所有业务表的状态后，对于处于新增状态或者修改状态的业务表，直接根据业务表的名称从业务数据库中获取该业务表的元数据信息；对于处于删除状态或者其他状态的业务表，则不需要从业务数据库采集该业务表的元数据信息。如此，服务器100只需从业务数据库中获取处于新增状态及修改状态的业务表的元数据信息，对于处于删除状态、其他状态或者没有发生数据变化的业务表的元数据信息则不用从业务数据库中获取，实现了从业务数据库增量采集业务表的元数据信息，相比现有技术需从业务数据库采集最新的所有元数据信息的方式，可明显降低元数据信息的传输时间，提升元数据信息的采集效率；同时利用触发器监控业务数据库中业务表的数据变化情况并更新该预设采集状态表，服务器100只需根据预设采集状态表中的信息解析出业务表当前处于新增、删除或者修改状态，相比于现有技术中，省去了将业务数据库中所有业务表的元数据信息与元数据信息库中的所有业务表的元数据信息进行对比这一耗时步骤，从而降低了服务器100的处理时间。进一步地，服务器100在从业务数据库增量采集业务表的元数据信息后，还需要根据业务表的当前状态和业务表的元数据信息更新服务器100的元数据信息库。其中，对于处于不同状态的业务表，在元数据信息库中需要采用不同的更新策略。如图5所示，在图4的基础上，本实施例提供的信息采集方法还可以包括：步骤s305，若业务表处于删除状态，则根据业务表的名称在服务器存放的元数据信息库中将业务表删除。在本实施例中，对于处于删除状态的业务表，采用删除策略，即服务器100直接在元数据信息库中删除该业务表的元数据信息。此外，对于获取的处于新增状态的业务表的元数据信息，采用添加策略，即在元数据信息库中添加该业务表的元数据信息；对于获取的处于修改状态的业务表的元数据信息，采用覆盖策略，即用业务数据库中处于修改状态的业务表的元数据信息覆盖元数据信息库中对应业务表的元数据信息；对于处于其他状态的业务表，服务器100在元数据信息库中不做任何更新处理。为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种元数据信息采集装置的实现方式。请参照图6，为本申请实施例所提供的一种元数据信息采集装置的功能模块示意图。需要说明的是，本实施例所提供的元数据信息采集装置，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该元数据信息采集装置可应用于上述的服务器100，其包括读取模块410、状态确定模块420、信息获取模块430及信息更新模块440。该读取模块410用于从存放业务数据库的数据源端200读取预设采集状态表记录的业务数据库中发生数据变化的业务表的名称和业务表对应的更新操作；其中，业务表的名称和业务表对应的更新操作由数据源端200在监听到业务数据库中的业务表发生数据变化时，添加到预设采集状态表中。可以理解，该读取模块410可以执行上述步骤s301。该状态确定模块420用于根据业务表对应的更新操作确定业务表处于新增状态、删除状态或修改状态。在本实施例中，该状态确定模块420用于当业务表对应的更新操作为一个时，若所述更新操作为新增操作，则确定所述业务表处于新增状态；若所述更新操作为删除操作，则确定所述业务表处于删除状态；若所述更新操作为修改操作，则确定所述业务表处于修改状态；当业务表对应的更新操作为多个时，根据多个更新操作中的第一个更新操作和最后一个更新操作确定业务表处于新增状态、删除状态或修改状态。具体地，该状态确定模块420用于当第一个更新操作为新增操作、最后一个更新操作为新增操作或修改操作时，确定业务表处于新增状态；当第一个更新操作为删除操作或修改操作、最后一个更新操作为删除操作时，确定业务表处于删除状态；当第一个更新操作为删除操作或修改操作、最后一个更新操作为新增操作或修改操作时，确定业务表处于修改状态。可以理解，该状态确定模块420可以执行上述步骤s302。该信息获取模块430用于若业务表处于新增状态或修改状态，则根据业务表的名称从业务数据库中获取业务表的元数据信息，若业务表处于删除状态，则不从业务数据库中获取业务表的元数据信息。可以理解，该信息获取模块430可以执行上述步骤s303及步骤s304。该信息更新模块440用于若业务表处于删除状态，则根据业务表的名称在服务器100存放的元数据信息库中将业务表删除。此外，该信息更新模块440还用于若业务表处于新增状态，则在元数据信息库中添加该业务表的元数据信息，若业务表处于修改状态，则用业务数据库中处于修改状态的业务表的元数据信息覆盖元数据信息库中对应业务表的元数据信息，若业务表处于其他状态，则在元数据信息库中不做任何更新处理。可以理解，该信息更新模块440可以执行上述步骤s305。请参照图7，为本申请实施例提供的服务器100的一种结构框图。该服务器100包括存储器110、处理器120及通信模块130。存储器110、处理器120以及通信模块130各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。其中，存储器110用于存储程序或者数据。存储器110可以是，但不限于，随机存取存储器(randomaccessmemory，ram)，只读存储器(readonlymemory，rom)，可编程只读存储器(programmableread-onlymemory，prom)，可擦除只读存储器(erasableprogrammableread-onlymemory，eprom)，电可擦除只读存储器(electricerasableprogrammableread-onlymemory，eeprom)等。处理器120用于读/写存储器110中存储的数据或程序，并执行相应地功能。通信模块130用于通过网络建立服务器100与其他通信终端之间的通信连接，并用于通过网络收发数据。应当理解的是，图7所示的结构仅为服务器100的结构示意图，服务器100还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。图7中所示的各组件可以采用硬件、软件或其组合实现。本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器120执行时实现上述实施例所揭示的信息采集方法。综上所述，本申请实施例提供的信息采集方法、装置、服务器及计算机可读存储介质，数据源端通过监听业务数据库中业务表的数据变化情况，同时更新预设采集状态表；服务器从存放业务数据库的数据源端读取预设采集状态表记录的业务数据库中发生数据变化的业务表的名称和业务表对应的更新操作，该业务表的名称和业务表对应的更新操作由数据源端在监听到业务数据库中的业务表发生数据变化时，添加到预设采集状态表中，该服务器根据业务表对应的更新操作确定业务表处于新增状态、删除状态或修改状态，若业务表处于新增状态或修改状态，则根据业务表的名称从业务数据库中获取业务表的元数据信息，若业务表处于删除状态，则不从业务数据库中获取业务表的元数据信息。如此，服务器只需从业务数据库中获取处于新增状态及修改状态的业务表的元数据信息，对于处于删除状态或者没有发生数据变化的业务表的元数据信息则不用从业务数据库中获取，实现了从数据源端增量采集元数据信息，相比现有技术需从业务数据库采集最新的所有元数据信息的方式，有效降低了元数据信息的传输时间，从而提升了元数据信息采集效率；对于服务器来说，只需读取预设采集状态表并解析出业务表当前处于新增、删除或者修改状态，与现有技术相比，有效减少了大数据量下对新、老元数据信息进行对比这一耗时步骤，从而降低了服务器的处理时间。在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。当前第1页12当前第1页12