CN104077694B - 用户权益信息处理方法及系统 - Google Patents

Abstract

本申请公开了用户权益信息处理方法及系统，其中，所述方法包括：接收权益配置方提交的权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；判断当前用户是否符合所述目标规则信息；根据判断结果，响应所述操作命令。通过本申请，能够在对权益进行操作的限制条件进行设置及校验的过程中，更灵活地应对各种权益所针对的人群特征的变化。

Description

用户权益信息处理方法及系统

技术领域

本申请涉及网络数据处理技术领域，特别是涉及用户权益信息处理方法及系统。

背景技术

在电子商务等互联网应用中，一些系统经常会为其会员提供一些各具特色的权益，这些权益一般都具有特定的使用场景要求，也就是说，用户只有在符合某种或者某些条件的情况下，才能使用这种权益。例如，在某购物类网站中，为其会员提供了“退货保障”、“生日优惠”等权益。其中，对于“退货保障”这项权益，可能会要求会员具有较高的级别时才能使用；对于“生日优惠”这项权益，可能会要求只能在会员的生日所在月份之内才能使用，同时还可能需要对会员级别进行限制，或者根据会员级别的高低，享受的优惠程度有所不同，等等。

在实际应用中，如果要为会员提供某种权益，则需要对使用场景的条件进行设置，以便其提供的权益能够被符合条件的用户使用。现有的权益配置系统中，是针对权益独立出服务的概念，每个服务都通过各自的类去限定可享受服务的人群特征。也就是说，针对各项权益需要各自定义对应的类，在类的代码中写死该权益所针对的人群特征、级别等条件。后台配置人员如果需要添加某种权益，需要在代码中调用对应的类函数，当用户具体在使用或者领取某权益时，就会跳转到对应的类中，根据类中定义的判断规则对用户进行判断，以便确定该用户是否符合使用或者领取该权益的条件。

这种现有技术的方案能够实现在特定的使用场景下对权益的使用或者领取，但是，如果某权益所针对的人群特征发生变化就要修改代码，甚至需要重新定义新的类，等等。因此，现有技术在实现的过程中缺少灵活性。

发明内容

本申请提供了用户权益信息处理方法及系统，能够在对权益进行操作的限制条件进行设置及校验的过程中，更灵活地应对各种权益所针对的人群特征的变化。

本申请提供了如下方案：

一种用户权益信息处理方法，包括：

接收权益配置方提交的权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；

接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；

判断当前用户是否符合所述目标规则信息；

根据判断结果，响应所述操作命令。

一种用户权益信息处理系统，包括：

后台配置单元，用于接收权益配置方提交的权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；

规则筛选单元，用于接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；

校验单元，用于判断当前用户是否符合所述目标规则信息；

响应单元，用于根据判断结果，响应所述操作命令。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以将权益、对权益生命周期中的各种操作、对权益进行操作时的限制条件进行抽象，分别对应成道具、操作命令以及规则等，这样可以将权益本身以及对权益的操作分离开来，配置人员在配置一个权益及其限制条件时，可以采用填写或者选择配置参数的方式来实现配置。相应的，系统可以对配置人员的配置信息进行保存，在接收到用户对某权益进行操作的操作指令时，就可以从数据库中筛选出该权益在当前操作命令下需要校验的规则信息，进而对这些规则信息进行校验即可。可见，在本申请实施例中，可以通过各种参数取值的组合来实现对限制条件的设置及校验，因此，能够更灵活地应对各种权益所针对的人群特征的变化。

具体在进行校验时，可以将需要校验的规则信息组装成规则树，通过遍历规则树中的各个分支到叶子节点的方式，来对用户的相关数据进行校验，从而避免规则的漏检或重检。

如果需要校验的规则信息包括多个规则类型，还可以在不同的线程中分别针对各个规则类型单独组装规则树，然后分别对各个规则树的各个分支进行遍历，最后再根据各个线程返回的校验结果，来得到最终的校验结果。这样可以降低对系统性能的消耗，降低规则校验的难度。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的方法中各种后台配置参数的示意图；

