CN113778321A - 消息处理的方法和装置 - Google Patents

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的消息处理的方法的主要流程的示意图，且图3是主要示出根据本发明实施例的消息处理的方法中的一次查重的示意图。

在传统的消息处理的方法中，在某条消息处理完成并存入数据库后，客户端会给服务端发送回执，服务端收到回执后便不再重复给客户端发送该条消息。然而，现实场景中，在客户端已经接收消息，但消息处理过慢或者出现网络丢包导致发出的回执未被服务端接收时，会出现服务端不能及时地收到消息回执的情况。在此情况下，服务端由于无法分辨未收到回执的具体原因，所以一般会统一判定为客户端未收到该消息，然后再次向客户端发生该消息。而消息的重复处理是一种资源浪费。同时，由于待处理的消息队列是串行队列，消息会按照时间接收顺序在队列中排队，如果服务端因长时间收不到客户端回执而重复发送该消息，极端情况下会导致消息队列中出现大量的重复消息，消息队列压力会越来越大，内存暴增而导致系统崩溃。

为解决上述问题，如图1和图3所示，根据本发明实施例的消息处理的方法包括：接收从服务端发送的消息；对所述消息进行一次查重，确认该消息是否处于等待处理或正在处理的状态；在所述消息未处于等待处理或正在处理的状态时，基于所述消息到达的顺序并入消息队列，并对消息队列中的消息按顺序进行处理；以及将完成处理的消息显示在显示页面上。上述处理是指提取所述消息的字段，例如消息的发送方、消息的发送时间、消息的内容等。

在本发明的优选实施例中，对完成处理的消息进行存储，将该消息先后存储在内存缓存和数据库中，且将该消息从消息队列中移除，随后再将该消息显示于所述显示页面。完成处理的消息首先存储在内存缓存中，并定时/定量地批处理存储至数据库中。存储于内存缓存中的完成处理的消息根据内存缓存的容量进行更新和替换。在消息存储到数据库后，向服务端发送回执，告知服务端已经收到消息。服务端收到回执后便不再重复发送此消息。

图4是主要示出根据本发明实施例的消息处理的方法中包括一次查重、二次查重、三次查重的流程的示意图。如图4所示，消息队列中的消息在进行处理之前，进行二次查重，确认该消息是否已经存储在内存缓存中；在所述消息未存储在内存缓存中时，进行三次查重，确认该消息是否已经存储在数据库中(例如，通过sql(结构化查询语言)来查询)；并且在所述消息未存储在数据库中时，对该消息进行处理。

在对消息一次查重时，如果确认该消息在消息队列中处于等待处理或者正在处理的状态，那么这条消息就被判定为重复消息而直接被丢弃。可以给通过一次查重的消息增加一个标记，用于后续操作中的查重和/或读取时的检索。在对消息进行二次查重时，如果确认一条消息已经存储在内存缓存中，那么这条消息同样被判定为重复消息而直接被丢弃。相似地，在对消息进行三次查重时，如果确认一条消息已经存储在数据库中，那么这条消息同样被判定为重复消息而直接被丢弃。

也就是说，如果在一次查重时，消息已经被判定为重复消息，则可以直接丢弃该消息，该消息不再进入消息队列以进行后续处理。在消息通过了一次查重(即确认该消息未在消息队列中处于等待处理或者正在处理的状态)时，进行二次查重，如果在二次查重时，消息已经被判定为重复消息，则可以直接丢弃该消息，该消息不再进行三次查重和后续处理。这样，假如在内存缓存中就确认了消息的存在，则可以少一次数据库的查询，节省数据库I/O时间。只有在消息通过一次查重、二次查重和三次查重三者时，即该消息既未在消息队列中处于等待处理或者正在处理的状态又未处于处理完成状态存储在内存缓存和/或数据库中时，该消息进行处理，提取该消息的例如发送方、发送时间、内容等的字段。

