CN102375862B

CN102375862B - 大数据量消息管理方法和装置

Info

Publication number: CN102375862B
Application number: CN2010102654223A
Authority: CN
Inventors: 张丽
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Cloud Computing Beijing Co Ltd
Priority date: 2010-08-26
Filing date: 2010-08-26
Publication date: 2013-03-27
Anticipated expiration: 2030-08-26
Also published as: WO2012025058A1; EP2610759A4; US8566388B2; EP2610759A1; US20130066879A1; CN102375862A

Abstract

本发明提供了大数据量消息管理方法和装置，其中，该方法包括：A，客户端从服务器拉取消息索引列表；B，所述客户端分批拉取所述消息索引列表中消息索引对应的消息体；C，所述客户端采用消息池的方式管理拉取的消息体和对应的消息索引；D，所述客户端在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘。采用本发明，能够管理大数据量消息。

Description

大数据量消息管理方法和装置

技术领域

本发明涉及互联网技术，特别涉及大数据量消息管理方法和装置。

背景技术

目前，不管是在平时的休闲娱乐中，还是在用户的工作生活中，网络即时通信(IM)工具已成为用户必不可少的软件工具。在IM软件中，主要实现的是一对一的单独聊天模式，以及一对多的群或者讨论组的消息聊天模式。

随着互联网技术的发展，微博的应用也不断发展壮大。在微博应用中，用户可以通过微博文表达自己，也可以通过阅读他人的微博文来了解他人，这种方式能够实现一个人对无穷个人进行消息传播，同时，也能实现一个人接收无穷个人传播的消息。也就是说，微博的收听用户量非常大，与现有IM支持的收听用户量完全不是在一个等级上，通过微博文，能够实现聊天模式从IM软件支持的一对一、一对多到一对无穷的跨越。

由于微博的收听用户量非常大，因此，消息量也会随之非常大，然而，现有技术却没有一种管理大数据量消息的方法。

发明内容

本发明提供了大数据量消息管理方法和装置，以便实现管理大数据量消息。

本发明提供的技术方案是这样的：

一种大数据量消息管理方法，包括以下步骤：

A，客户端从服务器拉取消息索引列表；

B，所述客户端分批拉取所述消息索引列表中消息索引对应的消息体；

C，所述客户端采用消息池的方式管理拉取的消息体和对应的消息索引；

D，所述客户端在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘。

一种大数据量消息管理装置，包括：

拉列表拉取模块，用于从服务器拉取消息索引列表；

消息体拉取模块，用于分批拉取所述消息索引列表中消息索引对应的消息体；

管理模块，用于采用消息池的方式管理拉取的消息体和对应的消息索引；

存储模块，用于在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘。

由以上技术方案可以看出，本发明中，通过从服务器端拉取消息索引列表，并依据所述消息索引列表中的消息索引从服务器上拉取消息体，能够实现大数据量消息的拉取，通过将消息索引和消息体统一存放在消息池中，能够实现集中管理大数据量消息和解决大数据量消息的内存占用问题，通过将消息池中存放的消息索引和消息体存储在本地磁盘，能够实现大数据量消息的本地存储，进而实现大数据量消息的管理。

附图说明

图1为本发明实施例提供的流程图；

图2为本发明实施例提供的装置基本结构图；

图3为本发明实施例提供的装置详细结构图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

由于现有的IM工具中，涉及的用户量比较少，因此，消息量也相对比较少，而在类似微博的产品中，涉及的用户量非常多，消息量也呈现出几何量级的增长，完全不能用现有的IM管理方法管理，因此，本发明实施例提供了大数据量消息管理方法，具体参见图1所示的流程。

参见图1，图1为本发明实施例提供的基本流程图。如图1所示，该流程可包括以下步骤：

步骤101，客户端从服务器拉取消息索引列表。

本步骤101中，客户端拉取消息索引列表是根据用户的触发执行的。以微博为例，对该拉取操作进行具体描述：若用户当前位置为微博的首页，在客户端接收到用户在首页的触发后，发送该触发至服务器，服务器接收到触发后，根据消息的时间标示顺序对需要在首页显示的消息(比如该用户当前所关注的用户发送的消息、通过该用户的即时通信关系链得到的消息等)所对应的消息索引进行排列，之后发送至客户端。