图3是本申请实施例提供的方法中规则树的示意图；

图4-1、4-2、4-3是本申请实施例提供的方法中以规则类型为单位分别组装的小型规则树的示意图；

图5是本申请实施例提供的方法中将待校验的所有规则信息组装成一个大型规则树的示意图；

图6是本申请实施例提供的系统的示意图。

具体实施方式

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

在本申请实施例中，可以将各具特色的权益抽象成“道具”，将对权益的操作抽象成“命令”，将命令的限制条件抽象成“规则”，由接收器负责命令的执行。

例如，对于“退货保障”、“多倍积分”、“生日礼包”、“客服优先”、“活动优先”、“急速退款”等各项权益，可以分别抽象成道具，每项权益都对应这一个道具。

对权益的操作分为内部用户对权益的操作，以及后台配置人员对权益的操作；其中，用户对权益的操作可以包括激活、使用、领用、停用等操作，后台配置人员对权益的操作可以包括上架、下架等。也就是说，一个权益从上架，到被用户领用、使用、停用(可选)，再到下架会经历一个生命周期，这个生命周期中涉及到的各种操作都可以抽象成对应的命令。例如，对应前述各种操作，可以包括激活命令、使用命令、停用命令、上架命令、下架命令等。这些命令与用户或者配置人员的操作相关，可以在用户界面或者配置界面上提供相应的操作入口，以便于发起相应的命令。以上这些命令都可以被看作是系统的内部命令，除此之外，在实现过程中，还可以包括以下外部命令，这些外部命令一般是与内部命令相关联的，用于在针对内部命令进行判断等处理的过程中和/或结束后，调用相应的外部命令，对权益的状态进行控制。例如，与权益的使用命令相关联的外部命令可以包括冻结命令(例如，当用户发出使用某权益的命令之后，可以使用该命令将对应的权益进行冻结)、消耗命令(例如，在一个权益实际被成功使用之后，使用消耗命令对权益的被使用次数等进行修改)、解冻命令(例如，在一个权益未被成功使用的情况下，使用解冻命令对权益进行解冻，将权益的被使用次数等还原到发出使用命令前的状态)。另外，还可以包括查询命令，用于查询某权益能使用的次数等等。

规则可以用来描述对权益进行操作的限制条件。具体实现时，规则可以对应各种操作命令分为多种类别，例如，使用类规则、领取类规则等。每一类规则又可以细分为多种规则类型，例如，使用类规则中可以包括用户级别限制、领取数量限制、领取时间限制等，领取规则中可以包括使用过程中产生的累积受益值限制、使用数量限制、使用时间限制、使用频率限制、受益比例限制等。也就是说，对于某一权益而言，如果需要对使用该权益的条件进行限制，则可以从用户级别、领取数量、领取时间等角度来设置限制条件，而如果需要对领取该权益的条件进行限制，则可以从使用过程中产生的累积受益值限制、使用数量限制、使用时间限制、使用频率限制、受益比例限制等角度来设置限制条件。

在以上抽象的基础上，本申请实施例首先提供了一种用户权益信息处理方法，参见图1，该方法可以包括以下步骤：

S101：接收权益配置方提交的权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；

在具体实现时，可以为权益配置方(例如，某电子商务系统的后台技术人员)显示出配置界面，在配置界面上显示有配置接口，这样，技术人员可以通过这些配置接口进行配置，例如，在特定的规则类型下可提供的权益等。为了完成这些配置，参见图2，配置界面上的配置入口可以分别用于配置以下参数：id、prop_item_id、rule_type、member_level、tag、condition_key、condition_Value、gmt_creat、gmt_modified、prop_id、prop_level、status等。

