CN111654428B - 离线消息处理方法、装置和服务器 - Google Patents

离线消息处理方法、装置和服务器 Download PDF

Info

Publication number
CN111654428B
CN111654428B CN202010509692.8A CN202010509692A CN111654428B CN 111654428 B CN111654428 B CN 111654428B CN 202010509692 A CN202010509692 A CN 202010509692A CN 111654428 B CN111654428 B CN 111654428B
Authority
CN
China
Prior art keywords
target client
file
offline
current
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010509692.8A
Other languages
English (en)
Other versions
CN111654428A (zh
Inventor
张坤宇
陈岩光
张晓磊
畅婷婷
张斌
刘森
张彬
王智慧
李明亮
席杰
袁玮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tianjin Troila Technology Development Co ltd
Original Assignee
Tianjin Troila Technology Development Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tianjin Troila Technology Development Co ltd filed Critical Tianjin Troila Technology Development Co ltd
Priority to CN202010509692.8A priority Critical patent/CN111654428B/zh
Publication of CN111654428A publication Critical patent/CN111654428A/zh
Application granted granted Critical
Publication of CN111654428B publication Critical patent/CN111654428B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/043—Real-time or near real-time messaging, e.g. instant messaging [IM] using or handling presence information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明提供了一种离线消息处理方法、装置和服务器，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将该消息确定为给目标客户端的离线消息；按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；按预设条件对文件进行压缩，得到目标客户端对应的压缩文件；如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端。该方法通过限定目标客户端的每个文件中存储的离线消息的数据量，以及对文件进行压缩的方式，减少了存储离线消息所占用的存储空间，并且将压缩文件发送给目标客户端时的数据量也较小，提高了离线消息传送的稳定性。

Description

离线消息处理方法、装置和服务器
技术领域
本发明涉及通讯技术领域，尤其是涉及一种离线消息处理方法、装置和服务器。
背景技术
IM(Instant Messaging，即时消息)是一种在移动网络、互联网上开展的，基于呈现业务的个人对个人、个人对群组的消息类的移动数据业务；相关技术中，当需要对大量IM离线消息进行存储时，通常需要占用较多的存储空间，并且，当用户在客户端上线并拉取离线消息时，每次拉取的离线消息数据量通常也较大，由于移动网络本身的不稳定性，使用该方式难以保证离线消息稳定传送至该客户端。
发明内容
本发明的目的在于提供一种离线消息处理方法、装置和服务器，以减少存储离线消息所占用的存储空间，同时提高离线消息传送的稳定性。
本发明提供的一种离线消息处理方法，所述方法包括：如果接收到发送至目标客户端的消息，且所述目标客户端为离线状态，将所述消息确定为给所述目标客户端的离线消息；按预设数据量大小，将所述离线消息保存至所述目标客户端对应的至少一个文件中；按预设条件对所述文件进行压缩，得到所述目标客户端对应的压缩文件；如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端。
进一步的，每个所述文件的文件名称为该文件中指定离线消息的时间戳；所述预设条件包括预设压缩时间、每个所述压缩文件中包含的预设文件数量，以及每个所述文件的文件名称排序方式；所述按预设条件对所述文件进行压缩，得到所述目标客户端的压缩文件的步骤包括：按所述预设压缩时间、所述预设文件数量，以及每个所述文件的文件名称排序方式，对所述文件进行压缩，得到所述目标客户端对应的至少一个压缩文件；其中，每个所述压缩文件的文件名称为该压缩文件中指定文件的文件名称。
进一步的，所述如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端的步骤包括：如果接收到来自所述目标客户端的离线消息获取请求，按照每个所述压缩文件的文件名称中的时间戳的顺序，获取当前压缩文件；将所述当前压缩文件，以及所述当前压缩文件的压缩算法标记，发送至所述目标客户端，以使所述目标客户端根据所述压缩算法标记解压所述当前压缩文件；如果所述当前压缩文件存在前一个压缩文件，删除所述前一个压缩文件。
进一步的，所述按预设数据量大小，将所述离线消息保存至所述目标客户端对应的至少一个文件中的步骤包括：将所述离线消息发送至所述目标客户端对应的消息队列；按预设数据量大小，将所述消息队列中的离线消息发送并保存至所述目标客户端对应的至少一个文件中。
进一步的，所述如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端的步骤包括：如果接收到来自所述目标客户端的离线消息获取请求，统计所述消息队列中的当前离线消息数量；如果所述当前离线消息数量为零，将所述压缩文件发送至所述目标客户端；如果所述当前离线消息数量不为零，继续执行统计所述消息队列中的当前离线消息数量的步骤，直至将所述压缩文件发送至所述目标客户端。
进一步的，所述目标客户端为多个；所述按预设条件对所述文件进行压缩，得到所述目标客户端对应的压缩文件的步骤包括：遍历保存有各个所述目标客户端对应的离线消息的文件；针对每个所述目标客户端，基于所遍历的当前目标客户端对应的离线消息的文件，获取所述当前目标客户端对应的拉取标记；如果所述拉取标记为第二拉取参数，将所述当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中；其中，所述第二拉取参数用于指示所述当前目标客户端正在拉取离线消息；如果所述拉取标记为第一拉取参数，按预设条件对所述当前目标客户端对应的离线消息的文件进行压缩，得到所述当前目标客户端对应的当前压缩文件；其中，所述第一拉取参数用于指示所述当前目标客户端未拉取离线消息；设置所述当前目标客户端对应的压缩标记为第二压缩参数；其中，所述第二压缩参数用于指示：所述当前目标客户端对应的离线消息的文件未进行压缩；在对所述当前目标客户端对应的离线消息的文件进行压缩的过程中，设置所述当前目标客户端对应的压缩标记为第一压缩参数；其中，所述第一压缩参数用于指示：所述当前目标客户端对应的离线消息的文件正在进行压缩；继续执行获取所述当前目标客户端对应的拉取标记的步骤，直至所述当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中，或者得到所述当前目标客户端对应的各个压缩文件；遍历所述未完成压缩任务中所包含的各个目标客户端对应的离线消息的文件，继续执行获取所述当前目标客户端对应的拉取标记的步骤，直至得到各个目标客户端对应的压缩文件。
进一步的，所述如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端的步骤包括：如果接收到来自所述目标客户端的离线消息获取请求，获取所述目标客户端对应的压缩标记；如果所述压缩标记为第二压缩参数，将所述目标客户端对应的压缩文件发送至所述目标客户端；设置所述目标客户端对应的拉取标记为第二拉取参数；如果所述压缩标记为第一压缩参数，将所述目标客户端对应的离线消息的文件正在进行压缩的事件返回至所述目标客户端，以使所述目标客户端延迟发出离线消息获取请求；重复执行如果接收到来自所述目标客户端的离线消息获取请求，获取所述目标客户端对应的压缩标记的步骤，直至将所述目标客户端对应的压缩文件发送至所述目标客户端。
本发明提供的一种离线消息处理装置，所述装置包括：接收模块，用于如果接收到发送至目标客户端的消息，且所述目标客户端为离线状态，将所述消息确定为给所述目标客户端的离线消息；保存模块，用于如果按预设数据量大小，将所述离线消息保存至所述目标客户端对应的至少一个文件中；获取模块，用于按预设条件对所述文件进行压缩，得到所述目标客户端对应的压缩文件；发送模块，用于如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端。
本发明提供的一种服务器，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现上述任一项所述的离线消息处理方法。
本发明提供的一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现上述任一项所述的离线消息处理方法。
本发明提供的离线消息处理方法、装置和服务器，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将该消息确定为给目标客户端的离线消息；按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；按预设条件对文件进行压缩，得到目标客户端对应的压缩文件；如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端。该方法通过限定目标客户端的每个文件中存储的离线消息的数据量，以及对文件进行压缩的方式，减少了存储离线消息所占用的存储空间，并且将压缩文件发送给目标客户端时的数据量也较小，提高了离线消息传送的稳定性。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种离线消息处理方法的流程图；
图2为本发明实施例提供的另一种离线消息处理方法的流程图；
图3为本发明实施例提供的另一种离线消息处理方法的流程图；
图4为本发明实施例提供的一种离线消息的存储流程示意图；
图5为本发明实施例提供的一种离线消息的存储方式示意图；
图6(a)和图6(b)为本发明实施例提供的一种离线消息存储和拉取离线消息的锁流程图；
图7(a)和图7(b)为本发明实施例提供的一种拉取离线消息和定时离线压缩服务的锁流程图；
图8为本发明实施例提供的一种离线消息处理装置的结构示意图；
图9为本发明实施例提供的一种服务器的结构示意图。
具体实施方式
下面将结合实施例对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
传统的离线消息存储方案通常包括以下四个步骤：(1)客户端A发送消息给客户端B；(2)服务器检查客户端B状态，确认客户端B是否在线；(3)服务器发现客户端B离线，将客户端A发送的消息确定为离线消息，保存该离线消息到数据库；(4)服务器发送“消息发送成功”消息给客户端A；当需要对大量IM离线消息进行存储时，该离线消息存储方案通常需要占用较多的存储空间，存储压力较大。
典型的离线消息拉取方案通常包括以下四个步骤：(1)客户端B请求服务器拉取客户端A发送的离线消息；(2)服务器从数据库中查询客户端A发给客户端B的离线消息；(3)服务器从数据库删除客户端A发给客户端B的离线消息；(4)服务器将客户端A发给客户端B的离线消息返回给客户端B。如果客户端B有许多好友，采用该离线消息拉取方案，会导致客户端B与服务端的交互次数就会比较多；为了解决这个问题，传统的离线消息拉取方案有两种改进方式，第一种改进方式是：先拉取各个好友的离线消息数量，等到点进对话框之后，再拉取实际的离线消息，这样会比较节省流量，但该改进方式中，客户端B与服务器交互的次数并没有减少，反而还增加了一次拉取消息数量的步骤，对移动端来说，与服务器交互次数越多就意味着越费电，再加上移动端IM网络本身的不稳定性，所以与服务器交互次数越多，越加重了这种不稳定性。第二种改进方式是：一次性拉取客户端的所有离线消息拉取请求，然后根据离线消息的发送人和发送时间，在客户端进行计算；该改进方式虽然减少了客户端与服务器之间的交互次数，但一次性交互大量数据时，容易造成客户端机器卡顿。
基于此，本发明实施例提供了一种离线消息处理方法、装置和服务器，该技术可以应用于微信、QQ等多种通讯软件对离线消息的处理中。首先基于上述离线消息拉取方案的第二种改进方式中，客户端一次性拉取大量离线消息，导致速度变慢，卡死的问题，可以采用以下四个步骤拉取离线消息：(1)客户端B请求服务器分页拉取客户端A发给客户端B的离线消息；(2)服务器按照分页信息，从数据库中拉取客户端A发给客户端B的离线消息；(3)服务器从数据库删除已经拉取的客户端B的离线消息；(4)服务器将客户端A发给客户端B的离线消息返回给客户端B。通过分页拉取的方式，先拉取最新或者最旧的一页消息，再按需一页页拉取，直到客户端B判断服务器已经没有离线消息时停止拉取，通过这种方式可以改善用户体验。
但在上述优化方式中，在执行上述第(4)步的过程中，如果服务器宕机，或者客户端B故障，由于此时离线消息已经删除，导致出现客户端B的离线消息丢失的问题；为此，对该方式做了进一步优化，可以通过以下步骤拉取离线消息：(1)客户端B请求服务器分页拉取客户端A发给客户端B的离线消息；(2)服务器按照分页信息，从数据库中拉取客户端A发给客户端B的离线消息；(3)服务器向客户端B返回“server ok”的消息；(4)服务器将客户端A发给客户端B的离线消息返回给客户端B；(5)客户端B向服务器返回“client B ok”的消息；(6)服务器从数据库删除已经拉取的客户端B的离线消息；该方式增加了ack(acknowledge character，确认字符)机制。如果客户端B未收到server ok的消息，则会重复发送拉取离线消息的请求，服务端如果没有收到“client B ok”的消息，则不会删除数据库中的客户端B的离线消息。ack通知可以通过实时消息异步发送。客户端B判断服务器已经没有离线消息时停止拉取。
经过上述优化过程，仍存在一个问题，如果客户端在收到消息后，在ack之前崩溃了，服务端并不会删除离线消息，下次拉取的时候还会再次拉取重复的离线消息，这时，客户端B可以通过msg_id(Message_identity document)对离线消息做去重处理，业务层面通过消息重发和消息去重解决了系统消息会丢失的问题，保证了离线消息不丢不重；但是，每次拉取离线消息，客户端B都会发送一个ack的确认消息，无形中增加了客户端B对服务器的请求量，因此，分页拉取可以通过：每次拉取记录数+时间戳的方式拉取离线消息，将下一次拉取作为上一次拉取的ack，在下一次拉取时，再根据时间戳删除拉取过的离线消息，这样可以减少一半的请求量。通过拉取消息请求代替ack请求的方式，有效的减少了客户端ack请求的数量。
下面对本发明实施例所公开的一种离线消息处理方法进行详细介绍；如图1所示，该方法包括如下步骤：
步骤S602，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将消息确定为给目标客户端的离线消息。
上述目标客户端可以理解为接收微信或QQ等即时消息的手机或电脑等终端；在实际实现时，该目标客户端可能是在线状态，也可能是离线状态，当服务器接收到其他客户端发给至该目标客户端的消息后，通常会先检查该目标客户端的状态，如果该目标客户端为在线状态，则服务器直接将该消息发送至目标客户端，如果该目标客户端为离线状态，则该消息即为其他客户端发送给该目标客户端的离线消息。
步骤S604，按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中。
上述预设数据量大小可以根据实际需求进行设定，比如可以设定50k或100k等；在实际实现时，为了便于后续离线消息的传输，同时保证离线消息传输的安全性，可以预先设置一个合适的数据量大小，数据库中存储离线消息的文件的大小控制在该范围内，如果目标客户端的离线消息的数据量超过该预设数据量大小，可以将离线消息存储在数据库中该目标客户端对应的多个文件中。
步骤S606，按预设条件对文件进行压缩，得到目标客户端对应的压缩文件。
上述预设条件也可以根据实际需求进行设定，比如，可以预先设定对存储离线消息的文件进行压缩的时间周期，如，每天对前一天的存储离线消息的文件进行压缩等；在实际实现时，为了减少离线消息对存储空间的占用量，可以按预设条件，对数据库中该目标客户端对应的多个文件进行压缩，得到该目标客户端对应的压缩文件。
步骤S608，如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端。
上述离线消息获取请求可以理解为，当目标客户端上线后，向服务器发出的用于获取其他客户端发送至该目标客户端的离线消息的请求；当服务器接收到来自目标客户端的离线消息获取请求后，将数据库中该目标客户端对应的压缩文件发送至该目标客户端。
本发明实施例提供的一种离线消息处理方法，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将该消息确定为给目标客户端的离线消息；按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；按预设条件对文件进行压缩，得到目标客户端对应的压缩文件；如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端。该方法通过限定目标客户端的每个文件中存储的离线消息的数据量，以及对文件进行压缩的方式，减少了存储离线消息所占用的存储空间，并且将压缩文件发送给目标客户端时的数据量也较小，提高了离线消息传送的稳定性。
本发明实施例还提供了另一种离线消息处理方法，该方法在上述实施例方法的基础上实现；该方法重点描述按预设条件对文件进行压缩，得到目标客户端的压缩文件，以及如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端的具体过程，具体对应下述步骤S706至步骤S712，该方法中，每个文件的文件名称为该文件中指定离线消息的时间戳；由于每个文件中可能保存有多条离线消息，该指定离线消息可以是根据实际需求，从该文件中的多条离线消息中选取的一条离线消息，比如，可以将该文件中的第一条离线消息作为指定离线消息，或者，也可以将该文件中的最后一条离线消息作为指定离线消息；该时间戳可以理解为能够表示各条离线消息在特定时间点已经存在的完整的可验证的数据，具体可以是一份电子证据，以证明各条离线消息的产生时间。预设条件包括预设压缩时间、每个压缩文件中包含的预设文件数量，以及每个文件的文件名称排序方式；该预设压缩时间可以理解为，预先设定的对存储离线消息的文件进行压缩的时间周期，如，每天对前一天的存储离线消息的文件进行压缩等，具体可以根据实际需求进行设定；该预设文件数量可以是根据实际需求所设定的每个压缩文件中所包含的文件数量；上述排序方式可以是基于每个文件的文件名称得到的文件排序，比如，如果每个文件的文件名称为该文件中指定离线消息的时间戳，可以按每个文件的文件名称中时间戳倒序的方式对每个文件进行排序，当然，也可以选择其他方式对存储离线消息的各个文件进行排序。如图2所示，该方法包括如下步骤：
步骤S702，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将消息确定为给目标客户端的离线消息。
步骤S704，按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中。
相关技术中，通常采用关系型数据库存储离线消息，并且，群聊消息大多采用离线消息读扩散的方式存储，导致当存储有大量离线消息时，该关系型数据库的检索性能会比较差，本实施例中，采用分布式文件系统HDFS(Hadoop Distributed File System)代替关系型数据库来存储离线消息，存储群消息时采用写扩散的方式储存，每个用户保留一份自己的离线消息，按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；比如，以预设数据量大小为50k为例，在数据库中存储离线消息时，将存储离线消息的每个文件控制在50k以内，超过50k就新建一个文件继续存储，每个文件的文件名称以该文件中第一条离线消息的时间戳进行命名。
步骤S706，按预设压缩时间、预设文件数量，以及每个文件的文件名称排序方式，对文件进行压缩，得到目标客户端对应的至少一个压缩文件；其中，每个压缩文件的文件名称为该压缩文件中指定文件的文件名称。
由于每个压缩文件中可能包含多个文件，该指定文件可以是根据实际需求，从该压缩文件中的多个文件中选取的一个文件；在实际实现时，可以采用定时对离线消息进行压缩存储的方式来减小对存储空间的占用和每次传输的消息体积，所采用的压缩算法可以结合实际需求进行选择，比如，可以采用LZO(Lempel-Ziv-Oberhumer，一种数据压缩算法)压缩算法，如果磁盘空间充足也可以采用Zippy/Snappy算法，压缩率低，但是压缩和解压速度会更快。假设预设压缩时间为每天、预设文件数量为5个，指定文件为压缩文件中时间戳最早的文件，每个文件的文件名称排序方式为倒序，即按照文件名称中时间戳从新到旧的顺序进行排序，则每天对前一天的保存离线消息的文件进行压缩，在每天进行压缩时，按照每个文件的文件名称中时间戳倒序的方式对各个文件进行排序，采用的压缩比例为20％，即按顺序选取文件，每5个文件压缩为一个文件，每个压缩文件的文件名称以该压缩文件中时间戳最早的文件的文件名称命名，最后不足5个文件直接压缩为一个压缩文件。
步骤S708，如果接收到来自目标客户端的离线消息获取请求，按照每个压缩文件的文件名称中的时间戳的顺序，获取当前压缩文件。
如果服务器接收到来自目标客户端的离线消息获取请求，即目标客户端需要拉取离线消息时，通常会按照该目标文件所对应的压缩文件的文件名称中的时间戳的顺序进行排序，并拉取压缩文件，比如，按照压缩文件的文件名称中的时间戳从新到旧的顺序进行排序，并按该顺序拉取压缩文件，每次拉取一个压缩文件，将所拉取的压缩文件确定为当前压缩文件。
步骤S710，将当前压缩文件，以及当前压缩文件的压缩算法标记，发送至目标客户端，以使目标客户端根据压缩算法标记解压当前压缩文件。
上述压缩算法标记可以理解为，在服务器对存储有离线消息的文件进行压缩时，所采用的压缩算法对应的标记，由于当目标客户端拉取的文件为压缩文件时，需要对该压缩文件进行解压，因此当服务器获取到当前压缩文件后，通常需要将该压缩文件，以及该压缩文件对应的压缩算法标记一并返回至该目标客户端，以使目标客户端可以根据该压缩算法标记解压相应的当前压缩文件。
步骤S712，如果当前压缩文件存在前一个压缩文件，删除前一个压缩文件。
在实际实现时，服务器所获取的当前压缩文件可能存在前一个压缩文件，也可能不存在前一个压缩文件；比如，如果当前压缩文件为该目标客户端的第一个压缩文件，则该当前压缩文件不存在前一个压缩文件；如果当前压缩文件为除第一个压缩文件以外的其他压缩文件，则该当前压缩文件存在前一个压缩文件；如果按照压缩文件的文件名称中的时间戳从新到旧的顺序进行排序，并按该顺序逐一获取当前压缩文件，即先获取时间戳较新的压缩文件，再获取时间戳较旧的压缩文件，在向目标客户端发送当前压缩文件时，删除前一个压缩文件，比如，如果当前压缩文件为第二个压缩文件，则在向目标客户端发送该第二个压缩文件时，删除第一个压缩文件。
本发明实施例提供的另一种离线消息处理方法，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将该消息确定为给目标客户端的离线消息；按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；按预设压缩时间、预设文件数量，以及每个文件的文件名称排序方式，对文件进行压缩，得到目标客户端对应的至少一个压缩文件；如果接收到来自目标客户端的离线消息获取请求，按照每个压缩文件的文件名称中的时间戳的顺序，获取当前压缩文件；将当前压缩文件，以及当前压缩文件的压缩算法标记，发送至目标客户端，以使目标客户端根据压缩算法标记解压当前压缩文件；如果当前压缩文件存在前一个压缩文件，删除前一个压缩文件。该方法通过限定目标客户端的每个文件中存储的离线消息的数据量，以及对文件进行压缩的方式，减少了存储离线消息所占用的存储空间，并且将压缩文件发送给目标客户端时的数据量也较小，提高了离线消息传送的稳定性。
本发明实施例还提供了另一种离线消息处理方法，该方法在上述实施例方法的基础上实现；该方法重点描述按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中，以及如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端的具体过程，如图3所示，该方法包括如下步骤：
步骤S802，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将消息确定为给目标客户端的离线消息。
步骤S804，将离线消息发送至目标客户端对应的消息队列。
上述消息队列可以理解为基础数据结构中的“先进先出”的一种数据机构。在实际实现时，当服务器接收到其他客户端发送给目标客户端的离线消息时，通常先将该离线消息发送至消息队列，以实现对该离线消息的缓存，通常每发送一条离线消息发送至目标客户端对应的消息队列，就会将该目标客户端对应的离线消息未处理条数加1，该消息队列可以以MQ(Message Queue，消息队列)表示。
步骤S806，按预设数据量大小，将消息队列中的离线消息发送并保存至目标客户端对应的至少一个文件中。
在实际实现时，为了便于后续离线消息的传输，同时保证离线消息传输的安全性，可以预先设置一个合适的数据量大小，数据库中存储离线消息的文件的大小控制在该范围内，如果目标客户端对应的消息队列中的离线消息的数据量超过该预设数据量大小，可以将消息队列中的离线消息存储在数据库中该目标客户端对应的多个文件中，通常每保存一条离线消息至目标客户端对应的文件，就会将该目标客户端对应的离线消息未处理条数减1。
步骤S808，按预设条件对文件进行压缩，得到目标客户端对应的压缩文件。
步骤S810，如果接收到来自目标客户端的离线消息获取请求，统计消息队列中的当前离线消息数量。
上述当前离线消息数量可以理解为目标客户端对应的消息队列中，离线消息未处理条数；在实际实现时，当服务器接收到来自目标客户端的离线消息获取请求后，通常需要先统计该消息队列中的离线消息未处理条数。
步骤S812，如果当前离线消息数量为零，将压缩文件发送至目标客户端。
如果统计的目标客户端对应的消息队列中的当前离线消息数量为零，即该消息队列中的离线消息未处理条数为零，表示当前没有需要存储的离线消息，没有执行对离线消息的存储过程，这时，可以根据接收到的来自目标客户端的离线消息获取请求，将该目标客户端对应的压缩文件发送至目标客户端。
步骤S814，如果当前离线消息数量不为零，继续执行统计消息队列中的当前离线消息数量的步骤，直至将压缩文件发送至目标客户端。
如果统计的目标客户端对应的消息队列中的当前离线消息数量不为零，即该消息队列中的离线消息未处理条数不为零，表示当前消息队列中还有需要存储的离线消息，这时，通常会重复执行统计消息队列中的当前离线消息数量的过程，直至消息队列中没有需要存储的离线消息，并将压缩文件发送至目标客户端。
如果目标客户端上线后，向服务器发送离线消息获取请求，需要拉取离线消息时，如果正在存储其他客户端发送给目标客户端的离线消息，也就是说，在对目标客户端的离线消息进行存储的同时，目标客户端上线了，考虑到有一些离线消息可能还没存储完，目标客户端在拉取时有可能导致拉取不到，也就是说，可能这些没有存储完的离线消息可能会丢失，为了避免出现这个问题，如果接收到来自目标客户端的离线消息获取请求时，服务器正在对离线消息进行存储，这时通常会等存储完离线消息之后，再拉取离线消息。
本发明实施例提供的另一种离线消息处理方法，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将该消息确定为给目标客户端的离线消息；将离线消息发送至目标客户端对应的消息队列。按预设数据量大小，将消息队列中的离线消息发送并保存至目标客户端对应的至少一个文件中。按预设条件对文件进行压缩，得到目标客户端对应的压缩文件。如果接收到来自目标客户端的离线消息获取请求，统计消息队列中的当前离线消息数量，根据当前离线消息数量是否为零，执行相应的处理。该方法通过限定目标客户端的每个文件中存储的离线消息的数据量，以及对文件进行压缩的方式，减少了存储离线消息所占用的存储空间，并且将压缩文件发送给目标客户端时的数据量也较小，提高了离线消息传送的稳定性。
本发明实施例还提供了另一种离线消息处理方法，该方法在上述实施例方法的基础上实现；该方法重点描述按预设条件对文件进行压缩，得到目标客户端对应的压缩文件，以及如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端的具体过程，该方法中，目标客户端为多个；该方法包括如下步骤：
步骤902，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将消息确定为给目标客户端的离线消息。
步骤904，按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中。
步骤906，遍历保存有各个目标客户端对应的离线消息的文件。
在实际实现时，在对存储离线消息的文件进行压缩之前，通常需要遍历所有目标客户端对应的离线消息的文件。
步骤908，针对每个目标客户端，基于所遍历的当前目标客户端对应的离线消息的文件，获取当前目标客户端对应的拉取标记。
从多个目标客户端中选取当前目标客户端，基于所遍历的当前目标客户端对应的离线消息的文件，获取该当前目标客户端对应的拉取标记，以确认当前目标客户端是否正在拉取离线消息；在实际实现时，该拉取标记可以以0或1表示，也可以选择其他表示方式；比如，如果拉取标记为1，表示当前目标客户端正在拉取离线消息，如果拉取标记为0，表示当前目标客户端没有拉取离线消息。
步骤910，如果拉取标记为第二拉取参数，将当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中；其中，第二拉取参数用于指示当前目标客户端正在拉取离线消息。
为便于说明，仍以拉取标记为0或1表示，且拉取标记为1时，表示当前目标客户端正在拉取离线消息，拉取标记为0时，表示当前目标客户端没有拉取离线消息为例，如果获取的当前目标客户端对应的拉取标记为1，则可以确认当前目标客户端正在拉取离线消息，这时，通常会先将该当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中，临时跳过该当前目标客户端。也可以理解为，当需要对保存有目标客户端的离线消息的文件进行压缩时，如果目标客户端上线，则停止压缩过程，可以先跳过该目标客户端，去执行对其他目标客户端的压缩过程。
步骤912，如果拉取标记为第一拉取参数，按预设条件对当前目标客户端对应的离线消息的文件进行压缩，得到当前目标客户端对应的当前压缩文件；其中，第一拉取参数用于指示当前目标客户端未拉取离线消息。
为便于说明，以拉取标记为0或1表示，且拉取标记为1时，表示当前目标客户端正在拉取离线消息，拉取标记为0时，表示当前目标客户端没有拉取离线消息为例，如果获取的当前目标客户端对应的拉取标记为0，则可以确认当前目标客户端没有拉取离线消息，这时，可以按预设条件对当前目标客户端对应的离线消息的文件进行压缩，比如，如果预设压缩时间为每天时，每个压缩文件中包含的预设文件数量为5个，则可以在每天零点时，开始压缩前一天的保存有离线消息的文件，按预设排序方式，每5个文件压缩为一个压缩文件，每次压缩得到的压缩文件确定为该当前目标客户端对应的当前压缩文件。
步骤914，设置当前目标客户端对应的压缩标记为第二压缩参数；其中，第二压缩参数用于指示：当前目标客户端对应的离线消息的文件未进行压缩。
为方便说明，假如预设压缩时间为每天，每个压缩文件中包含的预设文件数量为5个，保存有离线消息的文件的数量多于5个，且按照每个文件的文件名称中时间戳倒序的方式对各个文件进行排序，在实际实现时，通常每完成一次压缩过程，就会设置当前目标客户端对应的压缩标记为第二压缩参数；比如，如果压缩标记以0或1表示，且压缩标记为1时，表示服务器正在对目标客户端对应的保存有离线消息的文件进行压缩；压缩标记为0时，表示服务器没有对目标客户端对应的保存有离线消息的文件进行压缩为例，假如在第一次压缩时，在将时间戳较新的5个文件压缩为一个压缩文件后，设置当前目标客户端对应的压缩标记为0。
步骤916，在对当前目标客户端对应的离线消息的文件进行压缩的过程中，设置当前目标客户端对应的压缩标记为第一压缩参数；其中，第一压缩参数用于指示：当前目标客户端对应的离线消息的文件正在进行压缩。
在对当前目标客户端对应的离线消息的文件进行压缩的过程中，通常需要设置当前目标客户端对应的压缩标记，在实际实现时，该压缩标记可以以0或1表示，也可以选择其他表示方式；比如，如果压缩标记为1，表示服务器正在对当前目标客户端对应的保存有离线消息的文件进行压缩；如果压缩标记为0，表示服务器没有对当前目标客户端对应的保存有离线消息的文件进行压缩，这样，在对当前目标客户端对应的离线消息的文件进行压缩的过程中，设置当前目标客户端对应的压缩标记为1。
步骤918，继续执行获取当前目标客户端对应的拉取标记的步骤，直至当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中，或者得到当前目标客户端对应的各个压缩文件。
在实际实现时，针对多个目标客户端中的每个目标客户端，在完成一次压缩过程，并设置当前目标客户端对应的压缩标记为第二压缩参数后，通常会继续执行获取当前目标客户端对应的拉取标记的步骤，根据每个目标客户端的拉取标记，完成对目标客户端的存储有离线消息的文件的压缩，或者，将目标客户端对应的离线消息的文件缓存至未完成压缩任务中。
步骤920，遍历未完成压缩任务中所包含的各个目标客户端对应的离线消息的文件，继续执行获取当前目标客户端对应的拉取标记的步骤，直至得到各个目标客户端对应的压缩文件。
在实际实现时，在对目标客户端对应的离线消息的文件进行压缩过程中，如果目标客户端上线，会将目标客户端对应的离线消息的文件缓存至未完成压缩任务中，但是该目标客户端有可能从最新的时间戳开始，只拉取了离线消息，有的离线消息并没有完成拉取，还保存在未完成压缩任务中，需要遍历未完成压缩任务中所包含的目标客户端对应的离线消息的文件，继续执行获取当前目标客户端对应的拉取标记的步骤，直至得到各个目标客户端对应的压缩文件。比如，目标客户端对应的存储有离线消息的文件有10个，每个文件的大小为50k，如果在压缩该目标客户端的保存有离线消息的文件时，该目标客户端上线，则压缩程序暂停，该目标客户端可能就只拉取了100k就下线了，这时需要再检测一下未完成压缩任务中，是否还有未拉取的未压缩的保存有离线消息的文件，如果有，继续压缩。
步骤922，如果接收到来自目标客户端的离线消息获取请求，获取目标客户端对应的压缩标记。
步骤924，如果压缩标记为第二压缩参数，将目标客户端对应的压缩文件发送至目标客户端。
为便于说明，仍以压缩标记可以以0或1表示，且压缩标记为1时，表示服务器正在对目标客户端对应的保存有离线消息的文件进行压缩；如果压缩标记为0，表示服务器没有对目标客户端对应的保存有离线消息的文件进行压缩为例，如果压缩标记为0，则说明在接收到来自目标客户端的离线消息获取请求时，服务器并没有执行对目标客户端对应的保存有离线消息的文件进行压缩的过程，这时，可以将目标客户端对应的压缩文件发送至目标客户端。
步骤926，设置目标客户端对应的拉取标记为第二拉取参数。
为便于说明，仍以拉取标记为0或1表示，且拉取标记为1时，表示当前目标客户端正在拉取离线消息，拉取标记为0时，表示当前目标客户端没有拉取离线消息为例，在服务器将目标客户端对应的压缩文件发送至目标客户端时，可以设置该目标客户端对应的拉取标记为1。
步骤928，如果压缩标记为第一压缩参数，将目标客户端对应的离线消息的文件正在进行压缩的事件返回至目标客户端，以使目标客户端延迟发出离线消息获取请求。
如果压缩标记为1，则说明在接收到来自目标客户端的离线消息获取请求时，服务器正在对目标客户端对应的保存有离线消息的文件进行压缩，这时，服务器通常会将标客户端对应的离线消息的文件正在进行压缩的事件返回至目标客户端，以使该目标客户端延迟重复发出离线消息获取请求。
步骤930，重复执行如果接收到来自目标客户端的离线消息获取请求，获取目标客户端对应的压缩标记的步骤，直至将目标客户端对应的压缩文件发送至目标客户端。
如果接收到目标客户端延迟一定时间后，再次发出的离线消息获取请求，则重复执行如果接收到来自目标客户端的离线消息获取请求，获取目标客户端对应的压缩标记的步骤，直至将目标客户端对应的压缩文件发送至目标客户端。
本发明实施例提供的另一种离线消息处理方法，在对保存有离线消息的文件进行存储和压缩的过程中，如果目标客户端上线，通过加锁的方式防止出现目标客户端拉取离线消息时，与存储或压缩过程的不同步问题。
为进一步理解上述实施例，下面提供如图4所示的一种离线消息的存储流程示意图，用户A发送消息给用户B(相当于上述目标客户端)，服务器判断用户B为离线状态，则服务器将该离线消息发送至MQ(相当于上述目标客户端对应的消息队列)，对MQ中的离线消息执行离线存储服务，将离线消息存储进HDFS，对HDFS中的文件执行离线定时压缩服务，如，每天凌晨对前一天的数据进行压缩存储。参见图5所示的一种离线消息的存储方式示意图，从离线存储根目录中获取到用户B对应的离线消息，其中包括2个不同时间戳的文件和2个不同时间戳的压缩文件，当用户B拉取离线消息时，用户B根据时间戳进行消息拉取和删除，每次拉取一个文件或压缩文件，同时根据时间戳删除上一个文件或压缩文件，服务器根据当前拉取的是否是压缩文件，返回给客户端是否进行解压，和压缩算法的标记。
下面提供如图6(a)和图6(b)所示的一种离线消息存储和拉取离线消息的锁流程图；图6(a)中，当服务器接收到其他客户端发送给用户B(相当于上述目标客户端)的离线消息后，将该离线消息发送至MQ，针对每一条离线消息，在将该离线消息发送MQ后，服务器将用户B的离线消息未处理条数加1，然后将MQ中的离线消息进行离线消息存储，针对每一条离线消息，在将离线消息存储文件后，将用户B的离线消息未处理数减1。图6(b)中，当用户B发出离线消息获取请求，需要拉取离线消息时，先判断用户B的离线消息未处理条数是否为0，如果是，则开始拉取离线消息，如果否，则将用户B的离线消息未处理条数不为0的时间返回至用户B，以使用户B重复执行发出离线消息获取请求。需要说明的是，图6(a)和图6(b)是在服务器正在存储离线数据时，用户上线拉取的操作流程，是随时可能发生的。
下面提供如图7(a)和图7(b)所示的一种拉取离线消息和定时离线压缩服务的锁流程图；图7(a)中，当开始执行定时压缩服务时，遍历所有离线用户文件夹(相当于上述保存有各个目标客户端对应的离线消息的文件)，判断当前用户是否正在拉取离线消息，如果当前用户正在拉取离线消息，临时跳过该当前用户，并将该当前用户对应的离线消息的文件存入未完成压缩任务缓存中；如果当前用户没有拉取离线消息，则开始压缩该当前用户的前一天的离线文件(相当于存储离线消息的文件)，在按照预设条件对这些离线文件进行压缩过程中，通常会将用户压缩标记设置为1，表示正在执行压缩，通常每完成一次压缩，即每得到一个压缩文件，就会将用户压缩标记设置为0，表示当前压缩文件已完成压缩，这时，会继续执行判断当前用户是否正在拉取离线消息的过程，也就是说，每完成一次压缩过程，得到一个压缩文件后，就会检查当前用户是否上线，而不是将该当前用户的所有离线文件全部压缩完之后才检查该当前用户是否上线，通过执行上述过程直至该当前用户的离线文件已完成相应的压缩，或已缓存至未完成压缩任务中，对其他离线用户按照同样的方式对相应的离线文件进行压缩，直至其他离线用户的离线文件已完成相应的压缩，或已缓存至未完成压缩任务中，最后，读取未完成压缩任务缓存，遍历未完成压缩任务缓存中所包含的离线用户对应的离线消息的文件，继续执行判断当前离线用户是否正在拉取离线消息的过程，直至未完成压缩任务缓存中的文件全部完成压缩。
图7(b)中，如果目标客户端是B用户，当B用户上线后，读取其对应的用户压缩标记，判断是否正在压缩，如果没有压缩，则B用户开始拉取离线消息，并设置拉取标记为1，表示正在执行拉取过程；如果正在压缩，则返回该结果给客户端，客户端延迟重复拉取操作。需要说明的是，图7(a)和图7(b)是服务器正在执行压缩过程是，用户上线拉取的操作流程，而压缩通常是定时压缩，是有时间段的，比如晚上零时执行定时压缩，在这个时间段可能存在压缩和拉取的冲突。
本申请提供的离线消息处理方式，解决了离线消息存储压力大，拉取性能较差，以及移动网络和应用本身的不稳定导致离线消息丢失等问题，实现了用户离线消息可靠，不丢失。
其中，对于离线消息存储压力大的问题，本申请采用分布式文件系统HDFS存储离线消息，相比关系型数据库,可横向扩充的优势，存储不够的时候直接扩展集群机器数量即可，而且机器存储容量大即可，不需要太高的配置，而关系型数据库是纵向扩充，如果存储不够，只能换存储更大的机器或更换磁盘，实施困难性和成本都很高。作为替代方案，也可以选择其他分布式文件系统替代HDFS，如ceph(一种分布式文件系统)。
如果有用户离线数据长期未拉取，就会在关系型数据库中积压大量数据，所以为了节省存储空间，相关技术中，群聊消息存储往往采用读扩散的方式，当拉取其中某一用户的离线数据时，就需要用过B+树索引的方式去检索数据，检索效率低，当存储大量离线数据的时候，数据库的检索性能会比较差，而本申请中利用分布式文件系统存储离线消息后，直接会到某个用户的文件夹下面找到离线数据，检索的时间忽略不计，查询的速度很快，而且不会随着数据的增多而导致检索性能下降，解决了离线消息拉取性能较差的问题。
通过业务层ack机制保证了离线消息不会丢失，通过控制每次传输的文件大小，减少因为移动网络不稳定造成的传输失败的风险，客户端也不会因为一次性数据量过大而变得卡顿。
本发明实施例提供了一种离线消息处理装置的结构示意图，如图8所示，该装置包括：接收模块130，用于如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将消息确定为给目标客户端的离线消息；保存模块131，用于如果按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；获取模块132，用于按预设条件对文件进行压缩，得到目标客户端对应的压缩文件；发送模块133，用于如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端。
本发明实施例提供的离线消息处理装置，如果接收到发送至目标客户端的消息，且目标客户端为离线状态，将该消息确定为给目标客户端的离线消息；按预设数据量大小，将离线消息保存至目标客户端对应的至少一个文件中；按预设条件对文件进行压缩，得到目标客户端对应的压缩文件；如果接收到来自目标客户端的离线消息获取请求，将压缩文件发送至目标客户端。该装置通过限定目标客户端的每个文件中存储的离线消息的数据量，以及对文件进行压缩的方式，减少了存储离线消息所占用的存储空间，并且将压缩文件发送给目标客户端时的数据量也较小，提高了离线消息传送的稳定性。
进一步的，每个文件的文件名称为该文件中指定离线消息的时间戳；预设条件包括预设压缩时间、每个压缩文件中包含的预设文件数量，以及每个文件的文件名称排序方式；获取模块132还用于：按预设压缩时间、预设文件数量，以及每个文件的文件名称排序方式，对文件进行压缩，得到目标客户端对应的至少一个压缩文件；其中，每个压缩文件的文件名称为该压缩文件中指定文件的文件名称。
进一步的，发送模块133还用于：如果接收到来自目标客户端的离线消息获取请求，按照每个压缩文件的文件名称中的时间戳的顺序，获取当前压缩文件；将当前压缩文件，以及当前压缩文件的压缩算法标记，发送至目标客户端，以使目标客户端根据压缩算法标记解压当前压缩文件；如果当前压缩文件存在前一个压缩文件，删除前一个压缩文件。
进一步的，保存模块131还用于：将离线消息发送至目标客户端对应的消息队列；按预设数据量大小，将消息队列中的离线消息发送并保存至目标客户端对应的至少一个文件中。
进一步的，发送模块133还用于：如果接收到来自目标客户端的离线消息获取请求，统计消息队列中的当前离线消息数量；如果当前离线消息数量为零，将压缩文件发送至目标客户端；如果当前离线消息数量不为零，继续执行统计消息队列中的当前离线消息数量的步骤，直至将压缩文件发送至目标客户端。
进一步的，目标客户端为多个；获取模块132还用于：遍历保存有各个目标客户端对应的离线消息的文件；针对每个目标客户端，基于所遍历的当前目标客户端对应的离线消息的文件，获取当前目标客户端对应的拉取标记；如果拉取标记为第二拉取参数，将当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中；其中，第二拉取参数用于指示当前目标客户端正在拉取离线消息；如果拉取标记为第一拉取参数，按预设条件对当前目标客户端对应的离线消息的文件进行压缩，得到当前目标客户端对应的当前压缩文件；其中，第一拉取参数用于指示当前目标客户端未拉取离线消息；设置当前目标客户端对应的压缩标记为第二压缩参数；其中，第二压缩参数用于指示：当前目标客户端对应的离线消息的文件未进行压缩；在对当前目标客户端对应的离线消息的文件进行压缩的过程中，设置当前目标客户端对应的压缩标记为第一压缩参数；其中，第一压缩参数用于指示：当前目标客户端对应的离线消息的文件正在进行压缩；继续执行获取当前目标客户端对应的拉取标记的步骤，直至当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中，或者得到当前目标客户端对应的各个压缩文件；遍历未完成压缩任务中所包含的各个目标客户端对应的离线消息的文件，继续执行获取当前目标客户端对应的拉取标记的步骤，直至得到各个目标客户端对应的压缩文件。
进一步的，发送模块133还用于：如果接收到来自目标客户端的离线消息获取请求，获取目标客户端对应的压缩标记；如果压缩标记为第二压缩参数，将目标客户端对应的压缩文件发送至目标客户端；设置目标客户端对应的拉取标记为第二拉取参数；如果压缩标记为第一压缩参数，将目标客户端对应的离线消息的文件正在进行压缩的事件返回至目标客户端，以使目标客户端延迟发出离线消息获取请求；重复执行如果接收到来自目标客户端的离线消息获取请求，获取目标客户端对应的压缩标记的步骤，直至将目标客户端对应的压缩文件发送至目标客户端。
本发明实施例所提供的离线消息处理装置，其实现原理及产生的技术效果和前述离线消息处理方法实施例相同，为简要描述，离线消息处理装置实施例部分未提及之处，可参考前述离线消息处理方法实施例中相应内容。
本发明实施例还提供了一种服务器，参见图9所示，该服务器包括处理器140和存储器141，该存储器141存储有能够被处理器140执行的机器可执行指令，该处理器140执行机器可执行指令以实现上述离线消息处理方法。
进一步地，图9所示的服务器还包括总线142和通信接口143，处理器140、通信接口143和存储器141通过总线142连接。
其中，存储器141可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口143(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线142可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
处理器140可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器140中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器140可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processor，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器141，处理器140读取存储器141中的信息，结合其硬件完成前述实施例的方法的步骤。
本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述离线消息处理方法，具体实现可参见方法实施例，在此不再赘述。
本发明实施例所提供的离线消息处理方法、装置和服务器的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (7)

1.一种离线消息处理方法，其特征在于，所述方法包括：
如果接收到发送至目标客户端的消息，且所述目标客户端为离线状态，将所述消息确定为给所述目标客户端的离线消息；
采用分布式文件系统存储所述离线消息，按预设数据量大小，将所述离线消息保存至所述目标客户端对应的至少一个文件中；
按预设条件对所述文件进行压缩，得到所述目标客户端对应的压缩文件；
如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端；
每个所述文件的文件名称为该文件中指定离线消息的时间戳；所述预设条件包括预设压缩时间、每个所述压缩文件中包含的预设文件数量，以及每个所述文件的文件名称排序方式；
所述按预设条件对所述文件进行压缩，得到所述目标客户端的压缩文件的步骤包括：
按所述预设压缩时间、所述预设文件数量，以及每个所述文件的文件名称排序方式，对所述文件进行压缩，得到所述目标客户端对应的至少一个压缩文件；其中，每个所述压缩文件的文件名称为该压缩文件中指定文件的文件名称；
所述如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端的步骤包括：
如果接收到来自所述目标客户端的离线消息获取请求，按照每个所述压缩文件的文件名称中的时间戳的顺序，获取当前压缩文件；
将所述当前压缩文件，以及所述当前压缩文件的压缩算法标记，发送至所述目标客户端，以使所述目标客户端根据所述压缩算法标记解压所述当前压缩文件；
如果所述当前压缩文件存在前一个压缩文件，删除所述前一个压缩文件；
所述目标客户端为多个；所述按预设条件对所述文件进行压缩，得到所述目标客户端对应的压缩文件的步骤包括：
遍历保存有各个所述目标客户端对应的离线消息的文件；
针对每个所述目标客户端，基于所遍历的当前目标客户端对应的离线消息的文件，获取所述当前目标客户端对应的拉取标记；
如果所述拉取标记为第二拉取参数，将所述当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中；其中，所述第二拉取参数用于指示所述当前目标客户端正在拉取离线消息；
如果所述拉取标记为第一拉取参数，按预设条件对所述当前目标客户端对应的离线消息的文件进行压缩，得到所述当前目标客户端对应的当前压缩文件；其中，所述第一拉取参数用于指示所述当前目标客户端未拉取离线消息；
设置所述当前目标客户端对应的压缩标记为第二压缩参数；其中，所述第二压缩参数用于指示：所述当前目标客户端对应的离线消息的文件未进行压缩；
在对所述当前目标客户端对应的离线消息的文件进行压缩的过程中，设置所述当前目标客户端对应的压缩标记为第一压缩参数；其中，所述第一压缩参数用于指示：所述当前目标客户端对应的离线消息的文件正在进行压缩；
继续执行获取所述当前目标客户端对应的拉取标记的步骤，直至所述当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中，或者得到所述当前目标客户端对应的各个压缩文件；
遍历所述未完成压缩任务中所包含的各个目标客户端对应的离线消息的文件，继续执行获取所述当前目标客户端对应的拉取标记的步骤，直至得到各个目标客户端对应的压缩文件。
2.根据权利要求1所述的方法，其特征在于，所述按预设数据量大小，将所述离线消息保存至所述目标客户端对应的至少一个文件中的步骤包括：
将所述离线消息发送至所述目标客户端对应的消息队列；
按预设数据量大小，将所述消息队列中的离线消息发送并保存至所述目标客户端对应的至少一个文件中。
3.根据权利要求2所述的方法，其特征在于，所述如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端的步骤包括：
如果接收到来自所述目标客户端的离线消息获取请求，统计所述消息队列中的当前离线消息数量；
如果所述当前离线消息数量为零，将所述压缩文件发送至所述目标客户端；
如果所述当前离线消息数量不为零，继续执行统计所述消息队列中的当前离线消息数量的步骤，直至将所述压缩文件发送至所述目标客户端。
4.根据权利要求1所述的方法，其特征在于，所述如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端的步骤包括：
如果接收到来自所述目标客户端的离线消息获取请求，获取所述目标客户端对应的压缩标记；
如果所述压缩标记为第二压缩参数，将所述目标客户端对应的压缩文件发送至所述目标客户端；
设置所述目标客户端对应的拉取标记为第二拉取参数；如果所述压缩标记为第一压缩参数，将所述目标客户端对应的离线消息的文件正在进行压缩的事件返回至所述目标客户端，以使所述目标客户端延迟发出离线消息获取请求；
重复执行如果接收到来自所述目标客户端的离线消息获取请求，获取所述目标客户端对应的压缩标记的步骤，直至将所述目标客户端对应的压缩文件发送至所述目标客户端。
5.一种离线消息处理装置，其特征在于，所述装置包括：
接收模块，用于如果接收到发送至目标客户端的消息，且所述目标客户端为离线状态，将所述消息确定为给所述目标客户端的离线消息；
保存模块，用于采用分布式文件系统存储所述离线消息，按预设数据量大小，将所述离线消息保存至所述目标客户端对应的至少一个文件中；
获取模块，用于按预设条件对所述文件进行压缩，得到所述目标客户端对应的压缩文件；
发送模块，用于如果接收到来自所述目标客户端的离线消息获取请求，将所述压缩文件发送至所述目标客户端；
获取模块，还用于按预设压缩时间、预设文件数量，以及每个所述文件的文件名称排序方式，对所述文件进行压缩，得到所述目标客户端对应的至少一个压缩文件；其中，每个所述压缩文件的文件名称为该压缩文件中指定文件的文件名称；
发送模块，还用于如果接收到来自所述目标客户端的离线消息获取请求，按照每个所述压缩文件的文件名称中的时间戳的顺序，获取当前压缩文件；将所述当前压缩文件，以及所述当前压缩文件的压缩算法标记，发送至所述目标客户端，以使所述目标客户端根据所述压缩算法标记解压所述当前压缩文件；如果所述当前压缩文件存在前一个压缩文件，删除所述前一个压缩文件；
获取模块，还用于遍历保存有各个所述目标客户端对应的离线消息的文件；针对每个所述目标客户端，基于所遍历的当前目标客户端对应的离线消息的文件，获取所述当前目标客户端对应的拉取标记；如果所述拉取标记为第二拉取参数，将所述当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中；其中，所述第二拉取参数用于指示所述当前目标客户端正在拉取离线消息；如果所述拉取标记为第一拉取参数，按预设条件对所述当前目标客户端对应的离线消息的文件进行压缩，得到所述当前目标客户端对应的当前压缩文件；其中，所述第一拉取参数用于指示所述当前目标客户端未拉取离线消息；设置所述当前目标客户端对应的压缩标记为第二压缩参数；其中，所述第二压缩参数用于指示：所述当前目标客户端对应的离线消息的文件未进行压缩；在对所述当前目标客户端对应的离线消息的文件进行压缩的过程中，设置所述当前目标客户端对应的压缩标记为第一压缩参数；其中，所述第一压缩参数用于指示：所述当前目标客户端对应的离线消息的文件正在进行压缩；继续执行获取所述当前目标客户端对应的拉取标记的步骤，直至所述当前目标客户端对应的离线消息的文件缓存至未完成压缩任务中，或者得到所述当前目标客户端对应的各个压缩文件；遍历所述未完成压缩任务中所包含的各个目标客户端对应的离线消息的文件，继续执行获取所述当前目标客户端对应的拉取标记的步骤，直至得到各个目标客户端对应的压缩文件。
6.一种服务器，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现权利要求1-4任一项所述的离线消息处理方法。
7.一种机器可读存储介质，其特征在于，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现权利要求1-4任一项所述的离线消息处理方法。
CN202010509692.8A 2020-06-05 2020-06-05 离线消息处理方法、装置和服务器 Active CN111654428B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010509692.8A CN111654428B (zh) 2020-06-05 2020-06-05 离线消息处理方法、装置和服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010509692.8A CN111654428B (zh) 2020-06-05 2020-06-05 离线消息处理方法、装置和服务器

Publications (2)

Publication Number Publication Date
CN111654428A CN111654428A (zh) 2020-09-11
CN111654428B true CN111654428B (zh) 2022-05-17

Family

ID=72352324

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010509692.8A Active CN111654428B (zh) 2020-06-05 2020-06-05 离线消息处理方法、装置和服务器

Country Status (1)

Country Link
CN (1) CN111654428B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112162872A (zh) * 2020-09-25 2021-01-01 海尔优家智能科技（北京）有限公司 消息处理方法及装置、存储介质、电子装置
CN112737928B (zh) * 2021-01-08 2022-07-15 金现代信息产业股份有限公司 即时通讯消息发送方法及装置
CN113467718B (zh) * 2021-06-25 2024-03-26 北京达佳互联信息技术有限公司 一种数据处理方法、装置、电子设备及存储介质
CN115022304B (zh) * 2022-05-27 2024-01-26 来也科技(北京)有限公司 基于rpa和ai实现ia的跨平台文件处理方法、装置和系统
CN115002137B (zh) * 2022-08-03 2022-10-21 广州此声网络科技有限公司 离线消息处理方法、装置、计算机设备和存储介质
CN115314457B (zh) * 2022-08-09 2024-04-19 湖南快乐阳光互动娱乐传媒有限公司 离线消息处理方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009003377A1 (fr) * 2007-06-29 2009-01-08 Tencent Technology (Shenzhen) Company Limited Procédé, système et client servant à transmettre des données dans un système de messagerie instantanée
CN104683217A (zh) * 2013-12-03 2015-06-03 腾讯科技（深圳）有限公司 一种多媒体信息的传输方法及即时通讯客户端
CN108206818A (zh) * 2016-12-20 2018-06-26 中移（杭州）信息技术有限公司 一种消息系统登录方法、登录装置和即时消息服务器
CN108717359A (zh) * 2018-05-10 2018-10-30 北京酷我科技有限公司 一种基于离线包的app模块的更新方法
CN109756417A (zh) * 2019-01-04 2019-05-14 平安科技（深圳）有限公司 离线消息分发方法、服务器及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020095513A1 (en) * 2001-01-16 2002-07-18 Freddie Lin Multilayer lossless data compression across a network
KR20020074370A (ko) * 2001-07-19 2002-09-30 박정진 홈페이지 자동생성 기능의 전자앨범, 웹페이지앨범
CN103139241A (zh) * 2011-11-24 2013-06-05 腾讯科技（深圳）有限公司 网络资源文件的离线下载系统和方法
CN107193576A (zh) * 2016-03-15 2017-09-22 阿里巴巴集团控股有限公司 一种移动终端应用程序的更新方法和装置
US10148698B2 (en) * 2016-09-30 2018-12-04 Fortinet, Inc. Selective enforcement of event record purging in a high volume log system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009003377A1 (fr) * 2007-06-29 2009-01-08 Tencent Technology (Shenzhen) Company Limited Procédé, système et client servant à transmettre des données dans un système de messagerie instantanée
CN104683217A (zh) * 2013-12-03 2015-06-03 腾讯科技（深圳）有限公司 一种多媒体信息的传输方法及即时通讯客户端
CN108206818A (zh) * 2016-12-20 2018-06-26 中移（杭州）信息技术有限公司 一种消息系统登录方法、登录装置和即时消息服务器
CN108717359A (zh) * 2018-05-10 2018-10-30 北京酷我科技有限公司 一种基于离线包的app模块的更新方法
CN109756417A (zh) * 2019-01-04 2019-05-14 平安科技（深圳）有限公司 离线消息分发方法、服务器及存储介质

Also Published As

Publication number Publication date
CN111654428A (zh) 2020-09-11

Similar Documents

Publication Publication Date Title
CN111654428B (zh) 离线消息处理方法、装置和服务器
US10909110B1 (en) Data retrieval from a distributed data storage system
CN108243256B (zh) 一种数据存储方法、编码设备及解码设备
JP5585062B2 (ja) 情報処理装置、情報処理方法、データ管理サーバおよびデータ同期システム
US20150006475A1 (en) Data deduplication in a file system
JP2005521938A (ja) データサービスによるデータ処理装置の全無線同期システム及び方法
CN109905479B (zh) 文件传输方法和装置
US20140143202A1 (en) Regulated Texting Solution for Mobile Devices
CN111708743A (zh) 文件存储管理方法、文件管理客户端及文件存储管理系统
EP2309389A1 (en) Delivery with reconciliation on client side
CN111464635B (zh) 一种字典索引传输方法及装置
CN101977361A (zh) 一种批量短信预处理方法
CN114641034B (zh) 一种基于5g消息系统的下行信息处理方法及相关组件
CN114924687A (zh) 存储装置、计算机系统及数据传送程序
CN115617760B (zh) 一种大批量文件快速上传的方法
CN111245949A (zh) 文件归档传输方法、装置及设备
CN111414277A (zh) 数据恢复方法、装置、电子设备和介质
CN111355793A (zh) 一种基于HTML5和Python的大文件上传方法
CN113535482B (zh) 云备份链数据备份方法及装置、设备、可读介质
CN111953580B (zh) 一种会话发送、会话获取的方法、装置和存储介质
CN105868057A (zh) 一种数据处理的方法、装置和移动终端
CN112468386B (zh) 一种重复消息的处理方法及终端
CN111901416B (zh) 一种解决大数据平台数据冲击的系统和方法
CN114461414A (zh) 基于消息队列的延时消息处理方法、装置、终端和存储介质
CN114915622A (zh) 一种web端基于http的文件传输方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant