一种弹幕消息处理方法、装置与弹幕系统与流程

1.本技术涉及计算机技术领域，尤其涉及一种弹幕消息处理方法、装置与弹幕系统。


背景技术：

2.随着直播娱乐的兴起，直播的功能也越来越丰富，而直播系统中的弹幕功能是较为重要的一种互动功能。目前，弹幕功能主要通过下述两种方案实现：
3.方案一：
4.消息系统和直播系统单独部署。用户发送一条弹幕消息时，直播系统进行业务处理时读取直播间用户信息，然后遍历所有用户信息，再根据用户信息查询长链接的物理地址缓存，之后向每个用户发送http协议请求到消息系统，消息系统通过长链接将弹幕消息推送给用户。
5.该方案在百万直播的场景中，大部分的资源消耗都来源于服务与服务之间的通信，尤其是在发送弹幕请求量较大的情况下，因http资源的占用会导致其它接口无法达到，以致无法承受百万数据的并发量。
6.方案二：
7.消息系统、直播系统和弹幕系统单独部署。当用户进入直播间的时候按照直播间号进行分桶，以直播间为单位。假设每个桶为500人，当桶满500人时会创建新的桶存放用户信息。当用户发送一条消息时，消息服务会把这条消息发送给弹幕系统，弹幕系统会在该直播间分桶中随机选择一个桶，当选择一个桶后，遍历便利该桶的用户信息，再根据用户信查询长链接的物理地址缓存，之后通过dubbo分发到对应消息系统的物理机上，消息系统再将弹幕消息推送给用户。
8.该方案因在下发弹幕消息时对要接收弹幕消息的用户人数进行限流，这样会造成一条弹幕消息最多只能被500人接收，其他观众收不到这条弹幕消息，并且因为是随机选桶策略可能会造成某些观众一直接收不到弹幕消息，不适用百万数据的并发量场景。


技术实现要素：