其中，id、prop_item_id、prop_id用于设置权益的唯一性标识。prop_id代表权益本身的标识，如果定义了一个权益之后，在后续还会定义其他版本，则可以用prop_item_id来指定权益的规格版本信息，例如，某权益分为2012版以及2013版，则可以通过prop_item_id来标识出两者属于同一权益的不同版本。prop_level则用于指定当前定义的标识信息是prop_item_id还是prop_id。这几个参数中，prop_item_id或者prop_id的具体取值可以由用户进行填写，而prop_level由于只有两种选择，因此，可以采用下拉框等方式由用户进行选择。

rule_type用于设置权益的规则类型，具体在设置其取值时，由于规则类型的数量也比较有限，因此，也可以采用下拉框等方式由用户进行选择，这样可以方便用户的操作，并且也避免产生输入错误。需要说明的是，由于rule_type可以对应操作命令设置多个类别，因此，规则类型在取值上也可以体现出类别的信息，例如，如果可以分为领取规则和使用规则两大类，则领取类的各种规则类型的取值可以取大于0的数字，使用类的各种规则类型的取值可以取小于零的数字。这样，就可以直接从数值的正负关系上快速地区分出一条规则是为领取时设定的规则(领取时需要校验)，还是为使用时设定的规则(使用时需要校验)。当然，如果除了使用类以及领取类之外，还存在其他类的规则类型，例如，一共为N个大类，则可以将规则类型的取值范围划分为N个区间，并分别定义好各个区间对应的是哪个大类，然后分别在对应的区间内定义各个规则类型的取值。

member_level代表用户级别，例如，一个系统中将其会员分为一级、二级及三级，则member_level共有三个取值，因此，同样可以为技术人员提供下拉框等方式，供技术人员通过选择进行设置。

condition_key和condition_value这两个参数共同代表规则的限制条件，其中，condition_key表示规则限制的单位是时间、数量还是频率限制等，condition_value是限制的阈值。其中，condition_key同样可以采用下拉框等方式由技术人员进行选择，而condition_value则可以由技术人员添加具体的数值。例如，为某权益设置的规则包括：使用频率大于5次/月，则在rule_type字段中选择了“使用频率”这一规则类型之后，就可以在condition_key对应的下拉框中将限制的单位选为“频率”，并在condition_value对应的输入框中输入“5”即可。

gmt_creat、gmt_modified是两个时间信息，其中，gmt_creat代表创建的时间，gmt_modified代表修改时间。

status代表权益的状态，例如，包括冻结状态、消耗状态、解冻状态等等。

总之，如果技术人员需要为用户提供某权益，并且需要限制对其进行操作时的条件，则可以通过上述配置界面进行个参数值的选择或者填写，提交之后，这些信息就会被保存到数据库中。

需要说明的是，对于同一权益而言，可能需要从多个方面分别进行条件限制，此时，可以为其配置多条规则，在每一条规则中都分别对上述各参数对应的值进行选择或者填写(当然，一些参数允许有缺省值)。也就是说，对于一个权益来说，可能存在多条规则。另外，将一条规则的信息保存到数据库之后，可能对应多条数据，对于此，后续的例子中会有体现。

另外需要说明的是，在图2所示的表格中，分别定义了各个参数的类型、长度等信息，这里只是举例说明，在实际应用中也可以定义其他的类型或者长度，因此，不应看作对本申请保护范围的限制。

S102：接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；

在配置人员完成对一个权益的配置并提交到数据库之后，还可以通过界面上的“上架”操作入口发起上架命令，使得权益可以显示在用户侧的用户界面中。其中，在用户侧，系统可以根据用户的级别等基本信息，筛选出一些权益显示在其界面上，当然，此时对权益的显示这并不意味着用户已经可以领取或者使用该权益，因为还需要对用户是否符合各种规则对应的限制条件。因此，在用户界面上显示各个权益的同时，还可以提供“激活”、“领用”、“使用”等操作入口，这样，用户如果想要激活、领取或者使用某权益，就可以从相应的操作入口进入，向系统发起激活命令、领取命令或者使用命令。

