本申请涉及规则引擎技术领域，尤其涉及一种规则引擎系统及规则引擎的相关方法。
背景技术：
规则引擎由推理引擎发展而来，它可以将业务规则从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。规则引擎可以接收数据输入，解释业务规则，并根据业务规则做出业务决策。承载规则引擎的设备称为规则引擎服务器。
目前，规则引擎的一种实现方式为：在规则引擎服务器上预先设置与业务对应的业务规则；业务规则为一系列与业务对应的规则条件的组合。在规则引擎服务器接收业务规则中的规则条件对应的输入参数后，调用业务规则来对输入参数进行逻辑判断，从而获得规则结果(也即业务决策)。
例如，以“业务”为识别登录用户是否为正常用户为例，则可以预先在规则引擎服务器上设置与正常用户对应的业务规则；假设业务规则具有一个规则条件，该规则条件为：本次登陆地点与上次登陆地点一致(本次登录地＝＝上次登陆地点)。那么，规则引擎服务器可以接收输入参数：本次登录地点和上次登陆地点；然后调用操作符“＝＝”来判断本次登录地点和上次登陆地点是否一致，若一致则输出登录用户为正常用户(规则结果)。
通过上述对规则引擎服务器的描述可以发现，规则引擎服务器中具有与业务对应的业务规则，在每个业务规则中有一个或多个规则条件，每个规则条件都包括输入参数和/或常量(上述举例中的本次登陆地点和上次登录地点)和操作符(上述举例中的“＝＝”)。
在规则引擎服务器中进行逻辑判断的过程中必然会使用到操作符，但是规则引擎服务器一般仅提供固定数量的原生操作符，在实际应用过程中发现：规则引擎服务器提供的原生操作符已经不能满足多层次的用户需求。
因此现在需要一种方案，来更新规则引擎服务器中的操作符，以便满足多层次的用户需求。
技术实现要素：
目前规则引擎服务器中提供的原生操作符为：>(大于)、>＝(大于或等于)、<(小于)、<＝(小于或等于)、＝＝(等于)、！＝(不等于)、contains(包含)、notcontains(不包含)、memberof(在集合中)、notmemberof(不在集合中)、matches(匹配)、notmatches(不匹配)。
为了便于后续描述，将规则引擎服务器中容纳操作符的集合称为操作符集合，更新规则引擎服务器中操作符的过程，即为更新操作符集合的过程。
操作符由操作符名称和操作符的功能定义两部分组成，以操作符＝＝为例，操作符名称为“＝＝”，操作符的功能定义为操作符的左变量和右变量相等。在了解操作符的组成后，可以理解的是，更新规则引擎服务器中的操作符可以分为两种情况：
第一种情况：在操作符集合中增加原生操作符之外的新增操作符。
第二种情况：在操作符集合中更新原生操作符的功能定义。
下面分别对这两种情况进行举例说明：
第一种情况：在操作符集合中增加原生操作符之外的新增操作符。
例如，一个业务为“判断上海是否是一线城市”。
通常情况下，会采用原生操作符“memberof”来实现。此时业务规则中的规则条件为“上海memberof[北京,上海,广州,深圳]”；若输出的规则结果为“是”，则确定上海为一线城市。
但是，在这种情况下需要技术人员关心一线城市具体内容，并且，若将来一线城市有变化(例如将杭州添加至一线城市)则需要重新更新业务规则(上海memberof[北京,上海,广州,深圳，杭州])。该更新过程较为繁琐，不便于实际实现。
为此，技术人员提出一个自定义的操作符“namelistmatch”；其功能定义为“是否在名单库”。这样可以将[北京,上海,广州,深圳]抽象为一个整体并可以采用“一线城市”来命名。在该情况下，业务规则可以更新为“上海namelistmatch一线城市”。
这样，技术人员便可以不必关心一线城市的具体内容，只需要关心业务的规则逻辑(上海是否是一线城市)即可。一线城市的名单可以由专门的维护人员来维护。假设后续将天津、武汉、杭州加入一线城市，业务规则也不用变更。
在上述举例中可以发现自定义的操作符“namelistmatch”比原生操作符“memberof”更加方便，因此，可以将自定义的操作符“namelistmatch”更新至规则引擎服务器中。即，在操作符集合中增加原生操作符之外的新增操作符。
第二种情况：在操作符集合中更新原生操作符的功能定义。
例如，一个业务为判断本次交易金额与上次交易金额是否一致。
通常情况下会采用原生操作符＝＝，在规则引擎服务器中原生操作符＝＝的功能定义为左变量和右变量精确匹配，即操作符＝＝的左变量和右变量完全一致。因此，若本次交易金额为9.99，上次交易金额同样为9.99，则确定本次交易金额与上次交易金额一致。
若上次交易金额为9.992，则确定本次交易金额与上次交易金额不一致。但是，在对精度要求不高的应用场景下，本次交易金额9.99与上次交易金额9.992应被认为是一致的，但是原生操作符＝＝无法实现。
因此，在技术人员希望可以根据应用场景，更新原生操作符的功能定义，比如，可以更新原生操作符的适配精度，要求其适配到小数点后2点。那么在使用更新后操作符的情况下，本次交易金额9.99与上次交易金额9.992，则会被判定是一致的。
上述仅以两个具体实例来讲述更新规则引擎服务器中操作符的应用场景，可以理解的是还有其它应用场景，在此不再一一列举。
通过上述多层次需求可以发现，规则引擎服务器提供的原生操作符已经不能满足目前多层次的用户需求，因此需要更新规则引擎服务器中的操作符。鉴于此，本申请提供了更新规则引擎服务器中的操作符的方案，以便满足多层次的用户需求。
为了实现上述目的，本申请提供了以下技术手段：
一种动态更新操作符的方法，用于规则引擎服务器，规则引擎服务器利用加载器来加载操作符，包括：
在规则引擎服务器运行过程中，获取待更新操作符和用户标识；
对所述待更新操作符进行编译，得到编译后的待更新操作符；
利用新建加载器加载所述编译后的待更新操作符；
将所述编译后的待更新操作符，更新至与所述用户标识对应的操作符集合中。
优选的，操作符包括操作符名称和操作符的功能定义，则所述将所述编译后的待更新操作符、更新至与所述用户标识对应的操作符集合中，包括：
确定与所述用户标识对应的操作符集合；
判断所述操作符集合是否包含已有操作符；其中，所述已有操作符为与所述待更新操作符具有相同操作符名称的操作符；
若所述操作符集合包含所述已有操作符，则将所述待更新操作符的功能定义替换所述已有操作符的功能定义；
若所述操作符集合不包含所述已有操作符，则将所述待更新操作符添加至操作符集合中。
一种动态更新操作符的方法，用于规则引擎服务器，规则引擎服务器利用加载器来加载操作符，操作符包括操作符名称和操作符的功能定义，包括：
在规则引擎服务器运行过程中，获取待更新操作符和用户标识；
对所述待更新操作符进行编译，得到编译后的待更新操作符；
判断与所述用户标识对应的操作符集合中是否包含已有操作符；其中，所述已有操作符为与所述待更新操作符具有相同操作符名称的操作符；
若所述操作符集合中包含已有操作符，则利用新建加载器来加载所述待更新操作符，并将所述待更新操作符的功能定义替换所述已有操作符的功能定义；
若所述操作符集合中不包含已有操作符，则利用历史加载器来加载所述待更新操作符，将所述待更新操作符添加至所述操作符集合中；其中，历史加载器为加载过操作符的加载器。
一种动态更新操作符的方法，用于规则引擎服务器，规则引擎服务器利用加载器来加载操作符，包括：
在规则引擎服务器运行过程中，获取待更新操作符和用户标识；
对所述待更新操作符进行编译，得到编译后的待更新操作符；
在预设的多个历史加载器中确定出一个未加载所述待更新操作符的加载器，将该加载器作为目标加载器；其中，所述历史加载器为加载过操作符的加载器；
利用所述目标加载器来加载所述编译后的待更新操作符；
将所述编译后的待更新操作符，更新至与所述用户标识对应的操作符集合中。
优选的，操作符包括操作符名称和操作符的功能定义，则所述将所述编译后的待更新操作符、更新至与所述用户标识对应的操作符集合中，包括：
确定与所述用户标识对应的操作符集合；
判断所述操作符集合是否包含已有操作符；其中，所述已有操作符为与所述待更新操作符具有相同操作符名称的操作符；
若所述操作符集合包含所述已有操作符，则将所述待更新操作符的功能定义替换所述已有操作符的功能定义；
若所述操作符集合不包含所述已有操作符，则将所述待更新操作符添加至操作符集合中。
一种规则引擎系统，包括：
用户服务器，用于发送用户标识以及与业务对应的业务规则和上下文内容，并用于接收与业务对应的规则结果；
规则引擎服务器，用于接收所述用户服务器发送的用户标识、业务规则和上下文内容，并在与所述用户标识对应的操作符集合中获取所述业务规则中操作符的功能定义，在所述上下文内容中获取业务规则中输入参数的数据值，利用操作符的功能定义和输入参数的数据值来执行业务规则、并获得规则结果，将所述规则结果反馈至所述用户服务器。
一种规则引擎的执行方法，包括：
接收业务规则、上下文内容和用户标识；
在与所述用户标识对应的操作符集合中、获取所述业务规则中操作符的功能定义，并在所述上下文内容中、获取所述业务规则中输入参数的数据值；
利用所述操作符的功能定义和输入参数的数据值来执行所述业务规则，并获得规则结果。
优选的，规则引擎服务器包括组件池，所述组件池包括用于存储操作符的操作符集合，和，用于存储上下文内容中输入参数的变量池；组件池中的操作符和输入参数均称为组件；
则所述在与所述用户标识对应的操作符集合中、获取所述业务规则中操作符的功能定义，并在所述上下文内容中、获取所述业务规则中输入参数的数据值，包括：
将所述上下文内容添加至所述组件池的变量池中，并在所述业务规则中提取每个非常量字符，每个非常量字符称为一个组件；
针对每个组件均执行下述过程：
在所述组件池中与所述用户标识对应的操作符集合中查找组件，若在所述操作符集合中查找到组件，则确定该组件为操作符，并获取该操作符的功能定义，若未在所述操作符集合中查找到组件，则在所述变量池中查找组件，若在所述变量池中查找到组件，则确定该组件为输入参数，并获取该输入参数的数据值。
优选的，还包括：
若未在所述操作符集合中查找到组件且未在所述变量池中查找到组件，则执行异常处理过程。
优选的，还包括：
在获得规则结果后，反馈所述规则结果。
一种规则引擎系统，包括：
用户服务器，用于发送用户标识、业务标识以及与业务对应的上下文内容，并用于接收与业务对应的规则结果；
规则引擎服务器，用于接收所述用户服务器发送的用户标识、业务标识和上下文内容，在规则集合中获取与业务标识对应的业务规则，在与所述用户标识对应的操作符集合中获取所述业务规则中操作符的功能定义，在所述上下文内容中获取所述业务规则中输入参数的数据值，利用操作符的功能定义和输入参数的数据值来执行业务规则、并获得规则结果，将所述规则结果反馈至所述用户服务器。
一种规则引擎的执行方法，包括：
在接收用户标识、业务标识和上下文内容后，在规则集合中获取与业务标识对应的业务规则；
在与所述用户标识对应的操作符集合中获取所述业务规则中操作符的功能定义，在所述上下文内容中获取所述业务规则中输入参数的数据值；
利用所述操作符的功能定义和所述输入参数的数据值来执行业务规则、并获得规则结果。
一种规则引擎系统，包括：
用户服务器，用于发送原有业务规则、用户标识和各个上下文内容；
规则引擎服务器，用于利用各个上下文内容以及与所述用户标识对应的操作符集合执行所述原有业务规则并获得规则结果的过程中，记录各个上下文内容对应的规则结果以及每个业务规则中各个规则条件的条件结果，对各个条件结果和预先设定的规则结果进行关联性分析，将与规则结果具有关联性的条件结果对应的规则条件的组合、确定为优化后的业务规则；还用于将优化后的业务规则发送至所述用户服务器。
一种规则引擎系统，包括：
用户服务器，用于发送业务标识、用户标识和各个上下文内容；
规则引擎服务器，用于在利用各个上下文内容以及与所述用户标识对应的操作符集合、执行规则集合中与业务标识对应的原有业务规则并获得规则结果的过程中，记录各个上下文内容对应的规则结果以及每个业务规则中各个规则条件的条件结果，对各个条件结果和预先设定的规则结果进行关联性分析，将与规则结果具有关联性的条件结果对应的规则条件的组合、确定为优化后的业务规则；还用于将优化后的业务规则动态更新至规则集合中、替换与所述业务标识对应的原有业务规则。
一种业务规则的优化方法，包括：
记录各个上下文内容对应的规则结果以及每个业务规则中各个规则条件的条件结果；
对各个条件结果和预先设定的规则结果进行关联性分析；
将与规则结果具有关联性的条件结果对应的规则条件的组合、确定为优化后的业务规则。
通过以上技术手段，可以实现以下有益效果：
本申请在规则引擎服务器运行过程中更新操作符集合，即本申请可以动态更新规则引擎服务器中的操作符集合，这样可以避免在更新操作符集合的过程中停止规则引擎服务器，从而可以提高规则引擎服务器的执行效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请提供的一种规则引擎系统的示意图；
图2为本申请提供的又一种规则引擎系统的示意图；
图3a-3c为本申请提供的一种动态更新操作符的方法的流程图；
图4为本申请提供的又一种动态更新操作符的方法的流程图；
图5a-5b为本申请提供的一种规则引擎的执行方法的流程图；
图6为本申请提供的又一种规则引擎的执行方法的流程图；
图7a-7b为本申请提供的又一种规则引擎系统的示意图；
图8为本申请提供的一种业务规则的优化方法的流程图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
术语定义
规则引擎服务器，用于提供规则引擎服务的服务器，并且，可以向其它服务器以租用服务器的方式提供规则引擎服务。
用户服务器，在本申请中租用规则引擎服务器的公司称为用户，那么租用规则引擎服务器的公司所使用的服务器称为用户服务器。
操作符，在指令系统的每一条指令都有一个操作符，它表示该指令应进行什么性质的操作。在本申请中操作符位于业务规则中。并且，操作符具体包括操作符名称和功能定义。操作符集合，表示一个或多个操作符的集合。
编译，利用编译程序从源语言编译的源程序产生目标程序的过程。即，将高级语言编译成计算机可以识别的二进制语言。
编译操作符操作，用于对将待更新操作符编译成便于机器识别的机器语言的过程。
持久层，为设备的数据库、本机硬盘等存储空间；持久层中的数据在设备掉电后不会丢失，因此将其称为持久层。
加载，用于将持久层上的有用程序调到内存中的过程。
加载操作符操作，用于将操作符从持久层加载到内存中的过程。
加载器，为设备中的一段软件程序，其作用在于，将数据从持久层运输到内存中。
历史加载器，已经加载过操作符的加载器。
新建加载器，未加载过操作符的加载器。
用户标识，用于规则引擎服务器对外提供规则引擎租赁服务，多个用户可以均享受规则引擎服务器提供的规则引擎服务。因此，规则引擎服务器会采用用户标识来表示各个用户。操作符集合，一系列操作符的集合，在本申请中操作符集合可位于规则引擎服务器内存中，操作符集合又称为操作符容器。
规则集合，一系列规则的集合，在本申请中规则集合可位于规则引擎服务器内存中，规则集合又称为规则容器。
现有技术中规则引擎服务器针对操作符有两种常见的处理方式：
第一种处理方式：固定数量的原生操作符，无法更改。
第二种处理方式：可以更新操作符，但是需要将待更新操作符和原生操作符重新部署至内存的操作符集合中。
在现有技术中，规则引擎服务器中仅有一个初始化加载器，规则引擎服务器必须利用该初始化加载器，来加载原生操作符至操作符集合中。
通过前述内容可知，更新操作符集合具有两种情况：第一种情况，在操作符集合中增加原生操作符之外的新增操作符。第二种情况：在操作符集合中更新原生操作符的功能定义。
针对第二种情况，由于加载器自身的协议决定：加载器在加载一个操作符后，该加载器便会记录下该操作符的功能定义，后续再次采用该加载器加载相同操作符名称的操作符时，即便操作符的功能定义发生改变，该加载器也仅仅只能加载该操作符已经记录下来的功能定义，无法加载新的功能定义。
由于现有技术中规则引擎服务器的机制限制，其上仅有一个初始化加载器。因此，仅能使用初始化加载器来加载待更新操作符。因此，现有技术中为了保证规则引擎服务器可以对原生操作符的功能定义进行更新，所以会重新启动规则引擎服务器，以便初始化加载器内已经记载的功能定义被清除，变成空白的加载器。然后，再利用初始化加载器加载待更新操作符和原生操作符，在加载完成后，在重新启动规则引擎服务器，以便重新开始规则引擎服务。
由于现有技术中，在更新操作符过程中需要暂定规则引擎服务，所以，现有技术会降低规则引擎服务器的执行效率。
为了解决现有技术的问题，本申请提供了一种更新操作符的方法，以便在不停止规则引擎服务器的情况下更新操作符集合，即动态更新操作符。
为了便于本领域技术人员更加清楚了解本申请的应用场景，首先介绍本申请提供的规则引擎系统。
参见图1，为本申请提供的规则引擎系统的实施例一。规则引擎系统具体包括：用户服务器100，与用户服务器100相连的规则引擎服务器200。规则引擎系统还可以包括与规则引擎服务器200相连的规则客户端300。在实施例一中，规则引擎服务器从用户服务器接收待更新操作符。
用户服务器100与一个用户对应，用户标识用于表示用户。用户服务器100中存储有表示用户的用户标识。例如，以用户为“a贸易公司”为例，用户标识为标识a，用户服务器a存储有表示“a贸易公司”的标识a。
用户服务器100可以使用规则引擎服务器200提供的规则引擎服务。在使用过程中，用户服务器100若发现规则引擎服务器200中的操作符已经不能满足自身需求时，用户服务器100可以根据用户需求构建一个待更新操作符。(根据用户需求构建待更新操作符的过程可以采用现有技术完成，在此不再赘述)
然后，用户服务器100可以将待更新操作符和用于表示用户的用户标识发送至规则引擎服务器200。规则引擎服务器200，用于将待更新操作符更新至与用户标识对应的操作符集合中。(详细解释将在后续实施例中进行详细描述)。
参见图2，为本申请提供的规则引擎系统的实施例二。在实施例二中，规则引擎服务器从规则客户端接收待更新操作符。规则引擎系统具体包括：用户服务器100，与用户服务器100相连的规则引擎服务器200，以及，与规则引擎服务器200相连的规则客户端300。
一般规则引擎的提供商采用计算机(即规则客户端)来对规则引擎服务器200进行维护。在规则引擎服务器200运行过程中，维护人员若发现规则引擎服务器200中的操作符已经不满足用户需求时，规则客户端300可以根据用户需求构建待更新操作符。然后，规则客户端300可以将待更新操作符发送至规则引擎服务器200。
规则引擎服务器200，用于将待更新操作符更新至与用户标识对应的操作符集合中(详细解释将在后续实施例中进行详细描述)。
上述仅提供规则引擎服务器200获取待更新操作符的两种实现方式，可以理解的是，规则引擎服务器200还可以采用其它方式来获取待更新操作符。本申请不限定规则引擎服务器200获取待更新操作符的方式。
下面介绍规则引擎服务器将待更新操作符更新至操作符集合的过程。
规则引擎服务器在获得待更新操作符和用户标识后，会存储在规则引擎服务器的持久层。持久层为数据库、本机硬盘等存储空间，操作符集合位于规则引擎服务器内存中。因此，需要采用编译和加载的步骤将待更新操作符更新至操作符集合中。
本申请为了提高规则引擎系统的效率采用动态加载待更新操作符的方案。即，在将待更新操作符更新至操作符集合的过程中不再停止规则引擎服务器，而是保持规则引擎服务器处于运行状态。
本申请提供三种动态加载操作符的方法，下面分别对三种加载方式进行详细描述。
第一种加载方式：利用重新构建的加载器来加载待更新操作符。
本申请提供了一种动态更新操作符的方法的实施例一，如图3a所示，具体包括以下步骤：
步骤s311：在规则引擎服务器运行过程中、获取待更新操作符和用户标识，对所述待更新操作符进行编译，得到编译后的待更新操作符。
规则引擎服务器可以通过多种方式获取待更新操作符和用户标识。在获取待更新操作符之后，对待更新操作符进行编译。对待更新操作符进行编译的目的在于，将待更新操作符编译成便于机器识别的机器语言。
步骤s312：利用新建加载器加载所述编译后的待更新操作符。
本实施例中在接收待更新操作符之后，为了保证可以适用于对原生操作符的功能定义进行更新的情况，因此规则引擎服务器放弃使用初始化加载器来加载待更新更操作符，而是会重新构建一个加载器，将重新构建的加载器称为新建加载器。即，在本实施例中规则引擎服务器针对每个待更新操作符均构建一个加载器，这样各个操作符均使用重新构建的加载器来加载操作符。
利用新建加载器来加载待更新操作符，由于新建加载器并没有加载过任何操作符，所以新建加载器适用于对原生操作符的功能定义的更新，不会出现无法加载原生操作符功能定义的情况。此外，新建加载器还适用于对新增操作符的更新。
本实施例中，规则引擎服务器可以将重新构建加载器的过程可以在步骤s311之前执行。这样，在规则引擎服务器接收待更新操作符后、便可以直接使用预先已经生成的新建加载器来加载待更新操作符。
当然，本实施例中重新构建加载器的过程也可以在步骤s311和步骤s312之间执行。即，规则引擎服务器在接收待更新操作符之后，再实时构建新建加载器，并利用新建加载器来加载待更新操作符。
由于新建加载器在加载过待更新操作符后便变成历史加载器。本实施例中不再使用历史加载器，因此在本步骤后可以删除新建加载器，以免占用服务器资源。
步骤s313：将所述编译后的待更新操作符、更新至与所述用户标识对应的操作符集合中。
操作符由操作符名称和操作符的功能定义两部分组成，更新操作符集合具有两种情况，第一种情况：增加原生操作符之外的新增操作符，第二种情况：更新原生操作符的功能定义。
规则引擎服务器在获得待更新操作符后，并不确定待更新操作符属于上述两种情况的哪一种。若为第一种情况，则在与用户标识对应的操作符集合中不具有待更新操作符，若为第二种情况，则在与用户标识对应的操作符集合中已经具有待更新操作符，只是功能定义不同。
为了保证与用户标识对应的操作符集合中操作符的唯一性，规则引擎服务器在将待更新操作符更新至操作符集合的过程中，会执行如下述判断过程。
如图4所示，具体包括以下步骤：
步骤s401：确定与所述用户标识对应的操作符集合。
规则引擎服务器的提供商可以采用服务器租用方式、来向其它服务器(为了与规则引擎服务器进行区分、后续简称为用户服务器)来提供服务器租用业务。用户服务器可以调用规则引擎服务器提供的应用程序接口，来享受规则引擎服务器提供的规则引擎服务。
由于规则引擎服务器可以向多个用户服务器提供规则引擎服务，每个用户服务器对同一个操作符的功能定义可能是不同的。例如，用户服务器1要求操作符＝＝的功能定义为左变量和右变量精确匹配，而用户服务器2要求操作符＝＝的功能定义为左变量和右变量模糊匹配。
因此，为了满足各个用户服务器对操作符的需求，本申请中在规则引擎服务器为每个用户服务器设置一个操作符集合。并且，规则引擎服务器为每个用户设置一个用户标识，并构建用户标识与该用户服务器对应的操作符集合之间的对应关系，以便后续使用。
例如，“a贸易公司”的用户服务器a、“b钢铁公司”的用户服务器b和“c物流公司”的用户服务器c，均租用阿里巴巴提供的规则引擎服务器，则阿里巴巴的规则引擎服务器，可以为“a贸易公司”设置标识a，并将标识a与用户服务器a建立对应关系，然后，将标识a发送至用户服务器a，以便其得知自身在规则引擎服务器的标识。
因此，规则引擎服务器可以通过预先构建的对应关系，在众多操作符集合中查找与用户标识对应的操作符集合，即与用户服务器对应的操作符集合。
步骤s402：判断所述操作符集合是否包含已有操作符；其中，所述已有操作符为与所述待更新操作符具有相同操作符名称的操作符。若是，则进入步骤s403，若否，则进入步骤s404。
步骤403：若所述操作符集合包含所述已有操作符，则将所述待更新操作符的功能定义替换所述已有操作符的功能定义。
步骤s404：若所述操作符集合不包含所述已有操作符，则将所述待更新操作符添加至操作符集合中。
本实施例可以解决对原生操作符的功能定义进行更新的情况，并且，本实施例可以动态加载操作符而不需暂停规则引擎服务器，因此，本实施例可以提高规则引擎服务的执行效率。
本实施例的缺陷在于，在每次更新操作符时均需要重新构建加载器这个过程、较为繁琐。为此，本申请提供了第二种加载方式。
第二种加载方式：依据待更新操作符决定加载器的方式。
本申请提供了一种动态更新操作符的方法的实施例二，如图3b所示，具体包括以下步骤：
步骤s321：在规则引擎服务器运行过程中、获取待更新操作符和用户标识，对所述待更新操作符进行编译，得到编译后的待更新操作符。
步骤s322：判断与所述用户标识对应的操作符集合中是否包含已有操作符；其中，所述已有操作符为与所述待更新操作符具有相同操作符名称的操作符；若有，进入步骤s323，若无，则进入步骤s325。
规则引擎服务器可以通过预先构建的对应关系，在众多操作符集合中查找与用户标识对应的操作符集合，即与用户服务器对应的操作符集合。
由于与用户标识对应的操作符集合在内存中，所以规则引擎服务器可以从内存中获取该操作符集合中的操作符。然后判断操作符集合中是否有与待更新操作符名称一致的已有操作符。
若无，则判定操作符集合中不具有待更新操作符，本次更新为向操作符集合中新增操作符。因此，可以采用历史加载器来加载待更新操作符。
若有，则判定操作符集合中具有待更新操作符，本次更新为更新已有操作符的功能定义。为了避免出现历史加载器无法加载待更新操作符的功能定义的情况，可以利用新建加载器来加载待更新操作符。
步骤s323：若所述操作符集合中包含已有操作符，则利用新建加载器来加载所述待更新操作符。
步骤s324：在所述操作符集合中、将所述待更新操作符的功能定义替换所述已有操作符的功能定义。
若所述操作符集合中包含已有操作符，则首先利用新建加载器加载所述待更新操作符到内存中，然后，规则引擎服务器会在与用户标识对应的操作符集合中、将所述待更新操作符的功能定义替换所述已有操作符的功能定义。
步骤s325：若所述操作符集合中不包含已有操作符，则利用历史加载器来加载所述待更新操作符。
步骤s326：将待更新操作符添加至操作符集合中。
若所述操作符集合中不包含已有操作符，则首先利用历史加载器加载所述待更新操作符到内存中，然后，规则引擎服务器直接将待更新操作符添加至与用户标识对应的操作符集合中。
在本实施例二中，针对向操作符集合中新增操作符情况，可以采用历史加载器来加载待更新操作符；针对更新操作符集合中已有操作符的功能定义的情况，可以采用新建加载器来加载待更新操作符。即，针对不同的情况采用不同的加载器，以便减少新建加载器的数量。
因此，本实施例二中不会过多建立新建加载器，浪费服务器资源；还可以保证能够适用于更新已有操作符的功能定义的情况。因此，具有较高的适用性。但是，本方式需要更新规则引擎服务器的已有的处理逻辑，在实际应用过程中，可能有诸多不便。
上述两种加载方式可以适用于更新操作符的两种情况，下面提供第三种加载方式，本加载方式仅适用于更新操作符的第一种情况：增加原生操作符之外的新增操作符。
第三种加载方式：利用历史加载器来加载待更新操作符。
本申请提供了一种动态更新操作符的方法的实施例三，如图3b所示，具体包括以下步骤：
步骤s331：在规则引擎服务器运行过程中、获取待更新操作符和用户标识，对所述待更新操作符进行编译，得到编译后的待更新操作符。
在获取待更新操作符之后，对待更新操作符进行编译。对待更新操作符进行编译的目的在于，将待更新操作符编译成便于机器识别的机器语言。
步骤s332：在预设的多个历史加载器中确定出一个未加载所述待更新操作符的加载器，将该加载器作为目标加载器；其中，所述历史加载器为加载过操作符的加载器。
由于现有技术中仅有一个初始化加载器，初始化加载器加载过操作符，所以初始化加载器为历史加载器，即，现有技术中仅有一个历史加载器。因此，在加载待更新操作符时必然需要使用该历史加载器(初始化加载器)，因此，现有技术中必须重新启动规则引擎服务器，来更新初始化加载器，使得初始化加载器上已经记载的功能定义被清除。
为此，本申请可以预先设定多个历史加载器，可以理解的是，各个历史加载器上加载过的操作符不尽相同。这样，规则引擎服务器可以在多个历史加载器中进行选择，选择的目的在于选择出一个未加载过待更新操作符的加载器作为目标加载器。
由于目标加载器未加载待更新操作符，所以，目标加载器上未记载待更新操作符的功能定义。因此，即便目标加载器为历史加载器，也可以适用于第二情况(更新原生操作符的功能定义)下加载操作符的目的。
历史加载器可以为加载原生操作符的初始化加载器，还可以为已经加载其它新增操作符的加载器。规则引擎服务器可以调用历史加载器，来将位于持久层的编译后的待更新操作符、加载到内存中。
步骤s333：将所述编译后的待更新操作符、更新至与所述用户标识对应的操作符集合中。
在本实施例规则引擎服务器采用历史加载器来加载编译后的待更新操作符。由于历史加载器是预先已经生成的、所以可以免去生成加载器的过程，所以本实施例可以提高加载操作符的效率。
但是，本实施例仅适用于更新原生操作符之外的新增操作符，对于更新原生操作符的功能定义的情况不适用。
上述三种动态加载方式各有利弊，在实际使用过程中可以结合应用场景来决定使用具体的实现方式。
通过上述提供动态更新操作符的方法，本申请可以在规则引擎服务器运行过程中更新操作符集合，即本申请可以动态更新规则引擎服务器中的操作符集合，这样可以避免在更新操作符集合的过程中停止规则引擎服务器，从而可以提高规则引擎服务器的执行效率。
在现有技术中规则引擎设备为静态更新操作符，在更新操作符的过程不执行规则引擎服务。本申请提供的方案为动态更新操作符的方法，在动态更新操作符的过程，规则引擎服务器可以执行规则引擎服务。
下面介绍规则引擎服务器在动态加载操作符的过程中，规则引擎服务的执行过程。
由于操作符集合中的操作符在规则引擎服务器中已经具有预先设定的功能定义，因此操作符集合中的操作符属于保留关键字。在业务规则中既包括操作符(保留关键字)又包括输入参数(也即变量，非保留关键字)。因此，在业务规则中涉及的输入参数的名称应该避免与保留关键字的名称一致，以免在执行规则引擎服务的过程中产生冲突。
规则引擎服务器中对操作符的现有的两种处理方式为：第一种方式：固定数量的原生操作符，无法更改。第二种处理方式：可以更新操作符，但是需要将待更新操作符和原生操作符重新部署至内存的操作符集合中。
针对现有的处理方式规则引擎服务器在初始化时便已经得知原生操作符和待更新操作符，并可以得知其为系统保留关键字。因此，规则引擎服务器可以在执行业务规则的过程中可以自动识别出操作符(即自动识别保留关键字)。
通过前述内容可知，本申请中动态更新操作符集合中的操作符具有两种情况：第一种情况：在操作符集合中增加原生操作符之外的新增操作符，第二种情况：在操作符集合中更新原生操作符的功能定义。
在规则引擎服务器中已经将原生操作符记录为保留关键字，因此，针对第二种情况，仅仅是更新原生操作符的功能定义，不会更改保留关键字。但是针对第一种情况，在将操作符集合中增加待更新操作符之后，待更新操作符则变成保留关键字。
理论上规则引擎服务器应该将待更新操作符记录为保留关键字。但是，在动态加载待更新操作符的过程中，规则引擎服务器无法将待更新操作符记录为保留关键字。在这种情况下，规则引擎服务器可能会将待更新操作符误识为输入参数。
为了使得规则引擎服务器顺利执行业务规则，避免将待更新操作符误识为输入参数，本申请提出构建一个组件池。组件池包括两类寄存器：一类寄存器为存储操作符的操作符集合，另一类寄存器为存储业务规则中输入参数的变量池。组件池中的操作符和输入参数均称为组件。
本申请提供的技术手段为：将业务规则中非常量字符(也即操作符和输入参数)均一视同仁称为组件，并设定组件池中操作符集合的优先级大于变量池的优先级。
本申请在不确定业务规则中的组件为操作符或输入参数的情况下，首先在组件池的操作符集合中查询组件，若查找到则说明该组件为操作符；若在操作符集合中未查找到才在变量池中查找组件，若查找到则说明该组件为输入参数。
本申请设置操作符集合的优先级大于变量池优先级的目的在于，在操作符集合和变量池中均有组件的情况下，将组件确定为操作符；以便实现操作符的功能定义。
下面详细说明规则引擎服务器的规则引擎的执行过程。规则引擎服务器提供规则引擎服务可以有两种方式：
第一种方式为：规则引擎服务器仅提供逻辑判断功能，在此情况下规则引擎服务器接收用户服务器提供的业务规则，规则引擎服务器来执行业务规则。
第二种方式为：规则引擎服务器既提供业务规则又提供逻辑判断功能。在此情况下，规则引擎服务器预先存储了与业务对应的业务规则。为了便于区分业务规则，可以为业务设置业务标识，并构建业务标识与业务规则的对应关系。
与上面两种方式对应的本申请提供了规则引擎服务的两种实现方式，下面对两种实现方式分别进行说明：
第一种实现方式：用户服务器使用自己提供的业务规则。
参见图5a所示，本申请提供了一种规则引擎的执行方法的具体实施例，具体包括以下步骤：
步骤s501：接收业务规则、上下文内容和用户标识。
用户服务器可以调用规则引擎服务器提供的应用程序接口，并将规则引擎服务器发送业务规则，以便规则引擎服务器得知业务规则；还向规则引擎服务器发送与业务规则相关的上下文内容，上下文内容中包含业务规则中输入参数；还用于向规则引擎服务器发送用户标识，以便规则引擎服务器得知业务规则中操作符所在的操作符集合。
例如，用户服务器的业务判断用户登录是否异常，确定用户登录正常的业务规则中的一个规则条件为nowaddress(本次登陆地点)＝＝hisaddress(上次登录地点)。那么，用户服务器在判断用户登录是否异常时，会将业务规则“nowaddress＝＝hisaddress”，上下文内容“nowaddress＝北京”以及“hisaddress＝杭州”和用户标识发送至规则引擎服务器。
例如，用户服务器的业务为判断用户是否属于成人，确定用户属于成人的业务规则中的一个规则条件为“age(用户年龄)＞18”。那么，用户服务器在判断用户是否属于成人时，会将业务规则“age＞18”，上下文内容“age＝16”和用户标识发送至规则引擎服务器。
步骤s502：在与所述用户标识对应的操作符集合中、获取所述业务规则中操作符的功能定义，并在所述上下文内容中、获取所述业务规则中输入参数的数据值。
参见图6所示，本步骤具体包括以下内容：
步骤s601：将所述上下文内容添加至所述组件池的变量池中，并在所述业务规则中提取每个非常量字符，每个非常量字符称为一个组件。
规则引擎服务器中具有容纳业务规则的规则集合，所以，规则引擎服务器在接收业务规则后，可以将其添加至规则集合中，并将上下文内容加至组件池中的输入参数池中。
在规则集合中获取业务规则，每个业务规则由一个或多个规则条件组成，每个规则条件具有输入参数和操作符，有的规则条件中还具有常量。规则引擎服务器可以在业务规则中提取每个规则条件中的非常量字符，即提取业务规则中的输入参数和操作符，由于规则引擎服务器暂时不确定组件为操作符或输入参数，所以规则引擎服务器将所有的非常量字符一视同仁，即均先将其视为组件。
延续上述举例，将业务规则“nowaddress＝＝hisaddress”添加至规则集合中，将上下文内容“nowaddress＝北京”以及“hisaddress＝杭州”添加至输入参数池中。并将业务规则“nowaddress＝＝hisaddress”中的“nowaddress”、“＝＝”和“hisaddress”均视为组件。
例如，将业务规则“age＞18”添加至规则集合中，将上下文内容“age＝16”添加至输入参数池中。将业务规则“age”和“＞”视为组件。业务规则中的常量“18”具有明确定义，无需视为组件。
然后，针对每个组件均执行下述步骤s602-步骤s606：
步骤s602：在所述组件池中与所述用户标识对应的操作符集合中查找组件。若在所述操作符集合中查找到组件，则进入步骤s603，若未在所述操作符集合中查找到组件，则进入步骤s604。
规则引擎服务器首先在组件池的操作符集合中进行查找。若在操作符集合中查找到组件，则确定该组件属于操作符并获取其功能定义，即确定该组件属于保留关键词。
若未在操作符集合中查找到组件，则确定该组件不属于操作符，在组件池的变量池中继续查找组件。
步骤s603：若在所述操作符集合中查找到组件，则确定该组件为操作符，并获取该操作符的功能定义。
例如，组件“＝＝”在操作符集合中查找到功能定义，而“nowaddress”和“hisaddress”均未查找到功能定义，则继续在变量池中查找“nowaddress”和“hisaddress”。
例如，组件“＞”在操作符集合中查找到功能定义，而“age”未查找到功能定义，则继续在变量池中查找“age”。
步骤s604：若未在所述操作符集合中查找到组件，则在所述变量池中继续查找该组件。
步骤s605：若在所述变量池中查找到组件，则确定该组件为输入参数，并获取该输入参数的数据值。
若在输入参数池中查找到该组件，则确定该组件为输入参数，在变量池的上下文内容中查找输入参数的数据值。
例如，在变量池中查找到“nowaddress”和“hisaddress”的组件，则进一步在变量池的上下文内容中查找“nowaddress”的数据值为“北京”，以及“hisaddress”的数据值为“杭州”。
例如，在变量池中查找到“age”的组件，则在变量池中查找“age”的数据值为“16”。
步骤s606：若未在所述操作符集合中查找到组件且未在所述变量池中查找到组件，则执行异常处理过程。
理论上来说，业务规则中所有非常常量字符，均可以在组件池中查找到组件定义。若未在操作符集合中查找到组件的定义，也未在输入参数池中查找到组件的定义，则确定该组件出现异常，执行异常处理过程。该部分过程不是本申请的执行重点，在此不再赘述。
接着返回图5，进入步骤s503：利用所述操作符的功能定义和输入参数的数据值来执行所述业务规则，并获得规则结果。
业务规则中的各个组件均已经找到的情况下，可以将输入参数的数据值代入业务规则中，并根据操作符的功能定义来执行业务规则，从而获得规则结果。
例如，将“nowaddress＝北京”以及“hisaddress＝杭州”代入至业务规则“nowaddress＝＝hisaddress”中，即获得“北京＝＝杭州”；“＝＝”的功能定义为左变量与右变量相同。经过判断发现左变量与右变量不同，则确定规则结果为否，即用户登录异常。
例如，将“age＝16”代入业务规则“age＞18”中，“＞”的含义为左变量大于右变量，经过判断发现左变量不大于右变量，则确定规则结果为否，即用户不属于成人。
步骤s504：将规则结果反馈至用户服务器。
规则引擎服务器在经过逻辑判断后获得规则结果，可以将规则结果反馈至用户服务器，以便用户服务器获得规则结果。
第二种实现方式：用户服务器使用规则引擎提供的业务规则。
参见图5b所示，本申请提供了一种规则引擎的执行方法的具体实施例，具体包括以下步骤：
步骤s511：在接收用户标识、业务标识和上下文内容后，在规则集合中获取与业务标识对应的业务规则。
用户服务器向规则引擎服务器发送用户标识和上下文内容，与步骤s501不同的是，用户服务器发送的是业务标识而不是业务规则。这样规则引擎服务器在接收业务标识后，可以在规则集合中的众多业务规则中查找与业务标识对应的业务规则，以便基于业务规则来执行后续过程。
步骤s512：在与所述用户标识对应的操作符集合中获取所述业务规则中操作符的功能定义，在所述上下文内容中获取所述业务规则中输入参数的数据值。
由于业务规则是规则引擎服务器预存储的，所以，规则引擎服务器已经预先得知业务规则中的操作符名称和变量名称。因此，业务规则服务器可以直接提取业务规则中的操作符名称，并在操作符集合中获取操作符名称的功能定义；然后，可以直接提取业务规则中的变量名称，并在上下文内容中获取变量名称的具体数据值。
步骤s513：利用所述操作符的功能定义和所述输入参数的数据值来执行业务规则、并获得规则结果。
步骤s514：将规则结果反馈至用户服务器。
步骤s512-步骤s514的执行过程与步骤s502-步骤s504的执行过程一致，在此不再赘述。
本申请在动态更新操作符的过程中，可以执行规则引擎服务。在规则引擎服务的执行过程中，采用组件池的方式来区分出业务规则中的操作符和输入参数，从而可以保证规则引擎服务器准确的执行业务规则。
上述为规则引擎服务器利用业务规则执行规则引擎服务的过程，本申请发明人在研究过程中发现：业务规则包括一个或多个规则条件，规则引擎服务器依据业务规则中的各个规则条件来进行业务判断、从而获得业务对应的规则结果。
具体而言，规则引擎服务器会将输入参数与其中一个规则中各个规则条件进行对比。若输入参数符合一个规则条件，则该规则条件的条件结果为是，若输入参数不符合一个规则条件，则该规则条件的条件结果为否。只有输入参数满足一个规则中的所有规则条件的情况下，则确定规则结果为确认结果。
例如，以业务为判断路人是否属于妇女。已有的业务规则可以包括两个规则，第一个规则：年龄>18且性别＝女且有同伴且同伴年龄>18(结伴而行年龄均大于18的女性)。第二个规则：年龄>35且性别＝女且有同伴且同伴年龄<12(结伴而行一位妈妈带一个孩子)。
当输入参数满足第一个规则中的所有规则条件时，或者，满足第二个规则中的所有规则条件时，则规则结果为确认结果，即确认路人属于妇女。
可以理解的是，若想保证业务的具有准确结果，需要保证业务规则的准确性。但是，在实际应用中技术人员发现，业务规则中的规则条件大多数为人为定义的条件，所以业务规则具有一定不准确性，这会导致利用业务规则确定的规则结果也具有一定的不准确性。
延续上述举例，在实际应用中发现，上述业务规则不太合理。因为上述规则未考虑单独一个人的情况，且，对同伴年龄有要求。理论上，不论是单独一个人还是结伴而行，只要其中有一个人属于妇女，则可以确定该组人员属于妇女。因此，可以对原有规则进行优化得到新的业务规则“性别＝女且年龄>18”(仅作为举例说明，不代表实际情况)。
为此，本申请提供了一种方案来确定优化已有的业务规则，以便获得准确的业务规则，从而获得准确的规则结果。
申请人在研究优化业务规则的过程中发现：业务规则中的条件结果与规则结果具有一定的关联性，与预先设定的规则结果具有较高关联性的条件结果，其对应的规则条件是准确的。与规则结果具有较低关联性的条件结果，其对应的规则条件是不准确的。通过条件结果和规则结果的关联性可以来优化已有业务规则。
如图7a所示，本申请提供了一种规则引擎系统。具体包括：
客户服务器100，用于发送原有业务规则、用户标识和各个上下文内容；
规则引擎服务器200，用于利用各个上下文内容以及与所述用户标识对应的操作符集合执行所述原有业务规则并获得规则结果的过程中，记录各个上下文内容对应的规则结果以及每个业务规则中各个规则条件的条件结果，对各个条件结果和预先设定的规则结果进行关联性分析，将与规则结果具有关联性的条件结果对应的规则条件的组合、确定为优化后的业务规则；还用于将优化后的业务规则发送至所述用户服务器。
图7a所示的规则引擎系统中，利用各个上下文内容以及与所述用户标识对应的操作符集合执行所述原有业务规则并获得规则结果的过程可以详见图5a所示的规则引擎系统。在此不再赘述。
相对于图5a所示的规则引擎系统而言，规则引擎服务器还用于执行确定优化后业务规则的过程，并将优化后的业务规则发送至用户服务器。
如图7b所示，本申请还提供了一种规则引擎系统，包括：
客户服务器100，用于发送业务标识、用户标识和各个上下文内容；
规则引擎服务器200，用于在利用各个上下文内容以及与所述用户标识对应的操作符集合、执行规则集合中与业务标识对应的原有业务规则并获得规则结果的过程中，记录各个上下文内容对应的规则结果以及每个业务规则中各个规则条件的条件结果，对各个条件结果和预先设定的规则结果进行关联性分析，将与规则结果具有关联性的条件结果对应的规则条件的组合、确定为优化后的业务规则；还用于将优化后的业务规则动态更新至规则集合中、替换与所述业务标识对应的原有业务规则。
图7b所示的规则引擎系统中，利用利用各个上下文内容以及与所述用户标识对应的操作符集合、执行规则集合中与业务标识对应的原有业务规则并获得规则结果的过程可以详见图5b所示的规则引擎系统。在此不再赘述。
相对于图5b所示的规则引擎系统而言，规则引擎服务器还用于执行确定优化后业务规则的过程，并将优化后的业务规则动态更新至规则集合中、替换与所述业务标识对应的原有业务规则。
下面介绍规则引擎服务器具体优化原有业务规则的具体执行过程：
如图8所示，本申请提供了一种业务规则的优化方法，具体包括以下步骤：
步骤s801：在执行规则引擎的过程中，记录各个上下文内容对应的规则结果以及每个业务规则中各个规则条件的条件结果。
在上下文内容中具有输入参数，不同的上下文内容对应不同的输入参数。在将各个上下文内容代入至业务规则的各个规则条件后，可以得到各个规则条件的条件结果。根据各个规则条件的条件结果可以得到规则结果。
规则引擎服务器记录下来各个规则条件的条件结果以及对应的规则结果，以便后续用来分析条件结果和规则结果的关联性。
步骤s802：对各个条件结果和预先设定的规则结果进行关联性分析。
可以理解的是规则结果具有两类，一类为用户满足用户需求的结果，另一类为不满足用户需求的结果。将满足用户需求的结果作为预先设定的规则结果。然后分析各个条件结果与预先设定的规则结果的关联性。
对各个条件结果和对应的规则结果进行关联性分析的过程，相当于进行一次监督学习，可以使用机器学习分类算法(比如决策树)来进行关联性分析。
步骤s803：将与规则结果具有关联性的条件结果对应的规则条件的组合、确定为优化后的业务规则。
将与规则结果具有关联性的条件结果对应的规则条件，为准确的规则条件；与规则结果不具有关联性的条件结果对应的规则条件，为不准确的规则条件。将各个准确的规则条件的组合确定优化后的业务规则。
下面以一个具体实例进行详细说明：
以业务为判断账号是否被盗为例：
规则条件1：“年龄”>＝50；
规则条件2：“本次登录地”！＝“上次登录地”；
规则条件3：“性别”＝＝男；
规则结果：“账号被盗号”。
其中，规则条件1、规则条件2和规则条件3不限制是否来源自业务规则中的同一条规则，可以来源自业务规则中的不同的规则。
假设，规则引擎服务器中记录“条件结果”与“规则结果”如下表所示：
通过将各个条件结果(“年龄”>＝50、本次登录地”！＝“上次登录地”和“性别”＝＝男)与规则结果(“账号被盗号”)进行关联性分析后，可以发现：规则条件1和规则条件2与规则结果的关联性达：90％，而规则条件3与结果的关联性：50％。
因此，可以确定优化业务规则为：规则条件1&&规则条件2。
在本例中使用规则条件1&&规则条件2，不使用条件3。说明条件3与确定账户被盗没有太大关系。在使用优化后的业务规则后，可以能够提升识别的准确率，减少误识别。
比如，在序号1、3、6中，原业务规则不能识别出来账号被盗，在使用优化后的业务规则能够识别账号被盗。这样可以保护用户账户安全、减免损失。在序号7，9中，原业务规则误识别账号被盗，导致账户被冻结，这会导致正常用户的使用。
本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。