一种佣金数据处理方法和装置
文献发布时间：2023-06-19 12:24:27
技术领域
本发明涉及计算机技术领域，尤其涉及一种佣金数据处理方法和装置。
背景技术
随着电商业务的不断发展，入驻的商家数量逐步增多，商家推广需求也不断扩大，为提供更优质的服务，推出了电商广告联盟平台来满足商家的推广需求。广告主使用电商广告联盟平台进行物品、店铺的推广，而推客通过使用电商广告联盟平台进行物品、店铺的推广进而获得佣金。CPS(Cost Per Sales，即按销售付费)计划查询作为其中核心的一环，其实质是根据推客的推广行为，通过业务逻辑匹配出哪个广告主为该推广行为付出佣金。
目前实施逻辑为：广告主创建计划后存储在MySQL，匹配计划时再根据推客的信息和推广的物品信息，读取MySQL中的计划，然后通过业务逻辑选取到最优的计划，也即最优的佣金比例，以此决定付给推客多少佣金。
在实现本发明的过程中，发明人发现现有技术至少存在如下问题：用户通过点击物品推广信息进行下单操作后，该下单操作都会传输至MySQL以匹配计划，因而存在两个明显弊端，一是读取计划过慢，另一个是当用户下单量过多时，可能会导致MySQL宕机，影响整个CPS业务。
发明内容
有鉴于此，本发明实施例提供一种佣金数据处理方法和装置，至少能够解决现有技术中所有下单信息会传输至MySQL处理，导致查询计划过慢的问题。
为实现上述目的，根据本发明实施例的一个方面，提供了一种佣金数据处理方法，包括：
在收到对一个物品的下单操作后，获取下单信息中的物品推广信息和推客信息，查询与所述物品推广信息和所述推客信息对应的倒排索引；其中，所述一个物品的访问链接通过点击计划得到，计划为广告主所创建并由推客进行推广；
读取所述倒排索引中的计划标识，确定与所述计划标识对应的正排索引，获取所述正排索引中的计划列表，进而从中筛选出下单时间处于计划开始时间和结束时间范围内的多个计划；
将所述多个计划中优先级等级最高的计划作为目标计划，以基于下单金额和所述目标计划中的佣金比例，计算支付给推客的佣金金额。
可选的，在所述查询与所述物品推广信息和推客信息对应的倒排索引之前，还包括：
以计划开始时间和结束时间为查询条件，查询数据库中当前处于运行状态的计划；
对于任一计划，根据所述任一计划中的物品推广信息和计划标识，创建倒排索引；以及
确定与所述任一计划的标识对应的所有计划，结合计划标识，创建正排索引；
将每个计划的倒排索引和正排索引，一同写入缓存数据库。
可选的，计划包括店铺计划、类目计划、爆品计划中的至少一种；
对于店铺计划，倒排索引的键名为店铺标识，键值为与所述店铺标识对应的店铺计划标识列表；正排索引的键名为店铺计划标识，键值为与店铺计划标识对应的店铺计划列表；
对于类目计划，倒排索引的键名由计划中的一级类目标识、二级类目标识和三级类目标识按序组合而成，键值为与倒排索引键名对应的类目计划标识列表；正排索引的键名为类目计划标识，键值为与类目计划标识对应的类目计划列表；
对于爆品计划，倒排索引的键名为物品标识，键值为与物品标识对应的爆品计划标识列表；正排索引的键名为爆品计划标识，键值为与爆品计划标识对应的爆品计划列表。
可选的，在所述将每个计划的倒排索引和正排索引，一同写入缓存数据库之后，还包括：
将缓存数据库中的计划倒排索引写入虚拟机中；以及
计算所述虚拟机写入计划倒排索引后的剩余资源大小，若所述剩余资源大小大于计划正排索引占用的资源大小，则将缓存数据库中的计划正排索引写入虚拟机中，否则不做处理。
可选的，还包括：对上一版本号累加预设数值，以生成当前版本号，为每个倒排索引的键名添加所述当前版本号并存储。
可选的，还包括：在所述缓存数据库中，对于一个计划，判断是否达到所述一个计划的预设清理时间点，若达到，则过滤所述一个计划。
可选的，还包括：在将计划正排索引写入缓存数据库后，将每个计划的属性，使用预设数据格式类型表示。
可选的，还包括计划站长绑定关系，用于存储计划和推客之间的绑定关系；
所述方法还包括：
创建计划站长绑定关系的倒排索引和正排索引，并一同写入缓存数据库；其中，倒排索引的键名为推客标识，键值为与推客标识对应的计划标识列表；正排索引的键名为计划标识，键值为与计划标识对应的计划站长绑定关系组成的列表；
对根据物品推广信息查找到的倒排索引中的计划标识列表、和根据推客标识查找到的倒排索引中的计划标识列表，做取交集处理。
可选的，所述将所述多个计划中优先级等级最高的计划作为目标计划，包括：
从所述多个计划中筛选出优先等级最高的第一计划，判断所述第一计划的数量是否为一个；
若为一个，则将所述第一计划作为目标计划，否则从所述第一计划中筛选出佣金比例最高的第二计划，判断所述第二计划的数量是否为一个；
若为一个，则将所述第二计划作为目标计划，否则从所述第二计划中筛选出创建时间最早的第三计划，将所述第三计划作为目标计划。
为实现上述目的，根据本发明实施例的另一方面，提供了一种佣金数据处理装置，包括：
查询模块，用于在收到对一个物品的下单操作后，获取下单信息中的物品推广信息和推客信息，查询与所述物品推广信息和所述推客信息对应的倒排索引；其中，所述一个物品的访问链接通过点击计划得到，计划为广告主所创建并由推客进行推广；
筛选模块，用于读取所述倒排索引中的计划标识，确定与所述计划标识对应的正排索引，获取所述正排索引中的计划列表，进而从中筛选出下单时间处于计划开始时间和结束时间范围内的多个计划；
计算模块，用于将所述多个计划中优先级等级最高的计划作为目标计划，以基于下单金额和所述目标计划中的佣金比例，计算支付给推客的佣金金额。
可选的，还包括索引创建模块，用于：
以计划开始时间和结束时间为查询条件，查询数据库中当前处于运行状态的计划；
对于任一计划，根据所述任一计划中的物品推广信息和计划标识，创建倒排索引；以及
确定与所述任一计划的标识对应的所有计划，结合计划标识，创建正排索引；
将每个计划的倒排索引和正排索引，一同写入缓存数据库。
可选的，计划包括店铺计划、类目计划、爆品计划中的至少一种；
对于店铺计划，倒排索引的键名为店铺标识，键值为与所述店铺标识对应的店铺计划标识列表；正排索引的键名为店铺计划标识，键值为与店铺计划标识对应的店铺计划列表；
对于类目计划，倒排索引的键名由计划中的一级类目标识、二级类目标识和三级类目标识按序组合而成，键值为与倒排索引键名对应的类目计划标识列表；正排索引的键名为类目计划标识，键值为与类目计划标识对应的类目计划列表；
对于爆品计划，倒排索引的键名为物品标识，键值为与物品标识对应的爆品计划标识列表；正排索引的键名为爆品计划标识，键值为与爆品计划标识对应的爆品计划列表。
可选的，还包括索引存储模块，用于：
将缓存数据库中的计划倒排索引写入虚拟机中；以及
计算所述虚拟机写入计划倒排索引后的剩余资源大小，若所述剩余资源大小大于计划正排索引占用的资源大小，则将缓存数据库中的计划正排索引写入虚拟机中，否则不做处理。
可选的，还包括版本添加模块，用于：对上一版本号累加预设数值，以生成当前版本号，为每个倒排索引的键名添加所述当前版本号并存储。
可选的，还包括过期清理模块，用于：在所述缓存数据库中，对于一个计划，判断是否达到所述一个计划的预设清理时间点，若达到，则过滤所述一个计划。
可选的，还包括格式更改模块，用于：在将计划正排索引写入缓存数据库后，将每个计划的属性，使用预设数据格式类型表示。
可选的，还包括计划站长绑定关系，用于存储计划和推客之间的绑定关系；
所述装置还包括：
创建计划站长绑定关系的倒排索引和正排索引，并一同写入缓存数据库；其中，倒排索引的键名为推客标识，键值为与推客标识对应的计划标识列表；正排索引的键名为计划标识，键值为与计划标识对应的计划站长绑定关系组成的列表；
对根据物品推广信息查找到的倒排索引中的计划标识列表、和根据推客标识查找到的倒排索引中的计划标识列表，做取交集处理。
可选的，所述计算模块，用于：
从所述多个计划中筛选出优先等级最高的第一计划，判断所述第一计划的数量是否为一个；
若为一个，则将所述第一计划作为目标计划，否则从所述第一计划中筛选出佣金比例最高的第二计划，判断所述第二计划的数量是否为一个；
若为一个，则将所述第二计划作为目标计划，否则从所述第二计划中筛选出创建时间最早的第三计划，将所述第三计划作为目标计划。
为实现上述目的，根据本发明实施例的再一方面，提供了一种佣金数据处理电子设备。
本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一所述的佣金数据处理方法。
为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一所述的佣金数据处理方法。
根据本发明所述提供的方案，上述发明中的一个实施例具有如下优点或有益效果：通过CQRS架构将计划的读写进行了分离，更易去维护，建立正、倒排索引，避免了逐一查找比对的过程，将正、倒排索引存储至Redis以降低MySQL的存储压力，加入JVM以降低Redis的缓存压力，以此提高系统的稳定性、可用性。
上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1是现有电商广告联盟平台采用的三层架构；
图2是采用CQRS架构图的计划读写分离架构；
图3是根据本发明实施例的一种构建计划索引方法的流程示意图；
图4是根据本发明实施例的一种佣金数据处理方法的主要流程示意图；
图5是根据本发明实施例的一种佣金数据处理装置的主要模块示意图；
图6是本发明实施例可以应用于其中的示例性系统架构图；
图7是适于用来实现本发明实施例的移动设备或服务器的计算机系统的结构示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
在电商广告联盟平台创建初期，因为不为大众所知，所以广告主投放的计划较少，导致推客的推广行为也较少。随着业务的飞速发展，电商广告联盟平台被越来越多的广告主和推客所熟知，广告主创建了更多的计划，推客有了更多的推广行为。参见图1所示，电商广告联盟平台采用了传统的三层架构，将应用分为：展示层、应用层、数据访问层，展示层用于校验推客推广的信息以及查询最优佣金比例，应用层用于匹配计划，数据访问层用于从MySQL读取计划。
目前计划是d+1生效的，即今日创建计划明日生效，因此本方案采用CQRS架构图将图1中的三层架构改为计划读写分离架构，更易于维护。参见图2所示。上半部分用于计划的加载，将计划的倒排索引和正排索引加载到Redis，优选每天全量加载一次，对于MySQL而言不存在压力；下半部分用于计划的读取，每5分钟(仅为示例)从Redis中读取计划或写入JVM，对于更多的下单操作也不存在压力。
参见图3，示出的是本发明实施例提供的一种构建计划索引方法的主要流程图，包括如下步骤：
S301：以计划开始时间和结束时间为查询条件，查询数据库中当前处于运行状态的计划；
S302：对于任一计划，根据所述任一计划中的物品推广信息和计划标识，创建倒排索引；
S303：确定与所述任一计划的标识对应的所有计划，结合计划标识，创建正排索引；
S304：将每个计划的倒排索引和正排索引，一同写入缓存数据库。
上述实施方式中，对于步骤S301～S302，本方案中的计划为名词，是一个抽象的概念，包含有计划开始结束时间、广告主信息、佣金比例、计划类型等，物品包含商品、店铺。广告主创建的计划所包含的信息如下：
1)店铺计划：planId(计划id)、popId(店铺id)、basicRatio(佣金比例)、startDate(开始日期)、endDate(结束日期)。
2)类目计划：planId(计划id)、cate1(一级类目id)、cate2(二级类目id)、cate3(三级类目id)、commissionRatio(佣金比例)、startDate(开始日期)、endDate(结束日期)。
3)爆品计划：planId(计划id)、skuId、commissionRatio(佣金比例)、startDate(开始日期)、endDate(结束日期)。
以计划开始时间和计划结束时间为查询条件，计划未暂停为附加条件，从MySQL数据库中查询符合要求的所有广告主创建的计划，之后逐条进行索引创建。对于任一计划，可以根据计划中的物品推广信息和推客信息，创建计划倒排索引：
1)店铺计划倒排索引:Map
2)类目计划倒排索引：Map
3)爆品计划倒排索引：Map
同时根据计划id创建计划正排索引：
1)店铺计划正排索引:Map
2)类目计划正排索引：Map
3)爆品计划正排索引：Map
对于步骤S303，在创建完毕每个计划的正排索引和倒排索引后，将所有计划的正排索引和倒排索引一同存入Redis。为进一步提高计划读取速度，在Redis基础上引入虚拟机JVM，以降低Redis的缓存压力。考虑倒排索引只存储了Key，数据量很小，不用占用太多资源，而正排索引种存储了所有的计划信息，会占用很多资源，因而优选将Redis中的计划倒排索引写入到JVM中。
进一步的，考虑Redis的Key过期问题，可以为每个倒排索引的Key里添加一个版本号，如v1、v2、v3....，每次改动都会累计预设数值以升级一个版本号，便于日后清理。Key的过期时间受计划结束时间的影响，通常大于计划结束时间，如计划结束时间为2021/04/03，Key过期时间则设置为2021/04/04；如果不考虑Key过期问题，Key会一直占用Redis资源，增加资源成本。且由于每次生成的倒排索引的Key不同，因而也不会影响线上原有数据的运行。
对于计划正排索引，通过JVM的命令查看JVM内存剩余资源(如设置可视化界面查看)，在JVM内存剩余资源充足的情况下，也可以写入JVM，以此加快计划获取速度。进一步的，为尽量减少正排索引对Redis资源的占用，优选将正排索引plan对象中的所有属性，都使用Java基本数据类型表示。
广告主在创建计划时，还需要针对每个计划创建计划站长绑定关系，包含planId(计划id)、unionId(推客id)、startDate(开始日期)、endDate(结束日期)，一个计划可以由多个推客推广，每个推客也可以推广多个计划，两者为多对多的关系。因而对于部分计划，可以指定推客推广，如计划1-推客1、推客2、推客3，其计划信息中可以包含推广该计划的推客信息列表。
考虑计划站长绑定关系也需存储至Redis中，因而也需按照上述生成计划倒排索引和正排索引的方式，通常生成计划站长绑定关系倒排索引和倒排索引：
1)计划站长绑定关系倒排索引：Map
2)计划站长绑定关系正排索引：Map
若不使用CQRS架构，构建计划倒排索引和正排索引会占用大量JVM资源，如果遇到大流量高并发的情况，系统可能因为JVM资源耗尽而导致崩溃，所以依赖Redis集群，减少JVM资源占用，避免系统崩溃。通过使用CRQS架构对计划的读写进行分离，读是一个应用，写是另一个应用，中间通过Redis进行数据的存放和读取。
上述实施实施例所提供的方法，Redis是基于内存设计的，相比MySQL能够承载更多的下单信息，承担一部分对MySQL的压力，考虑虚拟机比Redis读取写入速度更快，因此进一步引入虚拟机，以降低Redis的缓存压力。
参见图4，示出的是本发明实施例提供的一种佣金数据处理方法的主要流程图，包括如下步骤：
S401：在收到对一个物品的下单操作后，获取下单信息中的物品推广信息和推客信息，查询与所述物品推广信息和所述推客信息对应的倒排索引；其中，所述一个物品的访问链接通过点击计划得到，计划为广告主所创建并由推客进行推广；
S402：读取所述倒排索引中的计划标识，确定与所述计划标识对应的正排索引，获取所述正排索引中的计划列表，进而从中筛选出下单时间处于计划开始时间和结束时间范围内的多个计划；
S403：将所述多个计划中优先级等级最高的计划作为目标计划，以基于下单金额和所述目标计划中的佣金比例，计算支付给推客的佣金金额。
上述实施方式中，对于步骤S401，推客通过推广计划，将物品信息推广给用户，用户点击该物品信息，即可通过其中的访问链接访问物品，之后若用户下单，即表示需支付给该推客一定佣金。下单信息包括：
1)物品信息：skuId、venderId(店铺id)、cate1(一级类目)、cate2(二级类目)、cate3(三级类目)、pop(是否是pop商品)
2)推客信息：unionId(推客id)、unionUserLevel(等级)
3)订单信息：orderId、orderTime(下单时间)
电商广告联盟平台与电商平台建立通讯链接，在收到用户对一个推广物品的下单操作后，可以从下单信息中获取到推客信息和推广的物品信息，进而以物品信息为key，查找相应倒排索引。此处为key可以包含物品所属店铺的id、所属类目的id以及skuId中的一种或多种。此处的倒排索引，从JVM中读取：
1)店铺计划倒排索引:Map
2)类目计划倒排索引：Map
3)爆品计划倒排索引：Map
也可以依据推客id为key，查找相应倒排索引：计划站长绑定关系倒排索引：Map
对于步骤S402，对根据物品推广信息查找到的倒排索引中的计划标识列表、和根据推客标识查找到的倒排索引中的计划标识，做取交集处理，得到后续使用的计划id。计划id即为正排索引的Key，因而可以获取到正排索引的value，即计划列表。例如，根据物品推广信息中的popId(店铺id)读取planBasicIndex中的planId，再通过planId从planBasicMap中获取到对应的计划列表。需要说明的是，正排索引在JVM资源充足情况下，会存储至JVM内，否则仍保留在Redis内，因而此处的正排索引可以是从Redis或JVM中获取得到。
下单信息包含下单时间，而有些计划的结束时间可能早于该下单时间，或者开始时间迟于该下单时间，因而在获取到计划列表后，从中筛选出下单时间处于计划开始结束时间范围内的多个计划。
对于步骤S403，广告主创建计划时，会根据不同的计划类型设置不同的优先级，如爆品>类目>店铺、爆品>店铺>类目。因而在筛选出的对于对符合条件的计划列表按优先级顺序等等排序，若优先等级最高的第一计划数量为一个，则将该第一计划作为目标计划，否则继续筛选。优选佣金比例筛选，从第一计划中筛选出佣金比例最高的第二计划，若第二计划的数量为一个，则将第二计划作为目标计划，否则继续筛选，从中选区创建时间最早的第三计划作为目标计划。
每个计划中都包含有计划开始结束时间、广告主信息、佣金比例、计划类型等，因而将目标计划中的佣金比例乘以用户下单金额，即可得到需支付给推客的佣金金额。
上述实施例所提供的方法，建立计划正、倒排索引，避免了逐一查找比对的过程，以此提高查询速度；即使查询到多个计划，也会通过计划开始结束时间、优先等级、佣金比例、创建时间继续进行筛选，以此提高佣金金额的计算准确性。
本发明实施例所提供的方法，针对现有MySQL存储计划过多，导致计划查询缓慢以及可能存在的崩溃问题，提出一种基于正、倒排索引及CQRS架构的计划查询方案：
1)通过CQRS架构将计划的读写进行了分离，更易去维护。
2)建立正、倒排索引，避免了逐一查找比对的过程；
3)在计划信息较少和JVM资源充足的情况下，可以将正排索引也写入内存，以提高接口性能，否则只将倒排索引存储于JVM，虽然损失部分性能，但是提高了系统的稳定性、可用性，面对日益增长的推广，也不会产生存储瓶颈。
参见图5，示出了本发明实施例提供的一种佣金数据处理装置500的主要模块示意图，包括：
查询模块501，用于在收到对一个物品的下单操作后，获取下单信息中的物品推广信息和推客信息，查询与所述物品推广信息和所述推客信息对应的倒排索引；其中，所述一个物品的访问链接通过点击计划得到，计划为广告主所创建并由推客进行推广；
筛选模块502，用于读取所述倒排索引中的计划标识，确定与所述计划标识对应的正排索引，获取所述正排索引中的计划列表，进而从中筛选出下单时间处于计划开始时间和结束时间范围内的多个计划；
计算模块503，用于将所述多个计划中优先级等级最高的计划作为目标计划，以基于下单金额和所述目标计划中的佣金比例，计算支付给推客的佣金金额。
本发明实施装置还包括索引创建模块，用于：
以计划开始时间和结束时间为查询条件，查询数据库中当前处于运行状态的计划；
对于任一计划，根据所述任一计划中的物品推广信息和计划标识，创建倒排索引；以及
确定与所述任一计划的标识对应的所有计划，结合计划标识，创建正排索引；
将每个计划的倒排索引和正排索引，一同写入缓存数据库。
本发明实施装置中，计划包括店铺计划、类目计划、爆品计划中的至少一种；
对于店铺计划，倒排索引的键名为店铺标识，键值为与所述店铺标识对应的店铺计划标识列表；正排索引的键名为店铺计划标识，键值为与店铺计划标识对应的店铺计划列表；
对于类目计划，倒排索引的键名由计划中的一级类目标识、二级类目标识和三级类目标识按序组合而成，键值为与倒排索引键名对应的类目计划标识列表；正排索引的键名为类目计划标识，键值为与类目计划标识对应的类目计划列表；
对于爆品计划，倒排索引的键名为物品标识，键值为与物品标识对应的爆品计划标识列表；正排索引的键名为爆品计划标识，键值为与爆品计划标识对应的爆品计划列表。
本发明实施装置还包括索引存储模块，用于：
将缓存数据库中的计划倒排索引写入虚拟机中；以及
计算所述虚拟机写入计划倒排索引后的剩余资源大小，若所述剩余资源大小大于计划正排索引占用的资源大小，则将缓存数据库中的计划正排索引写入虚拟机中，否则不做处理。
本发明实施装置还包括版本添加模块，用于：
对上一版本号累加预设数值，以生成当前版本号，为每个倒排索引的键名添加所述当前版本号并存储。
本发明实施装置还包括过期清理模块，用于：
在所述缓存数据库中，对于一个计划，判断是否达到所述一个计划的预设清理时间点，若达到，则过滤所述一个计划。
本发明实施装置还包括格式更改模块，用于：
在将计划正排索引写入缓存数据库后，将每个计划的属性，使用预设数据格式类型表示。
本发明实施装置还包括计划站长绑定关系，用于存储计划和推客之间的绑定关系；
所述装置还包括：
创建计划站长绑定关系的倒排索引和正排索引，并一同写入缓存数据库；其中，倒排索引的键名为推客标识，键值为与推客标识对应的计划标识列表；正排索引的键名为计划标识，键值为与计划标识对应的计划站长绑定关系组成的列表；
对根据物品推广信息查找到的倒排索引中的计划标识列表、和根据推客标识查找到的倒排索引中的计划标识列表，做取交集处理。
本发明实施装置中，所述计算模块503，用于：
从所述多个计划中筛选出优先等级最高的第一计划，判断所述第一计划的数量是否为一个；
若为一个，则将所述第一计划作为目标计划，否则从所述第一计划中筛选出佣金比例最高的第二计划，判断所述第二计划的数量是否为一个；
若为一个，则将所述第二计划作为目标计划，否则从所述第二计划中筛选出创建时间最早的第三计划，将所述第三计划作为目标计划。
另外，在本发明实施例中所述装置的具体实施内容，在上面所述方法中已经详细说明了，故在此重复内容不再说明。
图6示出了可以应用本发明实施例的示例性系统架构600，包括终端设备601、602、603，网络604和服务器605(仅仅是示例)。
终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，安装有各种通讯客户端应用，用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。
网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
服务器605可以是提供各种服务的服务器，用于执行接收下单信息、查询正倒排索引、筛选目标计划和计算支付佣金的操作。
需要说明的是，本发明实施例所提供的方法一般由服务器605执行，相应地，装置一般设置于服务器605中。
应该理解，图6中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
下面参考图7，其示出了适于用来实现本发明实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图7所示，计算机系统700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。
以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本发明的系统中限定的上述功能。
需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括查询模块、筛选模块、计算模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，计算模块还可以被描述为“佣金计算模块”。
作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：
在收到对一个物品的下单操作后，获取下单信息中的物品推广信息和推客信息，查询与所述物品推广信息和所述推客信息对应的倒排索引；其中，所述一个物品的访问链接通过点击计划得到，计划为广告主所创建并由推客进行推广；
读取所述倒排索引中的计划标识，确定与所述计划标识对应的正排索引，获取所述正排索引中的计划列表，进而从中筛选出下单时间处于计划开始时间和结束时间范围内的多个计划；
将所述多个计划中优先级等级最高的计划作为目标计划，以基于下单金额和所述目标计划中的佣金比例，计算支付给推客的佣金金额。
根据本发明实施例的技术方案，针对现有MySQL存储计划过多，导致计划查询缓慢以及可能存在的崩溃问题，提出一种基于正、倒排索引及CQRS架构的计划查询方案：
1)通过CQRS架构将计划的读写进行了分离，更易去维护。
2)建立正、倒排索引，避免了逐一查找比对的过程；
3)在计划信息较少和JVM资源充足的情况下，可以将正排索引也写入内存，以提高接口性能，否则只将倒排索引存储于JVM，虽然损失部分性能，但是提高了系统的稳定性、可用性，面对日益增长的推广，也不会产生存储瓶颈。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。
- 一种佣金数据处理方法和装置
- 一种佣金分配的方法及装置