另外，如果技术人员某权益了分别对应多种操作命令的多类规则，则可以首先将该权益与当前操作命令对应的规则取出，然后判断当前用户在系统中的具体数据是否符合这部分规则即可。例如，如前文所述，在定义各条规则的规则类型时，可以根据其取值所在的区间来表示对应的是那个操作命令的规则，因此，可以首先从数据库中将当前权益对应的全部规则都取出，然后根据各条规则的规则类型的取值，来取出当前的操作命令需要校验的规则。例如，当前接收到的操作命令是使用某权益的命令，则可以从该权益对应的各条规则中取出规则类型值小于零的规则(假设预先定义了规则类型值小于零的规则是使用类规则)，然后判断当前用户在系统中的数据是否满足这种规则对应的限制条件即可。也即，即使该权益还存在规则类型值大于0的其他规则，但由于那些规则与当前的操作命令无关，因此也不必进行校验。

S103：判断当前用户是否符合所述目标规则信息；

在根据当前用户发出的操作命令获取到数据库中保存的该权益在该操作命令下需校验的规则之后，就可以利用这些规则对用户进行校验，判断用户是否有符合该权益执行该操作命令的条件。其中，由于系统中会对各个会员用户在交互历史过程中产生的数据进行存储及统计，因此，可以从系统存储的信息中取出当前用户的相关数据，包括当前用户的级别、对某权益的使用时间、领取时间、使用频率等等，这些信息会作为用户的个人参数保存在系统中，因此，可以直接从系统保存的信息中获取到。

具体在判断当前用户的相关数据是否符合各个规则的限制条件时，可以有多种实现方式，在本申请实施例中，优选采用构造规则树的方式来实现。也就是说，由于对于一个权益而言，其对应的规则可能有多条，就算是当前操作命令下需校验的规则可能也有很多，此时，需要一种有效的方式，使得各种规则都能够被校验到，同时又避免对同一条规则的重复校验，等等。为此，考虑到各条规则都是由用户级别、规则类型、限制条件这样几种关键的参数来定义的，因此，对于某权益而言，可以以该权益的标识信息(权益的ID或者权益规格版本的ID)作为树的根节点，将各条规则对应的用户级别、规则类型、限制条件分别作为树的后续各级节点，以此组装成规则树。然后，在进行判断时，就可以分别遍历规则树中的各个分支至叶子节点，判断当前用户是否满足各个分支上对应的某种规则。

例如，如图3所示的规则树中，是以member_level(会员等级)作为树的第一级节点，以rule_type为第二级节点，以<condition_key，condition_Value>为叶子节点。这样，树的每一个分支都对应一个限制条件，当然，在实际应用中，一条规则可能存在多个限制条件，也就是说，一个限制条件可能并不能对应一个完整的规则，但是，对于这种一条规则对应多个限制条件的情况，在进行校验时，仍然需要分别对每个限制条件进行校验。因此，在组装成该规则树之后，就可以分别针对树的各个分支，遍历到叶子节点，以便判断是否符合各个分支对应的限制条件。其中，在图3所示的例子中，当遍历到叶子层级时，叶子节点是个Map，根据condition_key来比较会员数据是否在condition_Value的范围内。当然，如果用户在某分支上的第一级节点或者第二级节点就没有通过校验，则不会遍历到叶子节点，也即，在各级节点上，如果校验通过则进入下一层节点继续校验，如果校验未通过，则停止在该分支上的校验，并得到不符合该分支对应的限制条件这一校验结果。另外需要说明的是，当树是多叉树时，根据业务需求区分可以是满足其中一个分支，或者是满足所有分支的条件。总之，对于一个待处理的规则要决定沿哪条或者哪些分支来遍历，如果规则匹配就能够沿着分支一直遍历到叶节点，反之是规则不匹配。当满足了此种权益的所有规则限制条件，才表示可以进行相应的操作，如果不满足其中任何一种规则限制条件则不能进行相应的操作。

当然，在实际应用中，如果某权益在某操作命令下包括的规则非常多，则在如果将所有的规则都组装成一个规则树，则树的规模可能会比较庞大，包含的分支非常多，尤其是当业务规则复杂时将变得异常庞大，此时，创建、遍历的难度同比增大，程序每做一种规则校验就要遍历整棵树直到找到对应类型的规则分支；如果想在一次遍历中校验所有的规则，要对所有分支按规则类型进行区分并且要确保每类规则都要被校验，这无疑会消耗很多的系统资源。另外，若想在一棵树的结构中表示规则间的与或关系将变得很困难，当出现多层级嵌套的与或关系时系统解析、校验难度无疑将更大，这就需要在规则校验之外增加复杂的与、或等处理逻辑，并且很难与校验逻辑解耦，增加了对规则校验的难度，更不方便系统进行扩展。

为了避免这种情况的发生，本申请实施例还可以使用以下方式来实现：如前文所述，各条规则都具有不同的规则类型，因此，可以以规则类型为单位，将需要校验的规则信息组装成多棵规则树。也即，分别针对各个规则类型单独组装成各自的规则树，这样在进行校验时，就可以分别遍历各规则树中的各个分支至叶子节点，判断当前用户是否满足某权益的某种类型的规则。也就是说，将在一棵大的规则树中的遍历变为在多棵小的规则树中的遍历，这样，可以就避免将所有规则都组装成一个大的规则树时可能会产生的问题。

另外，为了进一步提高系统性能，可以采用多线程的方式来实现。也即，可以在系统启动时初始化一个线程池，在接收到一个操作命令之后，对于当前需校验的各个规则而言，如果其中包含N个规则类型，则可以通过线程池创建N个线程，每一个线程对应一个规则类型；对于各个规则类型而言，可以在各自的线程中进行规则树的组装以及后续的判断工作。这样，各个线程之间可以并行处理，提高处理效率，并且通过线程池创建线程的开销不会严重消耗系统性能。例如，具体实现时，可以选择以此方式创建线程池：ExecutorServiceexec＝Executors.newCachedThreadPool()，然后，对每个规则类型的规则分别创建线程并提交线程池执行，通过信号量控制使得应该校验的规则全部校验完后返回结果。校验的过程中首先递归地拼装规则树，然后尝试遍历到叶子节点，判断是否满足叶子节点的条件值。

S104：根据判断结果，响应所述操作命令。

在完成步骤S103中的判断操作之后，如果当前用户符合当前权益在当前操作命令下的各条规则限制条件，则可以继续执行该操作命令，例如，允许当前用户领取或使用对应的权益等等。而如果当前用户不符合当前权益在当前操作命令下的各条规则限制条件，则可以返回失败，同时，还可以给用户显示一些提示信息，比如，可以提示用户失败的原因，等等。

总之，在本申请实施例中，可以将权益、对权益生命周期中的各种操作、对权益进行操作时的限制条件进行抽象，分别对应成道具、操作命令以及规则，这样可以将权益本身以及对权益的操作分离开来，配置人员在配置一个权益及其限制条件时，可以采用填写或者选择配置参数的方式来实现配置。相应的，系统可以对配置人员的配置信息进行保存，在接收到用户对某权益进行操作的操作指令时，就可以从数据库中筛选出该权益在当前操作命令下需要校验的规则信息，进而对这些规则信息进行校验即可。可见，在本申请实施例中，可以通过各种参数取值的组合来实现对限制条件的设置及校验，因此，能够更灵活的应对各种权益所针对的人群特征的变化。

为了更好的理解本申请实施例提供的技术方案，下面通过一个实际应用中的例子对该方法进行介绍。

假设某系统需要为其会员提供一个“生日礼包”的权益，需要将对该权益进行操作时的条件限制为：

a、只有会员才能享受该权益；

b、必须在会员生日所在月之内使用；

c、会员的使用频率必须达到每月5次；

d、根据会员等级的不同，优惠的幅度有所不同，例如，一级会员优惠10％，二级会员优惠20％，三级会员优惠30％。

分析以上权益，可以提炼出以下四条规则：

规则(1)：领取等级规则限制(必须是会员)；

规则(2)：使用时间规则限制(必须在会员生日所在月之内使用)；

规则(3)：使用频率规则限制(b、会员的使用频率必须达到每月5次)；

规则(4)：优惠幅度规则限制(c、根据会员等级的不同，优惠的幅度有所不同，例如，一级会员优惠10％，二级会员优惠20％，三级会员优惠30％)。

因此，配置人员就可以为该权益配置以上四条规则，具体的，后台系统会为配置人员提供配置权益和权益规则的界面，配置人员可以在界面中选择或者填写各个参数的取值，实现对每条规则的配置。在提交到系统之后，会将各条规则对应的数据保存中数据库中。其中，每条规则对应数据库规则限制表中一条或多条记录，例如，该例子中，数据库中的规则限制表会包含如下表1所示的记录：

表1

其中，第1、2、3条记录表示第(1)种规则，rule_type＝1＞0表示领取等级，member_level字段存储会员的等级，Condition_key＝0表示无限制。

第4条记录表示第(2)种规则，rule_type＝-3表示使用时间，member_level＝-2147483648表示所有等级，Condition_key＝1表示时间限制，Condition_value里存的是对时间进行规则校验的类的全类名。

第5条记录表示第(3)种规则，rule_type＝-5表示使用频率，member_level＝-2147483648表示所有等级，此时Condition_key存储的是时间跨度单位，如332表示/月，Condition_value存的是次数，此时值为5，condition_key和condition_value配合使用即表示5次/月。

第6、7、8条记录表示第(4)种规则，rule_type＝-4表示优惠幅度，member_level字段分别存储会员的等级。此时Condition_key＝21表示单次数量上限，此时Condition_value存的是优惠率，分别表示一级会员单次优惠数量上限10％，二级会员单次优惠数量上限20％，三级会员单次优惠数量上限30％。

在某会员发起使用该权益的请求之后，系统可以接收到对该权益的使用命令，则可以按照以下步骤进行校验：

步骤一、从数据库读取“生日礼包”的权益所对应的共8条规则限制条件的记录；

步骤二、当容器启动时将所有规则校验类加载到内存中，根据rule_type＜0筛选出针对使用命令需要交验的是第(2)、(3)、(4)共三种规则校验类；

步骤三、组装请求操作的会员相关数据(此例需要的会员数据有会员等级、生目、当月使用次数)；

步骤四、从线程池中获取三个线程，分别将规则(2)、(3)、(4)拼装成如图4-1、4-2、4-3所示的规则树，在各个线程中，通过遍历规则树至叶子节点来判断会员数据是否满足此种规则限制条件。只有当所有的规则校验都满足时，即三个线程内的校验都通过，才表示会员可以使用该权益。

在该例子中，如果将与使用命令相关的各条规则都组装成一棵树，则对应的规则树可以如图5所示，虽然也能够达到校验的目的，但是规则树会显得很庞大，会给具体的校验等工作带来不便。

与本申请实施例提供的上述用户权益信息处理方法相当于，本申请实施例还提供了一种用户权益信息处理系统，参见图6，该系统可以包括：

后台配置单元601，用于接收权益配置方提交的权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；

规则筛选单元602，用于接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；

校验单元603，用于判断当前用户是否符合所述目标规则信息；

响应单元604，用于根据判断结果，响应所述操作命令。

具体实现时，所述操作命令包括多个类别(例如可以包括领取类、使用类等)；为一个权益配置的规则信息中，可以包括分别为各类操作命令配置的规则信息(也即为一个权益配置的规则信息可以包括多个大的类别，每个大的类别下还包括具体的规则类型)；相应的，所述规则筛选单元602具体可以包括：