消息处理完成后需要存入数据库，而数据库的写入操作属于对数据文件的输入/输出(I/O)操作，频繁地写入数据会导致文件经常开闭，非常损耗性能。一种常规的优化方法是开启数据库事务。所谓的数据库事务是一种批量入库的方式，通过开启数据库事务将数据先缓存在内存中，在提交数据库事务时把所有缓存至内存中的数据一次性更新到数据库文件中，此时数据库文件只需要开闭一次，也避免了长期占用文件I/O所导致性能低下的问题。但是对于即时通讯系统来说，在大部分情况下(即普通低并发消息的场景)，消息并不是批量到达，而是逐条发送。另外由于消息到达先后特性，最终的情况会因为网络等状况变得更加复杂。在该情况下，由于开启了数据库事务，所以需要先将处理完的消息缓存到内存中，定时或者定量地将积攒在内存的消息批处理入库，而这都需要额外的逻辑实现，会增加代码的复杂度，进而增加维护成本。

为解决上述问题，根据本发明的优选实施例，所述数据库为SQLite(一种轻型的数据库)，并将SQLite的写入模式设定为WAL(直写，Write-Ahead Log)模式。

与默认的回滚(rollback)模式相比，WAL模式具有以下优点：在大多数情况下，使用WAL模式写入速度更快；WAL模式进一步提升了数据库的并发性，因为读不会阻塞写，而写也不会阻塞读，读和写可以并发执行；使用WAL模式，磁盘I/O操作更有秩序；使用WAL模式减少了fsync()(函数同步内存中所有已修改的文件数据到储存设备)操作次数，因此不易受到系统上的fsync()系统调用(system call)中断的影响。

具体地，可以使用以下代码开启WAL模式：

PRAGMA journal_mode＝WAL。

在WAL模式下读的时候，SQLite会先在-wal文件(直写文件)中搜索，找到最后一个写入点，记住该写入点，并忽略在此之后的写入点(这保证了并发读写和并发读读的执行)。随后，它确定所要读的数据的所在页是否存在于-wal文件中，如果存在，则读-wal文件中的数据，如果不存在，则直接读数据库文件中的数据。为了避免每个读取操作扫描整个-wal文件来寻找页面，SQLite提供了WAL-index(直写索引)文件来辅助页面的查找。WAL-index文件使用了进程间共享内存的技术，共享内存是一个以.shm结尾并且和数据库文件在同一个目录下的文件。这个文件比较特别，内存和文件存在映射关系，取到这个文件的地址后可以像内存一样对其读写，而一般文件需要调用read(读)、write(写)函数才能读写。WAL-index可以帮助读取操作快速定位-wal文件中的页面，极大地提高了读取的性能。在读不会影响写入的情景下，能够进一步大幅提升数据库的写入性能。

图5为示出根据本发明的实施例的数据库增删改查的逻辑的示意图。

将完成处理的消息存储于数据库后，在将该完成处理的消息显示显示页面时，需要在数据库中查找该消息并进行提取，即对数据库中的数据进行读取。如果每次都通过消息标号(ID)在数据库中查询，由于需要遍历数据库中所有的消息进行匹配。所以在数据库中消息数量越来越多的情况下，查询的速度会越来越慢。一种常规的优化方法是增加索引，常见的关系型数据库均提供索引，适当地添加索引可以提高数据库的读取性能。然而，虽然可以通过添加索引的方式提升数据库的读取性能，但在数据库自带的缓存未命中时还是需要进行磁盘I/O，而磁盘I/O非常耗时。

为解决上述问题，根据本发明的优选实施例，在将完成处理的消息显示于显示页面之前，提取目标消息(待显示的消息)。此时，在内存缓存(图5中的内存Cache层)中查询目标消息，在查询到目标消息时，返回目标消息，用于显示页面上的显示，此时可以减少一次数据库读取操作。内存缓存可以使用简单的key-value(分布式存储系统)结构，key(关键字)为主键(PrimaryKey，或者其他唯一键，这个键应当经常被当作查询条件)。在内存缓存中没有命中目标消息时，进一步在数据库(图5中的DB层)中进行查询，将查询到的目标消息先更新到内存缓存中再返回该目标消息，用于显示页面上的显示。

根据本发明的优选实施例，也可以直接使用Where条件对数据库进行查询并返回待显示于显示页面的消息的相关数据。相似地，在写入和更新数据时，如上文所述，可以首先将数据写入/更新至内存缓存层，并随后将数据写入/更新至数据库。

图6是示出根据本发明的实施例的消息处理的方法中显示页面延迟刷新逻辑的示意图。

