一种消息推送方法、装置及设备与流程

本申请涉及计算机
技术领域：
，尤其涉及一种消息推送方法、装置及设备。
背景技术：
：现有技术中，随着互联网技术的快速发展，直播应用得到了越来越多用户的青睐，直播应用的产品种类也越来越多。如何提供更好的直播服务，成为了影响用户使用直播体验的关键。然而，现在的直播种类繁多，需要选择好的信息内容的传播方式作为有效的内容运营手段，直播前的开播通知方式，由于可以激活一定的僵尸用户，提高用户粘性，增加产品功能曝光度，所以在直播领域应用较广泛。目前，现有技术中由于用户数据无法打上所有维度的标签，而推送系统和用户系统和业务系统常常不在同一服务下面。此时，现有技术中首先会从系统中找出某一主播对应的所有粉丝，再基于各种预设条件从所有的粉丝中筛选出真正的有效用户，然后针对有效用户进行直播消息的推送，然而从众多的粉丝中筛选出真正的有效用户这一过程，是一项数据量非常庞大的任务，例如：很多主播拥有的粉丝超过一千万，而这一千万粉丝中仅有几百个有效用户，此时如果从一千万的粉丝数据中层层过滤筛选出几百个有效用户，服务器的工作量极大，筛选的效率较低，从而导致消息推送效率低。技术实现要素：有鉴于此，本申请实施例提供了一种消息推送方法、装置及设备，用于减少消息的推送时延，提高消息推送的效率。为解决上述技术问题，本说明书实施例是这样实现的：本说明书实施例提供的一种消息推送方法，包括：获取第一有效用户集合；所述第一有效用户集合中的有效用户为在规定时间内有活跃行为的用户；确定所述第一有效用户集合中各个有效用户关注的主播；从所述第一有效用户集合中，确定各个主播对应的第二有效用户集合；向所述第二有效用户集合中的各个有效用户进行消息推送。可选的，所述确定所述第一有效用户集合中各个有效用户关注的主播，具体包括：从关注系统中确定所述第一有效用户集合中各个有效用户对应的主播；所述关注系统中包含用户与主播之间的关注关系。可选的，确定所述各个主播对应的第二有效用户集合，具体包括：以所述各个主播为维度，对所述有效用户进行分类汇总，得到各个主播对应的第二有效用户集合。可选的，所述确定各个主播对应的第二有效用户集合之后，还包括：将所述第二有效用户集合以map数据结构形式进行存储。可选的，所述将所述第二有效用户集合以map数据结构形式进行存储，具体包括：查询所述map数据结构中是否存在所述各个主播对应的第三有效用户集合，得到查询结果；当所述查询结果表示所述map数据结构中存在所述第三有效用户集合时，将所述第三有效用户集合与所述第二有效用户集合进行去重合并，得到第四有效用户集合，并将所述第四有效用户集合以map数据结构形式进行存储；当所述查询结果表示所述map数据结构中不存在所述第三有效用户集合时，将所述第二有效用户集合以map数据结构形式进行存储。可选的，所述将所述第二有效用户集合以map数据结构形式进行存储之后，还包括：对于所述各个主播，遍历每个所述map数据结构，从每个所述map数据结构中获取各个主播对应的第二有效用户集合；将所述第二有效用户集合转换为第一字符串；将所述各个主播的主播标识作为key值，所述第一字符串作为value值，存储在数据库中。可选的，所述将所述各个主播的主播标识作为key值，所述第一字符串作为value值，存储在数据库中，具体包括：判断所述数据库中是否存在所述key值，得到判断结果；当所述判断结果表示所述数据库中不存在所述key值时，将所述key值和value值存储在所述数据库中。可选的，所述判断所述数据库中是否存在所述key值，还包括：当所述判断结果表示所述数据库中存在所述key值时，将所述数据库中的key值对应的第二字符串与所述第一字符串进行去重合并，得到第三字符串；将所述第三字符串作为value值，对应所述key值存储在所述数据库中。可选的，所述向所述第二有效用户集合中的各个有效用户进行消息推送，具体包括：在所述主播开播之前，向所述第二有效用户集合中的各个有效用户进行消息推送。本说明书实施例提供的一种消息推送装置，包括：第一有效用户获取模块，用于获取第一有效用户集合；所述第一有效用户集合中的有效用户为在规定时间内有活跃行为的用户；主播确定模块，用于确定所述第一有效用户集合中各个有效用户关注的主播；第二有效用户确定模块，用于从所述第一有效用户集合中，确定各个主播对应的第二有效用户集合；消息推送模块，用于向所述第二有效用户集合中的各个有效用户进行消息推送。本说明书实施例提供的一种消息推送设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行所述一种消息推送方法。一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，所述指令被处理器执行时实现所述一种消息推送方法的步骤。本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：通过直接获取有效用户，并针对有效用户确定关注的主播，再确定主播对应的有效用户集合，对每个主播对应的有效用户进行针对性的消息推送，避免了从大量粉丝中筛选有效用户的操作，减少了通知消息的推送时延，提高了消息推送的效率。附图说明此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1为本说明书实施例1提供的一种消息推送方法的流程示意图；图2为本说明书实施例1提供的一种消息推送界面示意图；图3为本说明书实施例2提供的一种主播-有效用户维护方法的流程示意图；图4为本说明书实施例提供的对应于图1的一种消息推送装置的结构示意图；图5为本说明书实施例提供的对应于图1的一种消息推送设备的结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。现有技术中进行消息推送时，常见的处理过程为：获取主播对应的所有粉丝→从所有粉丝中层层筛选，得到有效用户。然而在筛选过程中，需要耗费大量的时间，且当同时好多个主播进行直播时，服务器处理的数据量越来越大，可能会导致服务器崩溃，而无法筛选出有效用户。例如：某主播拥有一千万的粉丝，需要从1000万的粉丝中筛选出500个有效用户，此时，系统需要过滤大量无效的用户，若多个主播同时开播，系统需要过滤的数据量会越来越大，导致服务器压力增大，且处理时间较长，假设整个处理时长需要用时一小时零40分钟，收到开播通知请求指令时距离开播还有40分钟，而直播时长为30分钟，此时意味着当系统将无效用户过滤完成并将推送通知准确发送给每个有效用户时，直播已经结束，此时有效用户收到的信息为无效信息。为了克服现有技术中的问题，下面结合附图，详细说明本申请各实施例提供的技术方案。实施例1图1为本说明书实施例1提供的一种消息推送方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。如图1所示，一种消息推送方法的方法步骤如下：s101：获取第一有效用户(availuser)集合；所述第一有效用户集合中的有效用户为在规定时间内有活跃行为的用户。需要说明的是，有效用户集合也可以称作是有效用户列表，可以包括多个有效用户的集合，可以用avail_user_list进行表示。在获取第一有效用户集合时，可以从第三方应用平台中的推送系统(push_sys，简称push系统)中进行获取，第一有效用户集合可以定义为是：在第三方应用平台中规定时间之内有活跃行为的用户集合，这里提到的活跃行为可以是在规定时间之内登陆时间达到预设时间的用户，也可以是在规定时间内登陆频率符合预设范围的用户等等，例如：某小程序中制定具有表单(formid)的用户才能收到推送的规则，五天内在某个小程序有活跃行为即可生成formid上报给服务器。s102：确定所述第一有效用户集合中各个有效用户关注的主播。在直播平台的关注系统中存在着主播与用户的关注关系，在第三方应用平台的关注系统(attention_sys)中也存在第三方用户与关注主播的对应关系，同一用户在直播平台中的id账号或者昵称与在第三方应用平台中的id账号或者昵称可能不同，此时，在所述直播平台与所述第三方应用平台之间进行交互时需要找出同一用户在不同应用平台的对应关系，例如：用户a在直播平台的id账号为x，在所述直播平台中存在主播1与账号x的关注关系，此时在第三方应用平台的关注系统中存在的映射关系为：主播1与账号y，其中账号y为用户a在第三方应用平台中的注册账号。上述步骤中，从第一有效用户集合中提取出每个有效用户，然后从关注系统中确定每个有效用户关注的主播。例如：第一有效用户集合为：{a、b、c、d、e、f}，将所有的有效用户提取出来，分别得到每个有效用户关注的主播集合为：a→{主播1、主播3、主播4、主播7}，b→{主播1、主播2、主播6、主播7}，c→{主播2、主播3、主播5、主播7}，d→{主播2、主播3、主播4、主播7}，e→{主播1、主播4、主播6、主播7}，f→{主播2、主播3、主播5、主播7}。s103：从所述第一有效用户集合中，确定各个主播对应的第二有效用户集合。步骤s103，具体可以包括：以所述各个主播为维度，对所述有效用户进行分类汇总，得到各个主播对应的第二有效用户集合。例如：延用步骤s102中的例子，以主播为维度，分类汇总后得到的集合为：主播1→{a、b、e}，主播2→{b、c、d、f}，主播3→{a、c、d、f}，主播4→{a、d、e}，主播5→{c、f}，主播6→{b、e}，主播7→{a、b、c、d、e、f}。s104：向所述第二有效用户集合中的各个有效用户进行消息推送。在进行推送时，根据直播的对象进行推送，在同一时间可能会有对个主播通知直播，也可能只有一个主播进行直播，例如(延用步骤s103中的例子)：当主播1要进行直播时，根据映射关系：主播1→{a、b、e}，可知，可向用户a、用户b、用户e进行开播消息推送。图2为本说明书实施例1提供的一种消息推送界面示意图，如图2所示，为了保证有效用户能及时观看直播，在进行推送时，应该满足在所述主播开播之前，向所述第二有效用户集合中的各个有效用户进行消息推送。图2中会在服务通知中将消息推送给用户，推送的消息中包括主播的姓名(昵称)、直播主题(日程主题)、直播开场时间以及备注消息，若用户感兴趣可以直接点击“进入小程序查看”进入直播间，若用户以后不想再接收到与该直播相关的推送消息，可以点击“拒收通知”进行拒收。从图中可看出直播开场时间为2019年1月3日20:21，该消息推送给用户的时间为当天的19：51，即在进行推送时，应该满足在所述主播开播之前，向所述第二有效用户集合中的各个有效用户进行消息推送。当得到所述第二有效用户集合后，需要将所述第二有效用户集合以map数据结构形式进行存储。具体可以包括：查询所述map数据结构中是否存在所述各个主播对应的第三有效用户集合，得到查询结果；当所述查询结果表示所述map数据结构中存在所述第三有效用户集合时，将所述第三有效用户集合与所述第二有效用户集合进行去重合并，得到第四有效用户集合，并将所述第四有效用户集合以map数据结构形式进行存储；当所述查询结果表示所述map数据结构中不存在所述第三有效用户集合时，将所述第二有效用户集合以map数据结构形式进行存储。map数据结构是一种依照键值对的形式进行存储的数据结构。键值即key值。key值可以表示任何类型的对象，每个键值必须与一个相应的值对应存储。在将所述第二有效用户集合以map数据结构形式进行存储时，为了不浪费数据库中的存储空间，需要首先以主播号为索引，查询数据结构中是否已经存在相同的用户列表，比较存在的用户列表与准备存储的用户列表是否相同，若都相同则不必重复存储，若不存则新建相应的用户列表。所述将所述第二有效用户集合以map数据结构形式进行存储之后，还可以包括：对于所述各个主播，遍历每个所述map数据结构，从每个所述map数据结构中获取各个主播对应的第二有效用户集合；将所述第二有效用户集合转换为第一字符串；将所述各个主播的主播标识作为key值，所述第一字符串作为value值，存储在数据库中。所述将所述各个主播的主播标识作为key值，所述第一字符串作为value值，存储在数据库中，具体可以包括：判断所述数据库中是否存在所述key值，得到判断结果；当所述判断结果表示所述数据库中不存在所述key值时，将所述key值和value值存储在所述数据库中。当所述判断结果表示所述数据库中存在所述key值时，将所述数据库中的key值对应的第二字符串与所述第一字符串进行去重合并，得到第三字符串；将所述第三字符串作为value值，对应所述key值存储在所述数据库中。数据库可以是redis数据库。redis数据库是一种in-memory型(即内存型)的key-value键值数据库，是一种非关系型数据库系统，数据在磁盘上是持久的，键类型是字符串，值类型是字符串、字符串集合(set)、sortedset、字符串列表(list)、哈希(hash)等。其中，hash类型是一种字符串为键、字符串为值的键值对集合，类似键值类型都为字符串的map。redis数据库中存在每个主播与对应的有效用户列表的映射关系。实施例1中的方法，通过从有效用户集合中确定每个有效用户关注的主播；然后再确定各个主播对应的第二有效用户集合，从而向各个有效用户进行消息推送，在无标签的业务推送系统中，能大大减少消息推送的时延，达到精准推送，提高推送效率。实施例2图3为本说明书实施例2提供的一种主播-有效用户维护方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。实施例2如图3所示，在实际应用中，需要对数据库中的映射关系表进行维护，具体步骤如下：s301：获取定时维护时间触发指令。s302：响应于所述时间触发指令，获取当前时间对应的第一有效用户集合。从推送系统中拉取当前时间的有效用户，当有效用户的数量超出预设数量时，可以通过分组有效用户分成多个线程进行并行处理，即可将avail_user_list分为avail_user_list1、avail_user_list2、avail_user_list3、avail_user_list4……avail_user_listn，提高处理效率。s303：将所述第一有效用户集合中的第一有效用户提取出来，分别调用关注系统，获取每个第一有效用户关注的主播列表。s304：将所述主播列表中的所有主播提取出来，生成所述每个主播对应的第二有效用户集合。s305：以所述每个主播为索引，查询数据库中的map数据结构中是否存在所述主播对应的有效用户集合，若存在，则将当前生成的第二有效用户集合中的第二有效用户对应的数据添加到map数据结构中的有效用户列表尾部，生成每个主播对应的粉丝列表。s306：若不存在，则在map数据结构中新建对应于所述主播的粉丝列表，所述粉丝列表即为所述第二有效用户集合。s307：以所述每个主播为索引，从数据库中查询是否存在对应的主播，若存在，则将当前的粉丝列表与所述数据库中存在的用户列表进行去重合并，生成新的有效用户列表并存储。s308：若不存在，则将所述主播以及所述主播对应的粉丝列表存储在数据库中。定时维护时，每一次都采用上述步骤对应的方法对数据库中的主播-有效用户列表进行更新维护。需要进一步说明的是，在进行存储时，数据库中的数据是以字符串的形式进行存储，具体的是从map数据结构中获取每个主播对应的有效用户列表，将所述有效用户列表转换为字符串(即fans_sting)，然后将主播作为key，fans_sting作为value，存储在redis数据库中。表1keyvalueanchor1fans_sting1anchor2fans_sting2anchor3fans_sting3anchor4fans_sting4表1为redis数据库中已存在的主播-有效用户对应关系表，fans_sting1对应的有效用户集合为{a，b，c，d}，fans_sting2对应的有效用户集合为{e，f，g，h}，fans_sting3对应的有效用户集合为{a，c，b，h}，fans_sting4对应的有效用户集合为{i，j，k，g}。其中，不同主播对应的粉丝列表中的粉丝可以重合。假设定时维护时生成的当前主播与粉丝列表的映射关系表如表2：表2keyvalueanchor1fans_list5anchor3fans_list6anchor7fans_list7anchor8fans_list8表2为新生成的主播-粉丝列表。其中，fans_list5对应的有效用户集合为{a，b，c，d、e、l}，fans_list6对应的有效用户集合为{a，c，b，m，n}，fans_list7对应的有效用户集合为{e，f，j，k}，fans_list8对应的有效用户集合为{b，m，j，k}。以表2中的主播类型为索引，从表1中查找是否存在对应的key，对比表1与表2，可见，anchor1与anchor3在表1中已存在，此时，对两表中anchor1对应的粉丝列表进行去重合并，即对fans_sting1与fans_list5进行去重合并，得到的有效用户集合为{a，b，c，d、e、l}，将该集合作为fans_sting5；对两表中anchor3对应的粉丝列表进行去重合并，即对fans_sting3与fans_list6进行合并去重，得到的有效用户集合为{a，c，b，h，m，n}，将该集合作为fans_sting6；另外，新生成的主播粉丝列表中的anchor7与anchor8在表1中不存在，此时，将anchor7与anchor8以及对应的粉丝列表添加进表1中，假设anchor7对应的fans_list7转换为字符串为fans_sting7，anchor8对应的fans_list8转换为字符串为fans_sting8，则更新维护后的redis数据库主播-有效用户对应关系表可以如表3所示：表3keyvalueanchor1fans_sting5anchor2fans_sting6anchor3fans_sting3anchor4fans_sting4anchor7fans_sting7anchor8fans_sting8表3为redis数据库中更新维护后的主播-有效用户对应关系表。其中，fans_sting5对应的有效用户集合为{a，b，c，d、e、l}，fans_sting6对应的有效用户集合为{a，c，b，h，m，n}，fans_sting3对应的有效用户集合为{a，c，b，h}，fans_sting4对应的有效用户集合为{i，j，k，g}，fans_sting7对应的有效用户集合为{e，f，j，k}，fans_sting8对应的有效用户集合为{b，m，j，k}。图2中的方法，采用timed_job(定时任务)的形式，从avail_user(有效用户)入手，将全量avail_user(有效用户)列表进行维护，从根本上解决了过滤大量无效的问题，将avail_user全量同步到系统中，利用avail_user从attention_sys(关注系统)中拉取avail_user所关注的anchor(主播)，建立数据关系，即主播和有效用户列表的关系(anchor--avail_user_list)。具体的，通过定时捞取关注系统中的有效用户，对数据库中存储的主播-有效用户列表进行维护更新，避免了从大量粉丝中筛选有效用户的大工作量操作，保证在主播开播时，能够准确及时地将消息和传送给主播对应的有效用户。相对于现有技术来说，本说明书实施例中的方案收到一个或多个主播直播开播指令后，直接从数据库中获取一个或多个主播直播对应的有效用户列表，省去了从大量粉丝中过滤得到有效用户的操作过程。例如：假设主播a对应的有效用户列表中包括500个有效用户，此时这500个用户均为有效用户，无需再次筛选，直接向该500个用户发送直播开播通知即可，整个处理时长可能只需要1-5分钟，此时，当所有的有效用户收到开播通知时，距离直播开播还有半个小时左右，能够做到及时通知有效用户做好观看直播的准备。因此，相对于现有技术来说，本说明书实施例提供的方案能降低推送系统处理数据的成本和压力，具有较高的消息推送效率且能实现精准推送。基于同样的思路，本说明书实施例还提供了上述方法对应的装置。图4为本说明书实施例提供的对应于图1的一种消息推送装置的结构示意图。如图4所示，该装置可以包括：第一有效用户获取模块401，用于获取第一有效用户集合；所述第一有效用户集合中的有效用户为在规定时间内有活跃行为的用户；主播确定模块402，用于确定所述第一有效用户集合中各个有效用户关注的主播；第二有效用户确定模块403，用于从所述第一有效用户集合中，确定各个主播对应的第二有效用户集合；消息推送模块404，用于向所述第二有效用户集合中的各个有效用户进行消息推送。所述主播确定模块402，具体可以包括：主播确定单元，用于从关注系统中确定所述第一有效用户集合中各个有效用户对应的主播；所述关注系统中包含用户与主播之间的关注关系。所述第二有效用户确定模块403，具体可以用于：以所述各个主播为维度，对所述有效用户进行分类汇总，得到各个主播对应的第二有效用户集合。所述装置，具体还可以包括：第一存储模块，用于将所述第四有效用户集合以map数据结构形式进行存储。第二存储模块，用于将主播与有效用户集合的对应关系进行存储。所述第一存储模块，具体可以包括：查询模块，用于查询所述map数据结构中是否存在所述各个主播对应的第三有效用户集合，得到查询结果；判断处理模块，用于当所述查询结果表示所述map数据结构中存在所述第三有效用户集合时，将所述第三有效用户集合与所述第二有效用户集合进行去重合并，得到第四有效用户集合，并将所述第四有效用户集合以map数据结构形式进行存储；当所述查询结果表示所述map数据结构中不存在所述第三有效用户集合时，将所述第二有效用户集合以map数据结构形式进行存储。所述第二存储模块，具体可以包括：第二有效用户获取单元，用于对于所述各个主播，遍历每个所述map数据结构，从每个所述map数据结构中获取各个主播对应的第二有效用户集合；转换单元，用于将所述第二有效用户集合转换为第一字符串；存储单元，用于将所述各个主播的主播标识作为key值，所述第一字符串作为value值，存储在数据库中。所述存储单元，具体可以用于：判断所述数据库中是否存在所述key值，得到判断结果；当所述判断结果表示所述数据库中不存在所述key值时，将所述key值和value值存储在所述数据库中。当所述判断结果表示所述数据库中存在所述key值时，将所述数据库中的key值对应的第二字符串与所述第一字符串进行去重合并，得到第三字符串；将所述第三字符串作为value值，对应所述key值存储在所述数据库中。所述消息推送模块404，具体可以包括：消息推送单元，用于在所述主播开播之前，向所述第二有效用户集合中的各个有效用户进行消息推送。基于同样的思路，本说明书实施例还提供了上述方法对应的设备。图5为本说明书实施例提供的对应于图1的一种消息推送设备的结构示意图。如图5所示，设备500可以包括：至少一个处理器510；以及，与所述至少一个处理器通信连接的存储器530；其中，所述存储器530存储有可被所述至少一个处理器510执行的指令520，所述指令被所述至少一个处理器510执行，以使所述至少一个处理器510能够：获取第一有效用户集合；所述第一有效用户集合中的有效用户为在规定时间内有活跃行为的用户；确定所述第一有效用户集合中各个有效用户关注的主播；从所述第一有效用户集合中，确定各个主播对应的第二有效用户集合；向所述第二有效用户集合中的各个有效用户进行消息推送。基于同样的思路，本说明书实施例还提供了上述方法对应的计算机可读存储介质。一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令被处理器执行时实现以下步骤：获取第一有效用户集合；所述第一有效用户集合中的有效用户为在规定时间内有活跃行为的用户；确定所述第一有效用户集合中各个有效用户关注的主播；从所述第一有效用户集合中，确定各个主播对应的第二有效用户集合；向所述第二有效用户集合中的各个有效用户进行消息推送。在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。当前第1页12