提取子单元，用于查询数据库，提取出所述指定权益对应的所有规则信息；

命令类别确定子单元，用于确定所述操作命令所属的类别；

规则类别确定子单元，用于提取所述指定权益对应的各条规则信息中规则的类型信息对应的取值，并根据所述类型信息的取值确定所述权益对应的各条规则分别所属的类别；

匹配子单元，用于将所述指定权益对应的各条规则信息中所属类别与所述操作命令所属类别相匹配的规则信息，确定为所述权益在所述操作命令下需要校验的目标规则信息。

其中，所述操作命令的类别包括使用命令，针对一权益，为使用命令配置的规则信息的规则类型包括以下各类型中的一种或多种：用户级别限制、领取数量限制、领取时间限制。

所述操作命令的类别还可以包括领取命令，针对一权益，为领取命令配置的规则信息的规则类型包括以下各类型中的一种或多种：使用过程中产生的累积受益值限制、使用数量限制、使用时间限制、使用频率限制、受益比例限制。

在具体实现时，所述校验单元603具体可以包括：

规则树组装子单元，用于将所述目标规则信息组装成规则树；其中，所述规则树以所述指定权益的标识信息为根节点，分别以所述权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息作为树的其他各级节点；

遍历子单元，用于遍历所述规则树中的各个分支至叶子节点，判断当前用户是否满足所述指定权益的某种规则。

具体实现时，所述指定权益对应的规则信息具有多种规则类型时，为了避免对系统性能的消耗，规则树组装子单元具体可以用于：

以规则类型为单位，将所述目标规则信息组装成多棵规则树；

遍历子单元具体可以用于：

分别遍历各规则树中的各个分支至叶子节点，判断当前用户是否满足所述指定权益的某种类型的规则。

其中，具体实现时，可以以规则类型为单位，创建线程，分别在各个线程中将对应规则类型的目标规则信息组装成规则树。

在实际应用中，可以为后台配置人员提供配置界面，使得后台配置人员可以通过选择或填写具体的配置参数值的方式进行权益及其对应规则信息的配置，所述后台配置单元具体可以用于：

接收权益配置方在预置的配置界面中为各个配置参数选择或填写的参数值，根据所述参数值确定权益的标识信息，以及为权益配置的一条或多条规则信息。

另外，具体实现时，在用户侧，也可以为用户提高对权益执行操作的操作入口，使得用户可以通过对应的入口发起对指定权益的操作，也即，具体实现时，规则筛选单元602可以通过在用户界面上提供的操作入口，接收当前用户对指定权益的操作命令。

根据一些具体的应用场景，在校验过程中或者校验完毕之后，还可能涉及到对权益状态的修改，因此，还可以使用一些外部命令，例如，冻结命令、消耗命令、解冻命令，等等，因此，该系统还可以包括：

状态控制单元，用于接收到当前用户对指定权益的操作命令之后，通过调用预先定义的外部命令，对所述指定权益进行状态控制。

总之，在本申请实施例中，可以将权益、对权益生命周期中的各种操作、对权益进行操作时的限制条件进行抽象，分别对应成道具、操作命令以及规则，这样可以将权益本身以及对权益的操作分离开来，配置人员在配置一个权益及其限制条件时，可以采用填写或者选择配置参数的方式来实现配置。相应的，系统可以对配置人员的配置信息进行保存，在接收到用户对某权益进行操作的操作指令时，就可以从数据库中筛选出该权益在当前操作命令下需要校验的规则信息，进而对这些规则信息进行校验即可。可见，在本申请实施例中，可以通过各种参数取值的组合来实现对限制条件的设置及校验，因此，能够更灵活的应对各种权益所针对的人群特征的变化。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的用户权益信息处理方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种用户权益信息处理方法，其特征在于，包括：