需要说明的是，在执行步骤101的拉取操作之前，需要判断上一次的拉取是否完成，如果是，继续执行步骤101的拉取操作，否则，结束当前流程。

步骤102，客户端分批拉取所述消息索引列表中消息索引对应的消息体。

需要说明的是，步骤102可在客户端拉取到消息索引列表后即时执行，也可延时执行，本发明实施例并不具体限定。

步骤103，客户端采用消息池的方式管理拉取的消息体和对应的消息索引。

步骤104，客户端在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘。

至此，完成了图1所示的基本流程。

本实施例中，对大数据量消息的管理主要包括三个方面，分别为大数据量消息的拉取、大数据量消息的内存占用、和大数据量消息的本地存储。基于上述图1所示的流程，下面对这三个方面分别进行描述。

(1)大数据量消息的拉取：

针对该大数据量消息的拉取问题，本发明实施例通过步骤101和步骤102来解决。至于步骤102分批拉取所述消息索引列表中消息索引对应的消息体，其具体可包括：B1，从所述消息索引列表中选取N个消息索引；B2，客户端从服务器上拉取各个被选取的消息索引对应的消息体；B3，在所述步骤B2完成拉取操作之后，客户端判断所述消息索引表是否为空，如果是，在设定时间(具体可为用户触发客户端拉取消息索引列表的时间)到达时，返回执行步骤101，否则，执行步骤B4；B4，如果消息索引列表中未被选取的消息索引的个数大于等于N，则从该未被选取的消息索引中选取N个消息索引，之后执行步骤B2；如果消息索引列表中未被选取的消息索引的个数小于N，则选取该未被选取的消息索引，之后执行步骤B2；其中，N为正整数，且大于等于1。

至于客户端如何从服务器上拉取各个被选取的消息索引对应的消息体，其具体可包括：客户端将选取的消息索引发送至服务器；服务器检索到各个消息索引对应的各个消息体，将检索到的各个消息体携带在消息包中发送给客户端。

可以看出，服务器是以消息包的形式发送消息体至客户端的。优选地，为有效利用消息包发送消息体，本实施例可根据消息包的最大极限来最有效的利用消息包发送消息体，比如，如果一个消息包最大容量为800个字节，则需要尽量保证服务器每次发送的消息包的消息量占用800个字节，这可提高消息包的发送效率。基于此，可以得到上述N的取值由服务器返回的一个消息包所包含的最大消息量决定。通常，一个消息包最多可包含4个消息索引对应的消息体，基于此，上述N可为4。

(2)大数据量消息的内存占用：

针对大数据量消息的内存占用问题，本发明实施例通过步骤103解决。其中，步骤103具体实现时可包括：针对拉取的每一消息体，判断所述消息池是否已存放了该消息体，如果否，将该消息体和对应的消息索引存放在所述消息池中，如果是，丢弃该消息体。通过该判断，能够实现不同的页面需要呈现同一个消息体时，只会有一个消息体占用消息池中的内存，这节省了消息池的资源。

另外，本发明实施例对于消息索引与消息采用消息池集中进行管理，并非在每个页面控件或者逻辑管理类中管理各自的消息列表，这实现了消息的集中管理化。

(3)大数据量消息的本地存储：

对于IM消息，由于IM消息不是很大，可以完全存储在本地；而对于类似微博的产品，由于消息量巨大，如果像处理IM消息那样完全存储在本地，会造成本地数据文件的不断膨胀，同时引起读取文件的性能问题。为了解决大数据量消息的本地存储问题，需要在上述解决大数据量消息的内存占用问题时执行以下操作：