消息处理完后，下一步需要将消息展示在UI上。如果每条消息处理完就立即刷新页面，在普通低并发场景下没有太大问题，但是在高并发场景下就会造成短时间内UI刷新次数过多，从而导致页面卡顿的问题。

为解决上述问题，如图6所示，根据本发明的优选实施例，将所述完成处理的消息发送至所述显示页面的显示队列，并根据所述完成处理的消息到达所述显示队列的时间点距离上一次刷新的时间差和预定的刷新阈值进行显示页面刷新操作。

具体地，根据所述时间差和预定的刷新阈值进行显示页面刷新操作包括：在所述时间差大于或等于所述刷新阈值时，直接进行所述显示页面刷新操作；并且在所述时间差小于所述刷新阈值且所述时间差与预定的延迟时长之和大于所述刷新阈值时，在从所述上一次刷新经过所述刷新阈值的时间点进行所述显示页面刷新操作。

例如，可以设定刷新阈值为2000ms，预定的延迟时长为100ms。当消息A到达时，距离上一次刷新的时间差等于2000ms，则直接进行显示页面刷新操作。当消息A到达时，距离上一次刷新的时间差等于2500ms，也直接进行显示页面刷新操作。

如果距离上一次刷新的时间差小于刷新阈值(例如1950ms)且距离上一次刷新的时间差与预定的延迟时长之和大于所述刷新阈值(即1950ms+100ms＞2000ms)，则在从距离上一次刷新经过刷新阈值的时间点(距离上一次刷新2000ms)进行显示页面刷新操作。

具体地，根据所述时间差和预定的刷新阈值进行显示页面刷新操作包括：在所述时间差小于所述刷新阈值且所述时间差与预定的延迟时长之和小于所述刷新阈值时，生成延迟刷新指令并在从所述完成处理的消息到达所述显示队列的时间点起经过预定的延迟时长的时间点进行所述显示页面刷新操作，其中，在进行所述显示页面刷新操作时，取消已经生成的其他延迟刷新指令。

例如，如果消息A到达时距离上一次刷新的时间差小于2000ms(例如1600ms)且距离上一次刷新的时间差与预定的延迟时长之和小于所述刷新阈值(即1600ms+100ms＜2000ms)，则生成延迟刷新指令并在从该消息A到达所述显示队列的时间起经过预定的延迟时长的时间点(即1600ms+100ms＝距离上一次刷新1700ms)进行显示页面刷新操作。如果同时存在消息B，其到达显示队列的时间距离上一次刷新的时间差为1650ms，则会对应生成在1750ms进行的延迟刷新指令。而在进行消息A生成的1700ms的延迟刷新指令并进行显示页面刷新操作，此时消息B生成的1750ms的延迟刷新指令将被取消，即不在1750ms时进行显示页面刷新操作。

根据本发明的优选实施例，当使用者滑动显示页面(例如会话列表/会话页消息列表)时，不进行显示页面刷新操作，等到显示页面的滑动停止时再刷新，这样可以保证显示页面的滑动流畅度。

图7是示出根据本发明的实施例的消息处理的方法的整体流程的一个具体实例的示意图。如图7所示，接收从服务端发送的消息。接着，对该消息进行一次查重，确认该消息是否处于等待处理或正在处理的状态。在确认该消息在消息队列中处于等待处理或者正在处理的状态时，这条消息就被判定为重复消息而直接被丢弃；在所述消息未处于等待处理或正在处理的状态时，基于所述消息到达的顺序将所述消息并入消息队列。接着，进行二次查重，确认该消息是否已经存储在内存缓存中。在确认该消息已经存储在内存缓存中时，将这条消息同样判定为重复消息而直接被丢弃；在所述消息未存储在内存缓存中时，进行三次查重，确认该消息是否已经存储在数据库中(例如，通过sql来查询)。在确认一条消息已经存储在数据库中时，将这条消息同样判定为重复消息而直接被丢弃；并且在所述消息未存储在数据库中时，对该消息进行处理。将完成处理的消息首先缓存于内存缓存，在将内存缓存中存储的完成处理的消息定时/定量地批处理存入数据库。此时，消息队列通知UI队列有新消息，并根据所述完成处理的消息到达所述显示队列的时间点距离上一次刷新的时间差和预定的刷新阈值进行显示页面刷新操作。

图2是根据本发明实施例的消息处理的装置的主要模块的示意图。如图2所示，消息处理的装置200包括：