接收权益配置方通过预置的配置界面为各个配置参数提交的参数值，所述参数值包括权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，通过预先定义的多类操作命令来描述权益生命周期中的各类操作，所述规则信息与各类操作命令相对应，分为多种类型，分别用于描述对所述权益执行对应操作命令时的限制条件；各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；

接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；

判断当前用户是否符合所述目标规则信息；

根据判断结果，响应所述操作命令。

2.根据权利要求1所述的方法，其特征在于，所述操作命令包括多个类别；为一个权益配置的规则信息中，包括分别为各类操作命令配置的规则信息；所述查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息包括：

查询数据库，提取出所述指定权益对应的所有规则信息；

确定所述操作命令所属的类别；

提取所述指定权益对应的各条规则信息中规则的类型信息对应的取值，并根据所述类型信息的取值确定所述权益对应的各条规则分别所属的类别；

将所述指定权益对应的各条规则信息中所属类别与所述操作命令所属类别相匹配的规则信息，确定为所述权益在所述操作命令下需要校验的目标规则信息。

3.根据权利要求2所述的方法，其特征在于，所述操作命令的类别包括使用命令，针对一权益，为使用命令配置的规则信息的规则类型包括以下各类型中的一种或多种：用户级别限制、领取数量限制、领取时间限制。

4.根据权利要求2所述的方法，其特征在于，所述操作命令的类别包括领取命令，针对一权益，为领取命令配置的规则信息的规则类型包括以下各类型中的一种或多种：使用过程中产生的累积受益值限制、使用数量限制、使用时间限制、使用频率限制、受益比例限制。

5.根据权利要求1所述的方法，其特征在于，所述判断当前用户是否符合所述目标规则信息包括：

将所述目标规则信息组装成规则树；其中，所述规则树以所述指定权益的标识信息为根节点，分别以所述权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息作为树的其他各级节点；

遍历所述规则树中的各个分支，判断当前用户是否满足所述指定权益的某种规则。

6.根据权利要求5所述的方法，其特征在于，所述指定权益对应的规则信息具有多种规则类型时，所述将所述目标规则信息组装成规则树包括：

以规则类型为单位，将所述目标规则信息组装成多棵规则树；

所述遍历所述规则树中的各个分支，判断当前用户是否满足所述指定权益的某种规则包括：

分别遍历各规则树中的各个分支，判断当前用户是否满足所述指定权益的某种类型的规则。

7.根据权利要求6所述的方法，其特征在于，所述以规则类型为单位，将所述目标规则信息组装成多棵规则树包括：

以规则类型为单位，创建线程，分别在各个线程中将对应规则类型的目标规则信息组装成规则树。

8.根据权利要求1至7任一项所述的方法，其特征在于，所述接收当前用户对指定权益的操作命令包括：

通过在用户界面上提供的操作入口，接收当前用户对指定权益的操作命令。

9.根据权利要求1至7任一项所述的方法，其特征在于，还包括：

接收到当前用户对指定权益的操作命令之后，通过调用预先定义的外部命令，对所述指定权益进行状态控制。

10.一种用户权益信息处理系统，其特征在于，包括：

后台配置单元，用于接收权益配置方通过预置的配置界面为各个配置参数提交的参数值，所述参数值包括权益的标识信息，以及为权益配置的一条或多条规则信息，并将所述标识信息以及对应的规则信息保存到数据库中；其中，通过预先定义的多类操作命令来描述权益生命周期中的各类操作，所述规则信息与所述操作命令相对应，分为多种类型，分别用于描述对所述权益执行对应操作命令时的限制条件；各条规则信息中分别包括以下配置参数中的一项或多项：权益适用的用户的级别信息、规则的类型信息以及规则的限制条件信息；

规则筛选单元，用于接收当前用户对指定权益的操作命令，并查询数据库，筛选出所述指定权益在所述操作命令下需要校验的目标规则信息；

校验单元，用于判断当前用户是否符合所述目标规则信息；

响应单元，用于根据判断结果，响应所述操作命令。