在将消息体存放在消息池中时，计算当前待存放至消息池的消息体数量和消息池已存放的消息体数量之和；判断计算的结果是否大于M(其中，消息池最多能够容纳M条消息体)，如果否，直接该待存放消息体存放至消息池；如果是，对所述消息池进行清理，以实现消息池容纳下当前待存放的消息体，之后，将当前待存放的消息体存放在消息池中。比如，如果消息池最多容纳500条消息体，如果当前待存放至消息池的消息体数量为40，而消息池已存放的消息体数量为480，两者之和远大于500，基于此，就需要对消息池进行清理，以实现消息池容纳下当前待存放的消息体，比如从消息池中清理掉20条消息体或者大于20条消息体，之后，将待存放消息体存放在消息池中。

可以看出，通过上述操作，能够保证消息池在每一个时刻最多只能存放M条消息体。

之后，如果接收到用户触发的结束标志比如退出微博页面等，则可直接将消息池中存放的消息体存储在本地磁盘，即解决了大数据量消息的本地存储问题。

其中，上述对消息池进行清理的操作具体实现时可有多种实现实行，其中一种方式为：根据消息体的时间标示，和/或消息体是否展示的标志对消息池进行清理。以根据消息体的时间标示为例，则对消息池进行清理的操作为：按照时间标示的先后顺序排列消息体，按照消息池容纳下当前待存放消息体的原则将排列在前的消息体清理掉。

通常，一条消息中可包含用户信息(具体用户账号、昵称、关系链等信息)和正文信息(也称为裸信息)，基于此，本发明实施例还可对裸消息进行解析，得到需要拉取的其他消息比如裸消息中提及的其他用户发布的消息，之后按照上述拉取操作将该需要拉取的消息进行完整消息中涉及资料部分的拉取与消息组装，并且通过扩展以及回调的方式展现。

以上对本发明实施例提供的方法进行了描述，下面对本发明实施例提供的装置进行描述。

参见图2，图2为本发明实施例提供的装置图。如图2所示，该装置可包括列表拉取模块201、消息体拉取模块202、管理模块203和存储模块204。

其中，列表拉取模块201，用于从服务器拉取消息索引列表；

消息体拉取模块202，用于分批拉取所述消息索引列表中消息索引对应的消息体；

管理模块203，用于采用消息池的方式管理拉取的消息体和对应的消息索引；

存储模块204，用于在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘。

以上对本发明实施例提供的装置进行了简单描述。

参见图3，图3为本发明实施例提供的装置的详细结构图。如图3所示，该装置可包括：列表拉取模块301、消息体拉取模块302、管理模块303和存储模块304。其中，该列表拉取模块301、消息体拉取模块302、管理模块303和存储模块304具有的功能分别与上述列表拉取模块201、消息体拉取模块202、管理模块203和存储模块204具有的功能类似，这里不再详述。

优选地，本实施例中，消息体拉取模块302具体可包括：

选取单元3021，用于从所述消息索引列表中选取N个消息索引；

处理单元3022，用于从服务器上拉取各个被选取的消息索引对应的消息体；

第一判断单元3023，用于在处理单元3022完成拉取后，判断所述消息索引表是否为空，如果是，在设定时间到达时，触发列表拉取模块301执行拉取操作；否则，如果消息索引列表中未被选取的消息索引的个数大于等于N，则从该未被选取的消息索引中选取N个消息索引，之后触发处理单元3022执行拉取操作；如果消息索引列表中未被选取的消息索引的个数小于N，则选取该未被选取的消息索引，之后触发处理单元3022执行拉取操作；其中，N为正整数，且大于等于1。

其中，处理单元3022从服务器上拉取各个被选取的消息索引对应的消息体具体包括：将被选取的消息索引发送至服务器；接收服务器以消息包形式发送的消息，基于此，所述N由服务器返回的一个消息包所包含的最大消息量决定。

优选地，本实施例中管理模块303可包括：

第二判断单元3031，用于针对所述消息体拉取模块拉取的每一消息体，判断所述消息池是否已存放了该消息体；

存放单元3032，用于在第二判断单元3031的判断结果为否时，将该消息体以及对应的消息索引存放在所述消息池中。