接收模块201，用于接收从服务端发送的消息；

一次查重模块202，用于对所述消息进行一次查重，确认该消息是否处于等待处理或正在处理的状态；

队列模块203，在所述消息未处于等待处理或正在处理的状态上，该队列模块基于所述消息到达接收模块201的顺序将所述消息并入消息队列，并对消息队列中的消息按所述顺序进行处理；以及

显示模块204，用于将完成处理的消息显示于显示页面。

队列模块203对通过一次查重确认未处于等待处理或正在处理的状态的消息增加一个标记，用于后续操作中的检索。

消息处理的装置200在将完成处理的消息显示于显示页面之前，可以利用储存模块(未示出)对完成处理的消息进行存储，将完成处理的消息先后存储于内存缓存和数据库中。数据库为SQLite，且将SQLite的写入模式设定为WAL模式。

另外，队列模块203在进行处理之前，进行二次查重，确认该消息是否已经存储在内存缓存中；在消息未存储在内存缓存中时，进行三次查重，确认消息是否已经存储在数据库中；并且在消息未存储在数据库中时，队列模块203对该消息进行处理。

在显示模块204将完成处理的消息显示于显示页面之前，提取模块(未示出)提取目标消息，在所述内存缓存中查询目标消息，在查询到该目标消息时，将该目标消息显示在显示页面上。在内存缓存中没有找到所述目标消息时，提取模块进一步在数据库中进行查询，并将查询到的目标消息显示在显示页面上。

显示模块204接收将提取模块提取的目标消息并入显示队列，并根据目标消息(已完成处理的消息)到达显示队列的时间点距离上一次刷新的时间差和预定的刷新阈值进行显示页面刷新操作。在时间差大于或等于刷新阈值时，显示模块204直接进行显示页面刷新操作。并且在时间差小于刷新阈值且时间差与预定的延迟时长之和大于刷新阈值时，显示模块204在从上一次刷新经过刷新阈值的时间点进行显示页面刷新操作。在时间差小于刷新阈值且时间差与预定的延迟时长之和小于刷新阈值时，显示模块204生成延迟刷新指令并在从目标消息(已完成处理的消息)到达显示队列的时间点起经过预定的延迟时长的时间点进行显示页面刷新操作。显示模块204在进行显示页面刷新操作时，取消已经生成的其他延迟刷新指令。当使用者滑动所述显示页面时，显示模块204不进行显示页面刷新操作。

图8示出了可以应用本发明实施例的消息处理的方法或消息处理的装置的示例性系统架构800。

如图8所示，系统架构800可以包括终端设备(例如，接收消息的客户端)801、802、803，网络804和服务器(例如，发送消息的服务端)805。网络804用以在终端设备801、802、803和服务器805之间提供通信链路的介质。网络804可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备801、802、803通过网络804与服务器805交互，以接收或发送消息等。终端设备801、802、803上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备801、802、803可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器805可以是提供各种服务的服务器，例如对用户利用终端设备801、802、803所浏览的购物类网站提供支持的后台管理服务器。后台管理服务器可以将接收的消息发送给终端设备。

需要说明的是，本发明实施例所提供的消息处理的方法一般由终端设备(例如，接收消息的客户端)801、802、803执行，相应地，消息处理的装置一般设置于终端设备801、802、803中。

应该理解，图8中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图9，其示出了适于用来实现本发明实施例的终端设备的计算机系统900的结构示意图。图9示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括接收模块、一次查重模块、队列模块和显示模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，接收模块还可以被描述为“从服务端接收消息的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：接收从服务端发送的消息；对消息进行一次查重，确认该消息是否处于等待处理或正在处理的状态；在消息未处于等待处理或正在处理的状态时，基于消息到达的顺序将消息并入消息队列，并对消息队列中的消息按顺序进行处理；以及将完成处理的消息显示于显示页面。

本发明通过消息查重、写入性能优化、查询性能优化、消息UI刷新条件优化四个方面，提供了有效的高并发消息处理的方法。通过本发明构建的消息处理的方法，除了在普通低并发场景下的正常运作，还能够解决绝大多数场景下的高并发性能消息处理会遇到的技术问题，构建一个稳定、高效的可用于即时通讯的消息处理的方法及消息处理的装置。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。