一种频率控制方法及装置
技术领域
本申请涉及互联网技术领域,尤其涉及一种频率控制方法及装置。
背景技术
在运营策略中,用户进入策略的频率对策略的有效性至关重要。相关技术中,在某一业务接收用户的请求之后,会通过发短信、发push的方式使用户了解自身已对该业务成功进行访问或者需求已成功发送了。因此,用户每触发一次,对资源、渠道、预算的消耗都是非常大的支出,无效的用户反复进入运营策略中,不仅影响到分析师的分析效率,也造成了资源的浪费,在增量用户日渐减少的趋势下,存量用户的有效运营必须依赖于频率的控制管理。
在实现本发明过程中,发明人发现:由于频率控制管理最主要是实时性和频控策略。对于用户频率数据实时性差的情况,不仅影响频率控制时间的滞后,还影响频率规则的控制效果。同时,频控策略的制定和处理,不仅影响频率控制最终效果,还可能影响用户体验和营销资源。
针对相关技术中存在的诸多技术问题,目前尚未提供有效的解决方案。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题,本申请提供了一种频率控制方法及装置。
第一方面,本申请实施例提供了一种频率控制方法,包括:
确定在至少一个候选业务类型中被选定的需要进行频率数据配置的目标业务类型;
获取对所述目标业务类型进行频率配置的频率配置数据;
根据所述频率配置数据生成与所述目标业务类型对应的所述目标频率控制策略;
根据所述目标频率控制策略对客户端的发起的请求进行管控。
可选的,如前述的频率控制方法,所述根据所述目标频率控制策略对客户端的请求进行响应,包括:
获取所述客户端的请求信息;
确定所述请求信息对应的所述目标业务类型;
根据所述请求信息得到对应的频率信息;所述频率信息包括:所述客户端发起的所述目标业务类型对应请求的频率;
查询得到与所述目标业务类型对应的目标频率控制策略;所述目标频率控制策略包括不同频率与响应策略之间的对应关系;
根据所述对应关系,执行与所述频率信息对应的响应策略。
可选的,如前述的频率控制方法,所述根据所述请求信息得到对应的频率信息,包括:
根据所述请求信息查询得到与所述客户端及所述目标业务类型对应的请求记录信息;
根据所述请求记录信息确定每个历史请求的历史请求时间;
确定所述请求信息对应的请求时间;
根据所述每个历史请求的历史请求时间以及所述请求信息对应的请求时间得到所述频率信息。
可选的,如前述的频率控制方法,所述频率信息满足所述目标频率控制策略,包括:
获取所述目标频率控制策略中包括的至少两个子策略;
确定不同的所述子策略之间的优先级顺序;
在按照所述优先级顺序依次判断所述频率信息均满足各个所述子策略时,判定所述频率信息满足所述目标频率控制策略。
可选的,如前述的频率控制方法,所述根据所述频率配置数据生成与所述目标业务类型对应的所述目标频率控制策略,包括:
获取对所述目标业务类型进行历史频率配置的历史频率配置数据;
对所述历史频率配置数据以及频率配置数据进行数据清洗后,确定每个子策略对应的最新频率配置数据;其中,所述目标业务类型至少对应有一个所述子策略;
根据所述每个子策略对应的最新频率配置数据,确定所述目标频率控制策略。
可选的,如前述的频率控制方法,在所述查询得到与所述目标业务类型对应的目标频率控制策略之后,还包括:
判断所述频率信息是否满足所述目标频率控制策略,并得到用于管控是否接受所述请求信息的频率控制信息;
对所述频率控制信息进行存储,并提供查询接口,以使查询方通过所述查询接口对所述频率控制信息进行查询。
可选的,如前述的频率控制方法,所述获取客户端的请求信息,包括:
获取业务对接端传输的离线数据,所述业务对接端对接有多个业务端,所述离线数据为所述业务端采集得到;
获取客户端请求收到的实时数据以及非实时数据;
在所述离线数据、实时数据以及非实时数据中提取得到所述客户端的请求信息。
第二方面,本申请实施例提供了一种频率控制装置,包括:
确定模块,用于确定在至少一个候选业务类型中被选定的需要进行频率数据配置的目标业务类型;
获取模块,用于获取对所述目标业务类型进行频率配置的频率配置数据;
生成模块,用于根据所述频率配置数据生成与所述目标业务类型对应的所述目标频率控制策略;
处理模块,用于根据所述目标频率控制策略对客户端的发起的请求进行响应。
第三方面,本申请实施例提供了一种电子设备,包括:处理器、通信接口、存储器和通信总线,其中,所述处理器、通信接口和存储器通过通信总线完成相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行所述计算机程序时,实现如前述任一项所述的控制方法。
第四方面,本申请实施例提供了一种非暂态计算机可读存储介质,其特征在于,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行如前述任一项所述的控制方法。
本申请实施例提供了一种频率控制方法及装置,其中方法包括:确定在至少一个候选业务类型中被选定的需要进行频率数据配置的目标业务类型;获取对所述目标业务类型进行频率配置的频率配置数据;根据所述频率配置数据生成与所述目标业务类型对应的所述目标频率控制策略;根据所述目标频率控制策略对客户端的发起的请求进行响应。本申请实施例提供的上述技术方案与现有技术相比具有如下优点:通过对不同的业务类型配置不同的频率配置数据,进而得到与每个业务类型对应的频率控制策略,可以提供统一频率控制管理,从而达到能够适应不同业务场景和实现综合频率策略控制管理的目的。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种频率控制方法流程图;
图2为本申请另一实施例提供的一种频率控制方法流程图;
图3为本申请另一实施例提供的一种频率控制方法流程图;
图4为本申请另一实施例提供的一种频率控制方法流程图;
图5为本申请实施例提供的一种频率控制装置的框图;
图6为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
常用频率控制要求可以是:用户每小时/每天的控N不大于一预设的定值。其中,控N为用于进行频率控制的定值,频率控制具体包括:某一场景下控制用户在一段时间内访问频率控制在N次以内,大于N次以上则限制用户有效访问。相关技术存在如下缺点:
(1)适配场景比较单一,无法实现不同复杂场景的频率控制管理。
(2)适配的颗粒度比较粗,无法实现综合频率策略的频率控制管理。
(3)缺乏统一频率控制管理,各业务线定制化重复开发频率控制管理。
图1为本申请实施例提供的一种频率控制方法,包括如下所述步骤A1至A4:
步骤A1.确定在至少一个候选业务类型中被选定的需要进行频率数据配置的目标业务类型。
具体的,候选业务类型可以是通过可视化展示的方式供配置人员进行选择,在配置人员选中了需要进行频率数据配置的候选业务类型之后,即将该选定的候选业务类型作为目标业务类型,进一步的,可以同时选定多个候选业务类型作为目标业务类型,以对多个业务类型的请求频率进行控制。
步骤A2.获取对目标业务类型进行频率配置的频率配置数据。
具体的,频率配置数据可以是通过可视化展示的方式供配置人员进行选择或填写以完成配置的目的。举例来说:配置人员可以选择控制的时间段长短(例如:24小时、1小时等等),然后填写对应时间段控制的请求的次数(例如:5次、10次等等)。
进一步的,可以配置多组频率配置数据,以得到不同的子策略,以实现精细化控制。
步骤A3.根据频率配置数据生成与目标业务类型对应的目标频率控制策略。
具体的,在得到频率配置数据之后,即可得到对应的控制策略,然后根据选定的目标业务类型,便可得到与目标业务类型对应的目标频率控制策略。
A4.根据目标频率控制策略对客户端的发起的请求进行响应。
具体的,在得到目标频率控制策略之后,可通过获取客户端发起的请求的频率,然后根据目标频率控制策略对客户端当前发起的请求进行管控,以判断是否针对当前发起的请求进行响应。
本实施例一种可选的实现方式可以是:通过API网关(HTTP/RPC网关服务)对外提供频率配置接口,以使配置人员可以根据不同业务场景和频率策略配置相关频率配置数据;进一步的,可以将频率配置数据缓存到Redis(缓存集群)为频率控制提供策略依据并同步存储到DB Store(持久化数据库)为频率配置提供灾备保证。Redis即为缓存集群管理:Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。支持对不同数据结构(String字符串、Hash散列、List列表、Set集合、Sorted Set有序集合)。
在根据目标频率控制策略对请求进行控制时,需要将缓存至Redis中,其中缓存格式可以是:基于对Redis缓存集群管理中对不同数据结构(String字符串、Hash散列、List列表、Set集合、Sorted Set有序集合)从业务读写和存储性能等多方面考虑,可以采用String字符串数据结构而非Hash散列(Key+Field+Value)数据结构存储频率数据,减少额外缓存资源消耗和缓存清理难度。其中key可以是频率规则、频率策略以及时间标识,并设置相应的缓存自动过期时间,value是频率的序列化结果数据。目标频率控制策略的缓存时效:基于缓存数据占用大量的内存资源,因此缓存的时效性至关重要。可以采用两种方式保证缓存数据的清理,第一种方式:主动缓存失效,在创建缓存数据时增加相应的缓存失效时间的控制;第二种方式:被动缓存清理,通过调度任务或事件驱动扫描相应的频率缓存过期时间,过滤相应已失效的缓存数据并进行相应的清理。
图2为本申请另一实施例提供的一种频率控制方法,步骤A4根据目标频率控制策略对客户端的发起的请求进行响应包括如下所述步骤S1至S5:
步骤S1.获取客户端的请求信息。
具体的,客户端的请求信息,可以是客户端在游客状态下向实现本实施例方法的服务器发起的请求,也可以是客户端上登录的一特定的账户发起的请求;还可以是通过该客户端发起的所有请求,包括:游客状态以及不同的登录账户发起的请求。
请求信息可以是针对某一特定业务或某一组业务发起的请求,例如:添加购物车、电子支付等等。
由于请求信息是由客户端发送得到的,因此请求信息中可以包括客户端的信息,举例的,根据频率管控的策略,客户端的信息可以是:账户信息、客户端标识信息、设备码中的一种或多种。
步骤S2.确定请求信息对应的目标业务类型。
具体的,由前述实施例可知,由于请求信息是针对业务发起的,因此,可以得到该请求信息对应的业务类型,在此处,将请求信息对应的业务类型表征为目标业务类型。
在此处,目标业务类型可以是一个或多个,举例的:当某一些业务类型的被访问频率需要进行统一管控时,则目标业务类型可以是多个;当请求信息对应的业务类型是单独管控时,则目标业务类型为一个。
步骤S3.根据请求信息得到对应的频率信息;频率信息包括:客户端发起的目标业务类型对应请求的频率。
具体的,由于请求信息是由客户端发送得到的,因此请求信息中会包括客户端的信息,在此处,客户端的信息以在客户端上登录的账号信息为例:可以在数据库中记录账号信息与请求之间的对应关系,进而可以得到与该账号信息对应的频率信息。
步骤S4.查询得到与目标业务类型对应的目标频率控制策略;目标频率控制策略包括不同频率与响应策略之间的对应关系。
具体的,目标频率控制策略可以是用于对目标业务类型的请求频率进行管控的策略,目标频率控制策略可以是事先人为配置得到,也可以是根据历史请求对服务器造成的运算压力自动分析得到;目标频率控制策略可以是:
1、按照自然时间段进行划分,例如每自然分钟访问次数低于5次时,对应的响应策略是,根据请求进行响应;当访问次数达到5次时,对应的响应策略是:不对请求进行响应。
2、以初次访问的时间为起始时间的某一时间段进行划分,例如每分钟内5次(举例的:当初次访问时间为11:05:25,则需要控制的是11:05:25至11:06:24之间可以访问5次,即:当11:05:25至11:06:24之间访问次数低于5次时,对应的响应策略是,根据请求进行响应;当该时间段中访问次数达到5次时,对应的响应策略是,不对请求进行响应),或每小时20次等等用于按照起始时间对请求次数进行限定的策略。
3、目标频率控制策略还可以是根据访问时间段进行管控的策略,当对于某一线上平台:中午12时至13时,以及18时至24时之间,是其访问量的高峰期,而其他时间段,访问量较少,为低峰期;为了防止某一用户访问频率过高占用太多资源,导致系统负荷增加,影响系统整体的稳定性,因此在高峰期的每分钟或每小时的访问频率限制为低于低峰期的访问频率。
步骤S5.根据对应关系,执行与频率信息对应的响应策略。
具体的,频率信息满足目标频率控制策略可以是:频率信息中表征的请求频率在目标频率控制策略限定的频率范围(例如:每分钟5次)内时,则说明其请求的频率未超过上限阈值,可以继续进行请求;因此可以接受该请求信息,并执行与请求信息对应的响应;进一步的,一个请求可以对应有一个或多个响应(例如:同时发送短信以及push信息),因此在接收到一个请求之后,可以执行一个或多个响应,只要符合应用中的具体使用场景即可。
采用本实施例中的方法,通过针对不同的业务类型确定不同的频率控制策略,可以实现每个业务场景都有特定的频控控制管理策略;此外,由于可与对接不同的业务类型,因此本方法可以适用于统一频率控制管理,从而达到适应不同业务场景和进行综合频率策略控制管理目的。
如图3所示,在一些实施例中,如前述的频率控制方法,步骤S3根据请求信息得到对应的频率信息,包括如下所述步骤S31至S34:
步骤S31.根据请求信息查询得到与客户端及目标业务类型对应的请求记录信息。
具体的,请求记录信息可以是用于记录不同的客户端发起与目标业务类型对应请求的信息;可选的,请求记录信息可以存储于特定的数据库中,并且可以通过数据表的形式对客户端发起目标业务类型对应请求的信息进行记录。进一步的,每个客户端对应不同的业务类型的可以有不同的请求记录信息。
其中一种可选的实现方式可以是:按照业务类型→客户端标识(用于区分不同的客户端)的方式查询得到与该客户端即目标业务类型对应的请求记录信息。
步骤S32.根据请求记录信息确定每个历史请求的历史请求时间;
具体的,历史请求为在接收本次的请求信息之前的请求。请求记录信息中可以包括每个历史请求的历史请求时间,历史请求时间可以是接收到历史请求的时间。
步骤S33.确定请求信息对应的请求时间。
具体的,请求时间可以是接收到请求信息的时间。之所以需要确定请求信息对应的请求时间,是为了以请求时间为时间点,往前追溯一时间段,以得到在该时间段中的历史请求的次数。
步骤S34.根据每个历史请求的历史请求时间以及请求信息对应的请求时间得到频率信息。
具体的,在得到所有历史请求的历史请求时间以及请求时间之后,即可得到不同时间段的频率信息。举例来说:当请求时间为2020年1月1日12:05:00时,若需要得到一小时内的频率信息,则需要得到历史请求时间在2020年1月1日11:05:01至2020年1月1日12:05:00之间的历史请求,当该时间段中的历史请求存在5个时,则频率信息为5个每小时。
进一步的,还可以自然时间段中的历史请求的次数得到频率信息;举例来说,可以是2020年1月1日当天的频率信息或2020年1月1日12:00:00至12:59:59一个小时内的频率信息。
如图4所示,在一些实施例中,如前述的频率控制方法,步骤S5频率信息满足目标频率控制策略,包括如下所述步骤S51至S53:
步骤S51.获取目标频率控制策略中包括的至少两个子策略。
具体的,目标频率控制策略中可以包括多个不同的子策略;举例来说:不同的子策略可以是用于判断不同时间段的请求频率是否满足预设要求的请求频率区间,进一步的:目标频率控制策略中可以包括:每分钟的请求频率控制策略,每小时的请求频率控制策略,每天的请求频率控制策略等等。
步骤S52.确定不同的子策略之间的优先级顺序。
具体的,优先级顺序为对不同的子策略逐个进行判断的顺序。其中一种可选的实现方法中,优先级顺序可以按照子策略对应时间段长短进行排序,由于时间段越短,囊括的历史请求就越少,因此计算频率信息所占用的计算资源也越少,可以有效降低数据处理量。
步骤S53.在按照优先级顺序依次判断频率信息均满足各个子策略时,判定频率信息满足目标频率控制策略。
具体的,当按照优先级顺序判断频率信息都符合各个子策略的时候,则判定频率信息是满足目标频率控制策略的,反之,当频率信息不满足其中一个子策略时,则判定频率信息不满足目标频率控制策略。
其中一种可选的实现方式可以是:通过API网关(HTTP/RPC网关服务)对外提供频率控制接口,按照相应频率配置(策略规则和策略顺序),对频率输入数据进行频率计算,比对当前频率输入数据是否满足预先配置的目标频率控制策略的要求。当频率输入数据在目标频率控制策略配置的范围之内,则返回频率控制通过;当频率输入数据在目标频率控制策略配置的范围之外,则返回频控控制不通过。
因而可以实现综合频率策略(例如:每天、每周、每月和总量)的频控控制管理。
在一些实施例中,如前述的频率控制方法,步骤A3根据频率配置数据生成与目标业务类型对应的目标频率控制策略,包括如下所述步骤A31至A33:
步骤A31.获取对目标业务类型进行历史频率配置的历史频率配置数据。
具体的,由于目标业务类型在此次进行频率配置之前,可能已事先进行过频率配置,因此会得到历史频率配置的历史频率配置数据。且一般的,历史频率配置数据也可以是存储在DB Store中。
步骤A32.对历史频率配置数据以及频率配置数据进行数据清洗后,确定每个子策略对应的最新频率配置数据;其中,目标业务类型至少对应有一个子策略。
具体的,在得到频率配置数据之后,之所以需要对历史频率配置数据以及频率配置数据进行数据清洗,是为了将重复配置的数据进行删除,避免无用的数据占用存储空间;同时,最新频率配置数据可以通过在每次进行频率配置时都记录各个频率配置数据对应的配置时间,进而通过该配置时间进行判断得到最新频率配置数据。
步骤A33.根据每个子策略对应的最新频率配置数据,确定目标频率控制策略。
具体的,当某一子策略存在最新频率配置数据时,一般将该数据作为其配置数据,并对原配置数据进行覆盖;当某一子策略不存在最新频率配置数据时,可以保留原来配置的数据,也可以对该子策略进行删除,具体可根据实际使用场景进行选择。
在一些实施例中,如前述的频率控制方法,在步骤S4查询得到与目标业务类型对应的目标频率控制策略之后,还包括如下所述步骤B1和B2:
步骤B1.判断频率信息是否满足目标频率控制策略,并得到用于管控是否接受请求信息的频率控制信息。
具体的,在判断频率信息满足目标频率控制策略时,则接受请求信息,且频率控制信息可以是不对请求信息进行管控,并执行相应的响应;在判断频率信息不满足目标频率控制策略时,则拒绝请求信息,且频率控制信息可以是对该请求信息进行管控,不执行相应的响应。
步骤B2.对频率控制信息进行存储,并提供查询接口,以使查询方通过查询接口对频率控制信息进行查询。
具体的,频率控制信息可以存储在特定的服务器中,并且频率控制信息的输出可以根据存储查询引擎(ES(开源分布式搜索引擎数据库)+Hbase(分布式的、面向列的开源数据库,用于实现分布式存储))对外提供频率管理统计分析接口数据。进一步的,可以:API网关(HTTP/RPC网关服务)、Data Analysis(数据分析)和Page Query(分页查询)等多种方式进行查询,能够快速精准的获取相关频率管理的统计分析数据并用于自身系统频率控制管理使用。
其中,Hbase:是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。具有:线性扩展支持节点扩展、数据存储在HDFS上备份机制健全、通过Zookeeper协调查找数据访问速度快等特点。
在一些实施例中,如前述的频率控制方法,所述步骤S1获取客户端的请求信息,包括如下所述步骤S11至S13:
步骤S11.获取业务对接端传输的离线数据,业务对接端对接有多个业务端,离线数据为业务端采集得到。
具体的,业务对接端可以是本身无法提供频率控制,需要通过实现本申请实施例方法的装置进行频率控制的其他业务端。
可选的,可以通过Hive(一种数据仓库工具,用于实现离线数据计算)+Kylin(一种分析型数据仓,用于实现离线数据存储)实现从业务端进行离线数据获取的目的。
其中,Hive:是基于Hadoop的一个数据仓库工具解决海量日志数据的分析工具,可以将结构化的数据文件映射为一张数据库表,并提供类SQL查询功能;具有:通过类SQL分析大数据避免程序分析、数据存储在HDFS上、数据映射成数据库和表、可存储大数据集对数据完整性和格式要求较低、采用MapReduce任务计算适合离线分析等特点。
Kylin:是ebay开发的一套OLAP(联机分析处理)系统,与Mondrian不同的是,它是一个MOLAP系统(Multidimension OLAP,多维数据库),主要用于支持大数据生态圈的数据分析业务,它主要是通过预计算的方式将用户设定的多维立方体缓存到Hbase中;具有:可扩展超快的基于大数据的OLAP引擎、交互式查询能力强、多维立方体架构、与BI工具(数据可视化工具)无缝整合等特点。
步骤S12.获取客户端请求收到的实时数据以及非实时数据。
具体的,客户端请求可以为:客户端通过实现本申请实施例方法的装置直接对某一业务端进行请求收到。
可选的,可以通过Kafka(一种高吞吐量的分布式发布订阅消息系统,用于实现实时数据缓存,可以处理消费者规模的网站中的所有动作流数据。具有:消息持久化、高吞吐量、支持集群分区消息和分布式数据并行加载)+Storm/Flume(Storm为一种分布式实时大数据处理系统,Flume为一种海量日志采集、聚合和传输的系统,两者用于共同实现实时流式数据计算,支持在日志系统中定制各类数据发送方,用于收集数据)实现实时数据的获取。可以通过MQ(Message Queue,消息队列,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构,适用于异步处理,应用解耦,流量削锋和消息通讯等场景)实现非实时数据获取。
步骤S13.在离线数据、实时数据以及非实时数据中提取得到客户端的请求信息。
具体的,在得到离线数据、实时数据以及非实时数据之后,可以通过关键字段等方法提取得到请求信息。
进而,采用本实施例中的方法可以提供统一频率输入对不同数据来源(实时数据/非实时数据、离线数据)进行统一频率数据输入、并进行相应的频率存储和频率控制,同时对外提供统一频率数据输出,减少不同数据交互平台的资源浪费。
如图5所示,根据本申请的另一方面,本申请实施例提供了一种频率控制装置,包括:
确定模块1,用于确定在至少一个候选业务类型中被选定的需要进行频率数据配置的目标业务类型;
获取模块2,用于获取对目标业务类型进行频率配置的频率配置数据;
生成模块3,用于根据频率配置数据生成与目标业务类型对应的目标频率控制策略;
处理模块4,用于根据目标频率控制策略对客户端的发起的请求进行响应。
具体的,本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述,此处不再赘述。
根据本申请的另一个实施例,还提供一种电子设备,包括:如图6所示,电子设备可以包括:处理器1501、通信接口1502、存储器1503和通信总线1504,其中,处理器1501,通信接口1502,存储器1503通过通信总线1504完成相互间的通信。
存储器1503,用于存放计算机程序;
处理器1501,用于执行存储器1503上所存放的程序时,实现上述方法实施例的步骤。
上述电子设备提到的总线可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(DigitalSignalProcessing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
本申请实施例还提供一种非暂态计算机可读存储介质,非暂态计算机可读存储介质存储计算机指令,计算机指令使计算机执行上述方法实施例的步骤。
需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的具体实施方式,使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。