本实施例中，消息池最多能够容纳M条消息体；为了保证消息池的容量在任何时间都不超过M条消息体，存放单元3032执行的存放操作具体包括：计算当前待存放至消息池的消息体数量和消息池已存放的消息体数量之和；判断计算的结果是否大于M，如果是，对所述消息池进行清理，以实现消息池容纳下当前待存放的消息体，之后将待存放消息体存放在消息池中。

以上对本发明实施例提供的装置进行了详细描述。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种大数据量消息管理方法，其特征在于，该方法包括以下步骤：

A，客户端从服务器拉取消息索引列表；

D，所述客户端在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘；

其中，所述步骤B具体通过以下步骤分批拉取所述消息索引列表中消息索引对应的消息体：

B1，从所述消息索引列表中选取N个消息索引；

B2，客户端从服务器上拉取各个被选取的消息索引对应的消息体；

B3，客户端在所述步骤B2完成拉取操作之后，判断所述消息索引表是否为空，如果是，在设定时间到达时，返回执行步骤A；否则，执行步骤B4；

B4，如果消息索引列表中未被选取的消息索引的个数大于等于N，则从该未被选取的消息索引中选取N个消息索引，之后执行步骤B2；如果消息索引列表中未被选取的消息索引的个数小于N，则选取该未被选取的消息索引，之后执行步骤B2；

其中，N为正整数，且大于等于1。

2.根据权利要求1所述的方法，其特征在于，所述步骤B2中的拉取包括：

客户端将选取的消息索引发送至服务器；

服务器检索到各个消息索引对应的各个消息体，将检索到的各个消息体携带在消息包中发送给客户端；

所述N由服务器返回的一个消息包所包含的最大消息量决定。

3.根据权利要求1所述的方法，其特征在于，所述步骤C包括：

针对拉取的每一消息体，判断所述消息池是否已存放了该消息体，如果否，将该消息体和对应的消息索引存放在所述消息池中。

4.根据权利要求3所述的方法，其特征在于，所述消息池最多容纳M条消息体；

所述将消息体存放在消息池中包括：

计算当前待存放至消息池的消息体数量和消息池已存放的消息体数量之和；

判断计算的结果是否大于M，如果是，对所述消息池进行清理，以实现消息池容纳下当前待存放的消息体，之后将待存放消息体存放在消息池中。

5.根据权利要求4所述的方法，其特征在于，所述对消息池进行清理包括：

根据消息体的时间标示，和/或消息体是否展示的标志对消息池进行清理。

6.一种大数据量消息管理装置，其特征在于，所述装置包括：

列表拉取模块，用于从服务器拉取消息索引列表；

存储模块，用于在接收到用户触发的结束标志时，将消息池中存放的消息索引和消息体存储在本地磁盘；

其中，所述消息体拉取模块具体通过以下单元分批拉取所述消息索引列表中消息索引对应的消息体包括：

选取单元，用于从所述消息索引列表中选取N个消息索引；

处理单元，用于从服务器上拉取各个被选取的消息索引对应的消息体；

第一判断单元，用于在所述处理单元完成拉取操作后，判断所述消息索引表是否为空，如果是，在设定时间到达时，触发列表拉取模块执行拉取操作；否则，如果消息索引列表中未被选取的消息索引的个数大于等于N，则从该未被选取的消息索引中选取N个消息索引，之后触发处理单元执行拉取操作；如果消息索引列表中未被选取的消息索引的个数小于N，则选取该未被选取的消息索引，之后触发处理单元执行拉取操作；

其中，N为正整数，且大于等于1。

7.根据权利要求6所述的装置，其特征在于，所述管理模块包括：

第二判断单元，用于针对所述消息体拉取模块拉取的每一消息体，判断所述消息池是否已存放了该消息体；

存放单元，用于在所述第二判断单元的判断结果为否时，将该消息体以及对应的消息索引存放在所述消息池中。

8.根据权利要求7所述的装置，其特征在于，所述消息池最多能够容纳M条消息体；

所述存放单元计算当前待存放至消息池的消息体数量和消息池已存放的消息体数量之和；判断计算的结果是否大于M，如果是，对所述消息池进行清理，以实现消息池容纳下当前待存放的消息体，之后将待存放消息体存放在消息池中。