9.本技术实施例提供了一种弹幕消息处理方法、装置与弹幕系统，以在弹幕消息并发量较大的情况下，减小服务器压力，提升系统稳定性。
10.本技术实施例采用下述技术方案：
11.第一方面，本技术实施例提供一种弹幕消息处理方法，该方法包括：
12.获取在单位时间内一个或多个第一客户端发送的一个或多个弹幕消息，根据单位时间的序号与存储列表的对应关系，将所述一个或多个弹幕消息存储到对应的存储列表内；
13.获取第二客户端发送的拉取弹幕请求，根据所述拉取弹幕请求对应的查询时间从相应的存储列表中查询目标弹幕消息，并将查询到的目标弹幕消息返回客户端。
14.第二方面，本技术实施例还提供一种弹幕消息处理装置，该装置包括：
15.存储单元，用于获取在单位时间内一个或多个第一客户端发送的一个或多个弹幕消息，根据单位时间的序号与存储列表的对应关系，将所述一个或多个弹幕消息存储到对应的存储列表内；
16.处理单元，用于获取第二客户端发送的拉取弹幕请求，根据所述拉取弹幕请求对应的查询时间从相应的存储列表中查询目标弹幕消息，并将查询到的目标弹幕消息返回客户端。
17.第三方面，本技术实施例还提供一种弹幕系统，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行弹幕消息处理方法。
18.第四方面，本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的弹幕系统执行时，使得所述弹幕系统执行弹幕消息处理方法。
19.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：
20.本技术实施例在接收到客户端发送的弹幕消息时，不会直接将弹幕消息下发给所有用户，而是将弹幕消息缓存起来，以减少服务器的下行压力；在获取到弹幕消息时，将弹幕消息按照时间分片存储，这样在需要下发弹幕消息时，根据拉取弹幕请求的查询时间从存储列表中即可快速查询目标弹幕消息，将查询到的目标弹幕消息一次性下发给拉取弹幕请求的用户，避免服务器使用较多的资源来维护用户信息，进一步减少服务器压力，使得本实施例尤其适用于直播环境下的百万数据的并发量场景。
附图说明
21.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
22.图1为本技术实施例中一种弹幕消息处理方法的流程图；
23.图2为本技术实施例中一种弹幕消息的存储结构示意图；
24.图3为本技术实施例中一种弹幕消息上行处理的示意图；
25.图4为本技术实施例中一种弹幕消息下行处理的示意图；
26.图5为本技术实施例中一种弹幕消息出装置的结构框图；
27.图6为本技术实施例中一种弹幕系统的结构示意图。
具体实施方式
28.为便于理解本技术实施例的技术方案，对本技术实施例中涉及的相关术语进行说明。
29.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
30.以下结合附图，详细说明本技术各实施例提供的技术方案。
31.图1为本技术实施例中一种弹幕消息处理方法的流程图，图1中的方法应用于弹幕
系统，如图1所示，本实施例的方法包括以下步骤：
32.s110，获取在单位时间内一个或多个第一客户端发送的一个或多个弹幕消息，根据单位时间的序号与存储列表的对应关系，将所述一个或多个弹幕消息存储到对应的存储列表内。
33.这里单位时间可以根据服务器所支持的并发量进行设置，若服务器所支持的并发量大，单位时间可以设置的长一些，若服务器所支持的并发量小，单位时间可以设置的短一些。例如可以将单位时间设置为5秒、6、或10秒等，本实施例对此不做限定。
34.本实施例预先构建单位时间的序号与存储列表之间的对应关系，存储列表以时间块为标识，存储列表的时间块与单位时间的序号对应。例如参考图2，若单位时间为5秒，第一个单位时间(0～5秒)内获取到的弹幕消息存储到时间块为0～5秒的存储列表中，第二个单位时间(5～10秒)内获取到的弹幕消息存储到时间块为5～10的存储列表中，单位时间的序号数量可以根据应用需要进行设定，本实施例示例性地设置为12个，显然也可以设置其他数量，本实施例对此不做限定。
35.s120，获取第二客户端发送的拉取弹幕请求，根据所述拉取弹幕请求对应的查询时间从相应的存储列表中查询目标弹幕消息，并将查询到的目标弹幕消息返回客户端。
36.这里可以为客户端设置消息拉取策略，这样可以按照预先设定的消息拉取策略获取第二客户端发送的拉取弹幕请求。消息拉取策略包括但不限于：定时拉取、当前弹幕显示完毕后拉取、根据拉取指令拉取等策略。
37.需要说明的是，这里的拉取弹幕请求对应用层上的用户来说，用户是无感知的，即无需用户执行专门的操作来触发客户端发送拉取弹幕请求，客户端执行的拉取弹幕请求的发送动作是由直播平台中的弹幕系统所规定的，客户端只要达到弹幕系统规定的消息拉取策略，即向弹幕系统发送拉取弹幕请求。
38.由图1所示可知，本实施例在接收到客户端发送的弹幕消息时，不会直接将弹幕消息下发给所有用户，而是将弹幕消息缓存起来，以减少服务器的下行压力；在获取到弹幕消息时，将弹幕消息按照时间分片存储，这样在需要下发弹幕消息时，根据拉取弹幕请求的查询时间从存储列表中即可快速查询目标弹幕消息，将查询到的目标弹幕消息一次性下发给拉取弹幕请求的用户，避免服务器使用较多的资源来维护用户信息，进一步减少服务器压力，使得本实施例尤其适用于直播环境下的百万数据的并发量场景。
39.在一个实施例中，上述步骤s110中是解析一个或多个弹幕消息，获取发送每个弹幕消息的第一客户端的直播间标识和弹幕消息的时间标识；获取直播间标识对应的存储区域，按照时间标识指示的消息写入时间，将一个或多个弹幕消息顺序地存储到与单位时间的序号对应的得存储列表中。
40.本实施例配置redis(remote dictionary server，远程字典服务)数据库对弹幕消息进行缓存，在弹幕系统初始化时，建立直播间标识与存储区域的对应关系，例如直播间的房间号在直播平台上具有唯一性，可以将直播间的房间号作为直播间标识，将直播间的房间号与存储区域关联起来，这样一个或多个客户端在房间号为xxx的直播间发送n条弹幕消息时，弹幕系统在0～5秒内接收到该n条弹幕消息并解析后，将这n条弹幕消息按照消息写入时间的先后顺序，顺序地写入至存储区域aa的时间块为0～5秒的存储列表内，其中房间号xxx对应存储区域aa。
41.在一个实施例中，在存储弹幕消息之前，还解析一个或多个弹幕消息的类型标识；若类型标识弹幕消息为房间消息，按照时间标识指示的消息写入时间将一个或多个弹幕消息顺序地存储到与单位时间的序号对应的得存储列表中；若类型标识弹幕消息为全平台广播消息的情况下，不存储消息并将弹幕消息直接下发。
42.直播平台中通常包括全平台广播消息与房间消息，由于全平台广播消息的并发量通常较少，且在实际应用中时效性较强，因此，本实施例在判断出弹幕消息为全平台广播消息时，直接将该弹幕消息进行下发。而直播平台中的房间消息并发量通常比较大，本实施例所述的大数据量的弹幕消息的并发也是指房间消息，且房间消息的时效性相对不如全平台广播消息强，因此，本实施例在判断出弹幕消息为房间消息时，将房间消息缓存到redis数据库中。
43.这里，在类型标识弹幕消息为房间消息的情况下，根据所述弹幕消息的消息写入时间判断所述弹幕消息是否过期，例如对比消息写入时间与当前时间，若时间差不大于预设值，则没有过期，此时获取所述弹幕消息对应的房间消息的类型，房间消息的类型与存储列表种类具有对应关系，根据所述对应关系将所述弹幕消息存储到与其房间消息的类型对应种类的存储列表中；若时间差值大于预设值，则所述弹幕消息过期，此时丢弃所述弹幕消息。
44.在直播平台中，房间消息通常包括普通消息和重要消息，重要消息可以为送礼物消息，除重要消息外的其他房间消息为普通消息，这里重要消息可以进行设置。为便于直播平台中分开处理普通消息和重要消息，例如普通消息的过期时间短于重要消息的过期时间，本实施例为每个直播间标识对应的存储区域设置第一类存储区域和第二类存储区域，参考图2，第一类存储区域用于存储普通消息，第二类存储区域用于存储重要消息。这样在判断出房间消息为普通消息时，将该普通消息存储到第一类存储区域内的存储列表中，在判断出房间消息为重要消息时，将重要消息存储到第二类存储区域的存储列表中。
45.在一个实施例中，每个存储列表都对应设置有过期时间，当存储列表中的弹幕消息写入到存储列表中的时间超过该过期时间时，删除所述弹幕消息。
46.由此，通过上述步骤可以将各类弹幕消息进行相应处理，这样，在获取拉取弹幕请求的情况下，解析该拉取弹幕请求，获取发送弹幕消息的第二客户端的直播间标识和消息拉取偏移量；查询第二客户端的直播间标识对应的存储区域，并从存储区域内确定查询时间对应的存储列表，获取以消息拉取偏移量为起点的存储列表中的全量数据作为目标弹幕消息。
47.由于本实施例中的存储区域的种类与房间消息的类型对应，通常房间消息包括普通消息和重要消息两种类型，相应的，存储区域也包括第一类存储区域和第二类存储区域。那么在查询第二客户端的直播间标识对应的存储区域时，应查询全部种类的存储区域，即查询第一类存储区域和第二类存储区域。
48.这里获取发送弹幕消息的第二客户端的直播间标识应理解为获取当前时刻下第二客户端的直播间标识。实际应用中，由于用户操纵客户端频繁切换直播间，存在弹幕消息串直播间的情况，本实施例获取第二客户端在当前时刻下的直播间标识，而不是获取第二客户端在发送拉取弹幕请求的时间，这样在面对第二客户端在直播间a发送拉取弹幕请求后，切换到直播间b中的类似情形时，由于此时获取的是直播间b的直播间标识，目标弹幕消
息也是返回到直播间b，因此不存在弹幕消息串直播间的情况。
49.这里消息拉取偏移量指示了在存储列表中的查询起点，参考图2，若拉取弹幕请求携带的消息拉取偏移量指示为3，该拉取弹幕请求对应图2中第一类存储区域中时间块为5～10秒的存储列表，则在时间块为5～10秒的存储列表中第三个数据块开始读取弹幕消息直至该存储列表中的最后一个数据块。
50.本实施例查询到的目标弹幕消息通常包括多个弹幕，为节省通信资源，将目标弹幕消息打包为一条消息下发给第二客户端。下面结合图3与图4，详细说明本技术对弹幕消息的处理过程。
51.如图3所示，客户端使用mqtt(message queuing telemetry transport，消息队列遥测传输协议)到长连接接入代理服务，客户端可以为web环境下的客户端，也可以为pc(个人计算机)、android(安卓)、ios(苹果公司开发的移动操作系统)等操作系统下的客户端。
52.这里长连接接入代理服务中启动moveim弹幕生产者，弹幕系统中启动moveim弹幕消费者，通过moveim弹幕消费者与moveim弹幕生产者，实现长连接接入代理服务与弹幕系统之间的通信，moveim弹幕生产者在基于mqtt接收到消息时，可以根据消息的topic区分该消息是否为弹幕消息，如果是弹幕消息则使用rpc(romote procedure call，远程过程调用)协议调用弹幕系统。
53.当弹幕系统的moveim弹幕消费者接收到有新的弹幕消息时，首先通过上行链up chain对弹幕消息进行消息过滤，当弹幕消息的内容没问题时，将弹幕消息通过下行链down chain进行过期、消息种类分类等处理后，将弹幕消息以json格式存入mq(message queue，消息队列)服务。这里图3示例性的以kafka实现mq服务。
54.kafka最初由linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统，也可以当做mq系统，常见可以用于web/nginx日志、访问日志，消息服务等等。
55.当弹幕系统的moveim弹幕消费者消费mq消息队列时，如果弹幕消息为全平台广播消息，那么将会直接发送给所有长连接接入代理服务并进行遍历所有在线用户下发消息。如果弹幕消息为房间消息，将消息写入时间和当前时间进行对比，如果对比结果表明该弹幕消息超时，则将该弹幕消息将会被丢弃，如果对比结果表明该弹幕消息未超时，将这条弹幕消息写入redis缓存。
56.如图4所示，同样的，客户端使用mqtt(message queuing telemetry transport，消息队列遥测传输协议)到长连接接入代理服务，客户端可以为web环境下的客户端，也可以为pc(个人计算机)、android(安卓)、ios(苹果公司开发的移动操作系统)等操作系统下的客户端。
57.这里长连接接入代理服务中启动moveim弹幕消费者，弹幕系统中启动moveim弹幕生产者，通过moveim弹幕消费者与moveim弹幕生产者实现长连接接入代理服务与弹幕系统之间的通信，moveim弹幕消费者在基于mqtt接收到消息时，可以根据消息的topic区分该消息是否为拉取弹幕请求，如果是拉取弹幕请求则将该拉取弹幕请求发送给弹幕系统的moveim弹幕生产者，moveim弹幕生产者根据该拉取弹幕请求的查询时间从redis缓存中进行数据查询，得到查询结果，并将查询结果打包为一条消息发送给长连接接入代理服务的moveim弹幕消费者，通过moveim弹幕消费者将该消息推送给客户端。
58.结合图4与图5的描述，本实施例的弹幕消息处理方法尤其适用于百万并发的弹幕系统，该处理方法至少存在以下优势：
59.1、当客户端发送一条弹幕消息时，该弹幕消息不会直接发送给所有客户端，而是存储到缓存中，用于减少服务器下行的压力。
60.2、通过客户端主动从缓存中拉取弹幕消息，将缓存中缓存的百万弹幕消息分批次下发，并在每次下发过程中，将多个目标弹幕消息打包为一条消息，可以进一步减少服务器的压力。
61.3、由于是客户端主动拉取弹幕消息，因此不会存在弹幕消息串直播间的情况。
62.4、弹幕系统对接收到的弹幕消息进行过滤，过滤掉内容不符合要求的弹幕消息，保证直播过程中弹幕内容的健康。
63.5、在接收到新的弹幕消息时，使用mq服务作为中间件对百万并发的弹幕消息进行缓存，可以缓解大数据量对弹幕系统的冲击，保证弹幕系统的稳定。
64.图5为本技术实施例中一种弹幕消息处理装置的结构框图，本实施例的装置应用于弹幕系统，如图5所示，弹幕消息处理装置500包括：
65.存储单元510，用于获取在单位时间内一个或多个第一客户端发送的一个或多个弹幕消息，根据单位时间的序号与存储列表的对应关系，将所述一个或多个弹幕消息存储到对应的存储列表内；
66.处理单元520，用于获取第二客户端发送的拉取弹幕请求，根据所述拉取弹幕请求对应的查询时间从相应的存储列表中查询目标弹幕消息，并将查询到的目标弹幕消息返回客户端。
67.在一个实施例中，存储单元510，用于解析所述一个或多个弹幕消息，获取发送所述每个弹幕消息的第一客户端的直播间标识和弹幕消息的时间标识；获取所述直播间标识对应的存储区域，按照时间标识指示的消息写入时间将所述一个或多个弹幕消息顺序地存储到与所述单位时间的序号对应的得存储列表中。
68.在一个实施例中，存储单元510，进一步用于解析所述一个或多个弹幕消息的类型标识；若所述类型标识所述弹幕消息为房间消息，按照时间标识指示的消息写入时间将所述一个或多个弹幕消息顺序地存储到与所述单位时间的序号对应的得存储列表中；若所述类型标识所述弹幕消息为全平台广播消息的情况下，不存储所述消息并将所述弹幕消息直接下发。
69.在一个实施例中，存储单元510，进一步用于若所述类型标识所述弹幕消息为房间消息，根据所述弹幕消息的消息写入时间判断所述弹幕消息是否过期，若没有过期，则获取所述弹幕消息对应的房间消息的类型，房间消息的类型与存储列表种类具有对应关系，根据所述对应关系将所述弹幕消息存储到与其房间消息的类型对应种类的存储列表中；若所述弹幕消息过期，则丢弃所述弹幕消息。
70.在一个实施例中，处理单元520，用于按照预先设定的消息拉取策略获取第二客户端发送的拉取弹幕请求。
71.在一个实施例中，处理单元520，进一步用于解析所述拉取弹幕请求，获取发送所述弹幕消息的第二客户端的直播间标识和消息拉取偏移量；查询所述第二客户端的直播间标识对应的存储区域，并从所述存储区域内确定所述查询时间对应的存储列表，获取以所
述消息拉取偏移量为起点的所述存储列表中的全量数据作为目标弹幕消息。
72.在一个实施例中，处理单元520，还用于将所述目标弹幕消息打包为一条消息下发给所述第二客户端。
73.能够理解，上述弹幕消息处理装置，能够实现前述实施例中提供的由弹幕系统执行的弹幕消息处理方法的各个步骤，关于弹幕消息处理方法的相关阐释均适用于弹幕消息处理装置，此处不再赘述。
74.图6是本技术的一个实施例弹幕系统的结构示意图。请参考图6，在硬件层面，该弹幕系统包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-access memory，ram)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
75.处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
76.存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
77.处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成弹幕消息处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
78.获取在单位时间内一个或多个第一客户端发送的一个或多个弹幕消息，根据单位时间的序号与存储列表的对应关系，将所述一个或多个弹幕消息存储到对应的存储列表内；
79.获取第二客户端发送的拉取弹幕请求，根据所述拉取弹幕请求对应的查询时间从相应的存储列表中查询目标弹幕消息，并将查询到的目标弹幕消息返回客户端。
80.上述如本技术图1所示实施例揭示的弹幕消息处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field－programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的
存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
81.该弹幕系统还可执行图1中弹幕消息处理装置执行的方法，并实现弹幕消息处理装置在图1所示实施例的功能，本技术实施例在此不再赘述。
82.本技术实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的弹幕系统执行时，能够使该弹幕系统执行图1所示实施例中弹幕消息处理装置执行的方法，并具体用于执行：
83.获取在单位时间内一个或多个第一客户端发送的一个或多个弹幕消息，根据单位时间的序号与存储列表的对应关系，将所述一个或多个弹幕消息存储到对应的存储列表内；
84.获取第二客户端发送的拉取弹幕请求，根据所述拉取弹幕请求对应的查询时间从相应的存储列表中查询目标弹幕消息，并将查询到的目标弹幕消息返回客户端。
85.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
86.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
87.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
88.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
89.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
90.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
91.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。
计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
92.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
93.本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
94.以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。