A method, device, and storage medium for processing a session message

Abstract

The application discloses a kind of processing method, device and equipment of conversation message and storage medium, from server pull target object corresponding message stream is analyzed, determine deletion instruction message, obtain the first session identifier and first message identifier corresponding to deletion instruction message, according to the first session identifier determine the target session that needs to carry out conversation message deletion, according to the first message identifier determines the deletion cutoff position of conversation message. Start asynchronous deletion task and carry out message deletion job to target session, by the deletion task of asynchronous processing conversation message, can maintain the conversation function of client in available state, reduce the interference to normal conversation communication;For target session, first according to the first message identifier carries out the filtration of conversation message, then carry out the display of conversation message, can improve the efficiency and accuracy of message display, improve the use experience of the conversation function of application program.The technical scheme of the application can be widely applied in message processing technical field.

Description

Technical Field

[0001] This application relates to the field of message processing technology, and in particular to a method, apparatus, device and storage medium for processing conversational messages. Background Technology

[0002] Currently, with the rapid development of information technology, related services have gradually integrated into people's lives. For example, various applications provide diverse functions and are widely used in daily work, life, and entertainment. Some applications offer conversational functionality, allowing different individuals to communicate online anytime, anywhere, improving the convenience and efficiency of communication. During the use of conversational functionality, conversation messages are generally stored for easy review and use. However, for privacy protection or other reasons, individuals may need to delete conversation messages.

[0003] In related technologies, application session functions often include an option to delete session messages, allowing objects to perform message deletion on the terminal device. However, in practice, it has been found that some objects retain a large number of session messages. Deleting these messages can be time-consuming, during which the session function becomes unavailable, hindering normal communication and information display, resulting in a poor user experience. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for processing session messages, which can reduce interference with normal session communication when deleting session messages and improve the efficiency and accuracy of message display.

[0005] One aspect of this application provides a method for processing session messages, applied to a client, the method comprising:

[0006] Retrieve message streams corresponding to the target object from the server; wherein, the message streams are used to carry session messages of several sessions of the target object and instruction messages for the session messages;

[0007] The message stream is parsed. If it is determined that there is a deletion instruction message in the message stream, the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message are obtained; wherein, the first message identifier is used to indicate the deletion end position of the session message;

[0008] The target session is determined based on the first session identifier, and an asynchronous deletion task is started based on the first message identifier to perform message deletion on the target session;

[0009] In response to the target object's interactive operation on the target session, the session messages in the target session are filtered according to the first message identifier, and the filtered target session is displayed to the target object.

[0010] On the other hand, embodiments of this application provide a session message processing apparatus applied to a client, the apparatus comprising:

[0011] A retrieval unit is used to retrieve a message stream corresponding to a target object from the server; wherein the message stream is used to carry session messages of several sessions of the target object and instruction messages for the session messages;

[0012] The parsing unit is used to parse the message stream. If it is determined that there is a deletion instruction message in the message stream, it obtains the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message; wherein, the first message identifier is used to indicate the deletion cutoff position of the session message.

[0013] The initiation unit is used to determine the target session based on the first session identifier and to initiate an asynchronous deletion task based on the first message identifier to perform message deletion operations on the target session;

[0014] The display unit is used to respond to the interactive operation of the target object on the target session, filter the session messages in the target session according to the first message identifier, and display the filtered target session to the target object.

[0015] Optionally, in some embodiments, the message stream generation process includes the following steps:

[0016] The server receives a message corresponding to the target object and the associated information of the message; wherein the message is the session message or the instruction message, and the associated information includes the session identifier, the sending timestamp, and the message type corresponding to the message;

[0017] The server assigns a corresponding message identifier to the message;

[0018] The server generates a message entry corresponding to the message based on the message identifier, the association information, and the message content.

[0019] The server adds the message entry to the message stream corresponding to the target object.

[0020] Optionally, in some embodiments, the parsing unit is specifically used for:

[0021] Each message entry in the message stream is parsed to determine the associated information corresponding to each message;

[0022] Based on the message type in the associated information, determine whether the message belongs to the deletion instruction message.

[0023] Optionally, in some embodiments, the starting unit is specifically used for:

[0024] Save the first session identifier and the first message identifier to a pre-established cursor table;

[0025] An asynchronous message deletion thread is established, and the first session identifier and the first message identifier are obtained from the cursor table through the message deletion thread;

[0026] The message deletion thread queries the target session corresponding to the first session identifier and retrieves the first session message in the target session;

[0027] The message deletion thread queries the second message identifier corresponding to each first session message, and filters and deletes the first session messages based on the first message identifier and the second message identifier.

[0028] Optionally, in some embodiments, the starting unit is specifically used for:

[0029] Save the first session identifier and the first message identifier to a pre-established cursor table;

[0030] An asynchronous message deletion thread is established, and the first session identifier and the first message identifier are obtained from the cursor table through the message deletion thread;

[0031] The message deletion thread queries the target session corresponding to the first session identifier and obtains the second session message in the target session; wherein the second session message is a session message in the target session whose corresponding second message identifier is less than or equal to the first message identifier;

[0032] The message deletion thread performs deletion processing on the second session message.

[0033] Optionally, in some embodiments, the starting unit is specifically used for:

[0034] Check whether all the second session messages obtained in the previous batch have been deleted.

[0035] If it is determined that all the second session messages obtained in the previous batch have been deleted, check whether the second session messages still exist in the target session;

[0036] If the target session still contains the second session messages, obtain several of the second session messages as the second session messages in the current batch.

[0037] Optionally, in some embodiments, the apparatus further includes a deletion unit, which is specifically used for:

[0038] Monitor the processing progress of the asynchronous deletion task corresponding to the current first session identifier and the first message identifier;

[0039] If the asynchronous deletion task corresponding to the current first session identifier and the first message identifier is completed, delete the current first session identifier and the first message identifier from the cursor table, and return to the step of retrieving the first session identifier and the first message identifier from the cursor table through the message deletion thread.

[0040] Optionally, in some embodiments, the pull unit is specifically used for:

[0041] Check whether all messages in the message stream fetched in the previous batch have been processed; wherein, the message is the session message or the instruction message;

[0042] If it is determined that all messages in the message stream retrieved in the previous batch have been processed, query the first message at the end of the message stream retrieved in the previous batch;

[0043] In the message stream corresponding to the target object stored on the server, starting from the next message after the first message, a predetermined number of messages are retrieved as the message stream for the current batch.

[0044] Optionally, in some embodiments, the pull unit is specifically used for:

[0045] Check if the deletion instruction message exists in the message stream retrieved in the previous batch;

[0046] If the deletion instruction message exists in the message stream fetched in the previous batch, check whether the first session identifier and the first message identifier corresponding to the deletion instruction message fetched in the previous batch have been saved to the cursor table;

[0047] If the first session identifier and the first message identifier corresponding to the deletion instruction messages retrieved in the previous batch have been saved to the cursor table, it is determined that all deletion instruction messages in the message stream retrieved in the previous batch have been processed.

[0048] Optionally, in some embodiments, the apparatus further includes a generation unit, which is specifically used for:

[0049] In response to the deletion operation of the target object on the session message of the target session, the first session identifier of the target session is obtained;

[0050] Based on the deletion operation, determine the deletion cutoff position indicated by the target object, and determine the first message identifier based on the session message at the deletion cutoff position;

[0051] A deletion request carrying the first session identifier and the first message identifier is sent to the server, so that the server generates the deletion instruction message for the target session.

[0052] Optionally, in some embodiments, the apparatus further includes a second parsing unit, which is specifically used for:

[0053] The message stream is parsed, and if it is determined that there is a deletion instruction message in the message stream, the session identifier corresponding to the deletion instruction message and the deletion deadline contained in the message content of the deletion instruction message are obtained;

[0054] The target session is determined based on the first session identifier, and an asynchronous deletion task is started according to the deletion deadline to perform message deletion on the target session.

[0055] On the other hand, embodiments of this application provide an electronic device, including a processor and a memory;

[0056] The memory is used to store computer programs;

[0057] The processor executes the computer program to implement the aforementioned session message processing method.

[0058] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the aforementioned session message processing method.

[0059] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the aforementioned session message processing method.

[0060] The embodiments of this application include at least the following beneficial effects: This application provides a method, apparatus, device, and storage medium for processing session messages. This application retrieves a message stream corresponding to a target object from a server, parses the message stream to determine a deletion instruction message, and then obtains a first session identifier and a first message identifier corresponding to the deletion instruction message. Based on the first session identifier, it determines the target session for which session messages need to be deleted, and based on the first message identifier, it determines the deletion cutoff position of the session messages. Next, an asynchronous deletion task is initiated to perform message deletion operations on the target session. By asynchronously processing the session message deletion task, the client's session function can be maintained in an available state, reducing interference with normal session communication. For the target session, session messages are first filtered based on the first message identifier, and then the session messages are displayed, thereby achieving the same display effect as if the session message deletion task has been completed. This improves the efficiency and accuracy of message display and enhances the user experience of the application's session function. Attached Figure Description

[0061] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0062] Figure 1 This is a schematic diagram of the interface for performing session message deletion operations in related technologies;

[0063] Figure 2 This is a system architecture diagram used for a session message processing method provided in the embodiments of this application;

[0064] Figure 3 This is a schematic diagram of the terminal interface of an e-commerce website provided in the embodiments of this application;

[0065] Figure 4 This is a flowchart illustrating a method for processing session messages provided in an embodiment of this application.

[0066] Figure 5 This is a schematic diagram of the content of a message flow provided in an embodiment of this application;

[0067] Figure 6 This is a schematic diagram of another message flow provided in an embodiment of this application;

[0068] Figure 7 This is a flowchart illustrating a message deletion operation for a target session provided in an embodiment of this application;

[0069] Figure 8 This is a schematic diagram of a vernier table provided in an embodiment of this application;

[0070] Figure 9 This is a flowchart illustrating a message deletion operation for a target session, as provided in related technologies.

[0071] Figure 10 This is a schematic diagram of thread interaction provided in an embodiment of this application;

[0072] Figure 11 This is a schematic diagram illustrating a process for deleting a second session message in a target session, as provided in an embodiment of this application.

[0073] Figure 12 This is a schematic diagram illustrating how to filter session messages in a target session according to an embodiment of this application.

[0074] Figure 13 This is a structural block diagram of a session message processing device provided in an embodiment of this application;

[0075] Figure 14 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0076] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0077] It is understood that the terms “first,” “second,” etc., used in this application may be used to describe various concepts herein, but unless otherwise stated, these concepts are not limited by these terms. These terms are used only to distinguish one concept from another.

[0078] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0079] Currently, with the rapid development of information technology, related services have gradually integrated into people's lives. For example, various applications provide diverse functions and are widely used in daily work, life, and entertainment. Among them, some applications offer conversational functions, allowing different individuals to communicate online anytime, anywhere, improving the convenience and efficiency of communication.

[0080] For example, in some scenarios, conversational functionality can be configured into social applications such as WeChat and QQ. Users of these applications can use this functionality to exchange and transmit messages, such as text, images, voice, and video, enabling online communication. For example, in some scenarios, conversational functionality can be configured into customer service systems, such as those provided by online shopping platforms and bank websites. Customers can use these systems to communicate with customer service personnel and resolve issues encountered during shopping or transactions. For example, in some scenarios, conversational functionality can be configured into game programs, allowing different players to chat and discuss, thereby improving the gaming experience.

[0081] When using conversational features, applications typically retain conversation messages for easy viewing and use. However, for privacy protection or other reasons, objects may need to delete these conversation messages. For example, an object might want to delete conversation messages with a customer to protect related business privacy; or, conversation messages stored for a long time in an application may consume a lot of storage space, and to save storage resources and make more available for the terminal device, it may be necessary to periodically clear some unnecessary conversation messages.

[0082] In related technologies, application session functions often include an option to delete session messages, allowing the device to perform the deletion of session messages. For example, please refer to... Figure 1 , Figure 1 This diagram illustrates an interface for performing a session message deletion task in related technologies. When an object performs a session message deletion task on a terminal device, after initiating the relevant operation, the application's client will process the session message deletion task, removing the locally stored session messages from the storage space, thereby completing the session message deletion task. However, during the deletion process, the application's session functionality will be unavailable, for example... Figure 1 In the process of deleting session messages, a prompt box will be displayed on the front-end interface to indicate that the object is currently deleting session messages and needs to wait for a period of time. Only when the deletion task of this session message is completed or the object is manually terminated can the session function exit the unavailable state.

[0083] Understandably, if an object retains a large number of session messages, the deletion process may take a significant amount of time. During this process, the session functionality will be unavailable for an extended period, affecting normal communication and message display, resulting in a poor user experience.

[0084] In view of this, this application provides a method, apparatus, device, and storage medium for processing session messages. This application retrieves a message stream corresponding to a target object from a server, parses the message stream to determine a deletion instruction message, and then obtains a first session identifier and a first message identifier corresponding to the deletion instruction message. Based on the first session identifier, it determines the target session for which session messages need to be deleted, and based on the first message identifier, it determines the deletion cutoff position for the session messages. Next, an asynchronous deletion task is initiated to perform message deletion on the target session. By asynchronously processing the session message deletion task, the client's session functionality can be maintained in an available state, reducing interference with normal session communication. For the target session, session messages are first filtered based on the first message identifier before being displayed, achieving the same display effect as if the session message deletion task had been completed. This improves the efficiency and accuracy of message display and enhances the user experience of the application's session functionality.

[0085] System architecture and scenario description used in the embodiments of this application

[0086] Figure 2 This is a system architecture diagram of a session message processing method provided in this application embodiment, which includes a terminal device 240, an Internet 230, a gateway 220, a backend server 210, etc.

[0087] In this embodiment, the terminal device 240 can install and run related applications, such as social applications, shopping applications, and game applications. Users of the terminal device can initiate or participate in related conversation functions based on the applications on the terminal device 240. The terminal device 240 can include various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The terminal device 240 can communicate with the Internet 230 via wired or wireless means to exchange data.

[0088] A backend server 210 refers to a computer system that can provide certain services to terminal devices 240. Compared to ordinary terminal devices 240, backend servers 210 have higher requirements in terms of stability, security, and performance. A backend server 210 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines).

[0089] Gateway 220, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal device 240 to backend server 210 are forwarded to the corresponding backend server 210 via gateway 220. Messages sent from backend server 210 to terminal device 240 are also forwarded to the corresponding terminal device 240 via gateway 220.

[0090] The backend server 210 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0091] The session message processing method provided in this application embodiment can be executed on the terminal device 240, and the session message processing is realized based on the data transmission between the terminal device 240 and the backend server 210.

[0092] For example, terminal device 240 may install a client of an application with session functionality, and backend server 210 may be the backend server of that application. In this embodiment, terminal device 240 can retrieve the message stream corresponding to the target object from backend server 210, and then parse the message stream. If it is determined during the parsing process that a deletion instruction message exists in the message stream, the terminal device 240 obtains the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message. Next, terminal device 240 can determine the target session for which message deletion is required based on the first session identifier, and start an asynchronous deletion task based on the first message identifier to perform message deletion on the target session. When the target object needs to open the target session, in response to the target object's interactive operation on the target session, terminal device 240 can filter the session messages in the target session based on the first message identifier, and then display the filtered target session to the target object.

[0093] Of course, it is understood that the implementation environment corresponding to the method in the embodiments of this application is not limited to that of the implementation environment. Figure 2 As shown, those skilled in the art can flexibly select the specific implementation environment according to actual needs, and this application does not impose any restrictions on this.

[0094] The session message processing method provided in this application can be executed in various scenarios, and the following is an exemplary description of it.

[0095] (a) Scenarios for game applications

[0096] The method described in this application embodiment can be applied to game application scenarios.

[0097] For example, a game operator might offer an online multiplayer game where players can create characters, purchase virtual items, and participate in various activities. The game includes a chat function, allowing players to communicate in real-time with others, discuss strategies, and share game content and experiences.

[0098] The method described in this application embodiment can be applied to the aforementioned online multiplayer games. For example, when a player finds that the current game cache needs to be cleared, the method described in this application embodiment can be used to delete session messages, thereby reducing the storage space occupied by the game cache and improving the game's running efficiency. Moreover, during the deletion of relevant session messages, players can still communicate normally with other players without interfering with the game experience.

[0099] (II) Online shopping scenarios

[0100] Currently, online shopping is widely popular. E-commerce websites typically contain a large number of product images, videos, and related documents. Shoppers can log in to these websites to make purchases. A good e-commerce website should have high-performance data transmission capabilities and reliable data storage capabilities.

[0101] For example, please refer to Figure 3 , Figure 3 This illustration shows a terminal interface diagram of an e-commerce website provided in an embodiment of this application. This e-commerce website can provide session functionality. For example… Figure 3 The terminal interface shown includes a chat box 310, through which merchants and shoppers can communicate. The method described in this embodiment can be applied to... Figure 3 In the scenario of the e-commerce website shown, merchants or shoppers can delete relevant conversation messages as needed. The method in this embodiment can maintain the conversation function of the e-commerce website in an available state during the deletion of conversation messages, reducing interference with normal conversation communication.

[0102] General Description of Embodiments in this Application

[0103] Please refer to Figure 4 , Figure 4 A flowchart illustrating a session message processing method provided in an embodiment of this application is shown. This session message processing method can be applied to a client of an application with session functionality, and the client can be installed and deployed on, for example,... Figure 2 On the terminal device 240 shown. (As shown) Figure 4 As shown, a method for processing session messages according to an embodiment of this application includes, but is not limited to, the following steps:

[0104] Step 410: Retrieve the message stream corresponding to the target object from the server; wherein, the message stream is used to carry session messages of several sessions of the target object and instruction messages for the session messages;

[0105] Step 420: Parse the message stream. If it is determined that there is a deletion instruction message in the message stream, obtain the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message; wherein, the first message identifier is used to indicate the deletion end position of the session message.

[0106] Step 430: Determine the target session based on the first session identifier, and start the asynchronous deletion task based on the first message identifier to perform message deletion operation on the target session;

[0107] Step 440: In response to the target object's interactive operation on the target session, filter the session messages in the target session according to the first message identifier, and display the filtered target session to the target object.

[0108] In this application embodiment, a method for processing session messages is provided. This method maintains the client's session function in an available state by asynchronously processing the deletion task of session messages, reduces interference with normal session communication, improves the efficiency and accuracy of message display, and enhances the user experience of the application's session function.

[0109] The technical solutions provided in this application are mainly applied to the client of an application with session functionality. Users of this application's client can be referred to as target objects in this application, and this application does not limit the identity or type of the target object. For example, in some embodiments, the target object can be an individual; in others, it can be a group, such as an enterprise or other organization. In this application, within the application, target objects can be distinguished by accounts, with different target objects corresponding to different accounts. Of course, for the same target object, multiple different accounts can be registered for use, and this application does not impose any restrictions on this.

[0110] In this embodiment of the application, for each target object of the application, a corresponding message stream can be established and maintained for it on both the client and the server. The message stream can be used to carry session messages for several sessions of the target object, as well as instruction messages for the session messages.

[0111] For example, please refer to Figure 5 , Figure 5 This illustration shows a schematic diagram of a message flow provided in an embodiment of this application. In this embodiment, for the target object, its corresponding message flow carries all messages under the account. Based on the function of the messages, they are divided into two types: ordinary conversation messages, such as chat messages between the target object and other objects (e.g., text messages or image messages), and special command messages. Command messages are specific to conversation messages; for example, if the target object instructs the clearing of the unread status of a conversation message, a command message will be generated in its corresponding message flow. Command messages are invisible to the target object; however, the conversation messages in the message flow can be displayed on the client side.

[0112] A message stream can be a data sequence built upon multiple messages. Within this data sequence, each message corresponds to a message entry, and each message entry can include the message content itself, as well as other related information. For example, ... Figure 5 The message stream shown displays three message entries. Each message entry includes five fields: Message Identifier (ServerID), Session Identifier (ConversationID), SendTime, Message Type (ContentType), and Message Content (Content). The message identifier is a unique identifier for each message; different messages have different message identifiers. The message identifier can be a numerical value. In this embodiment, the message identifier can be an incrementing value. The message identifier for the first message entry in the message stream is 1. For each new message entry added to the message stream, the message identifier for that entry is incremented by 1 relative to the previous message entry. Figure 5 In the text, the message identifiers corresponding to the three message entries are 100, 101, and 102, respectively.

[0113] A session identifier is used to identify the session to which a message belongs. It's understood that since one account for a target object corresponds to one message stream, and one account may have multiple sessions—for example, if the target object communicates with different other objects—there will be a session between the target object and each of those other objects. These sessions all belong to the target object's sessions. It should be noted that the sessions corresponding to the target object are not limited to two individuals. In some embodiments, the target object may also belong to a group, and the group sessions corresponding to that group also belong to the target object's sessions. Therefore, in this embodiment, session identifiers can be used to distinguish the various sessions corresponding to the target object. Different sessions have different session identifiers. This application does not limit the specific form of the session identifier; for example, numbers or characters can be used to distinguish different session identifiers. Figure 5 As shown, two message entries with message identifiers 100 and 102 share the same session identifier of 20000, indicating that the message content in these two entries originates from the same session. However, the message entry with message identifier 101 has a session identifier of 1048234, which differs from the session identifiers of the other two entries. This suggests that the message content of message entry 101 belongs to a different session than the other two message entries.

[0114] The sending timestamp is used to record the sending time of the message. For session messages within a target object's session, the recipient can be either the target object itself or other objects; this application does not impose any restrictions on this. The message type is used to distinguish the type of message, and it can be represented by numbers or characters, etc. Different message types correspond to different values ​​for the message type field. Figure 5 In this application, the message type field value in each message entry is 2, indicating that they correspond to the same message type, such as text messages. For image messages, other values ​​can be used, such as 3, etc. This application does not impose any restrictions on this. The message content field is used to record the message content. For conversation messages, the format of the message content field can differ for different types of messages. For example, for text messages, the message content field can be recorded as a string; for image messages, the message content field can be recorded as encoded data.

[0115] As mentioned above, in this embodiment of the application, in addition to the session messages of the target object, the message stream may also include instruction messages for the session messages. Please refer to... Figure 6 , Figure 6 This illustration shows a different message flow content diagram provided in an embodiment of this application. Figure 6 In the message stream shown, relative Figure 5 The message stream shown has been augmented with a new message entry. This entry has a message identifier of 103, indicating it belongs to the delete instruction message type. The corresponding message type field value is 2055, and its function is to instruct the client to delete related session messages. Specifically, in this embodiment, the message entry corresponding to the delete instruction message may also include a session identifier field to indicate which session's messages are being deleted. Figure 6 The message indicates that the session ID corresponding to the deletion command message is 20000, meaning that this deletion command message is used to instruct the deletion of the session message with session ID 20000. Furthermore, in the message content field of the deletion command message, a message ID can be used to set the deletion cutoff position for the session message, that is, which session message corresponding to which message ID should be deleted.

[0116] Figure 6 In the message, the session identifier of the deletion command message is 20000, indicating that session messages in the session with session identifier 20000 will be deleted; the message content field is "message identifier = 102", indicating that session messages with the corresponding message identifier of 102 or earlier will be deleted. Combining these two fields allows us to determine the specific session messages to be deleted from the message stream. For example... Figure 6 The session messages with corresponding message identifiers 102 and 100 are the session messages that need to be deleted, while the session message with corresponding message identifier 101 does not belong to the session with corresponding session identifier 20000, so it is not one of the session messages that the deletion instruction message indicates to be deleted.

[0117] Based on the foregoing description of the message flow involved in the embodiments of this application, the following describes each step in the embodiments of this application.

[0118] In step 410, the message stream corresponding to the target object is retrieved from the server. Specifically, in this embodiment, a message stream can be established and maintained for each target object's account. On the server side, this message stream continuously increases as the number of session messages in the target object's session increases. On the client side, the message stream corresponding to the target object can be retrieved from the server synchronously for corresponding processing.

[0119] In this embodiment, when retrieving the message stream corresponding to the target object, the account information corresponding to the target object can be obtained first. Based on the account information, the corresponding message stream can be retrieved on the server side. It is understood that the message stream may include session messages from several sessions of the target object, as well as instruction messages for those session messages. In this embodiment, the number of sessions to which the target object belongs is not limited, and the type of instruction messages included in the message stream may include one or more types; this application also does not impose any limitations on this.

[0120] It should be noted that in this embodiment, the message stream corresponding to the target object changes in real time on the server side. Therefore, when the client pulls the message stream, it can be pulled in batches. For example, each time a segment of the message stream is pulled, the corresponding processing is performed locally on the client, and then the next batch of message streams is pulled until the message stream is processed and stops updating on the server side, at which point the client can pause the pulling process.

[0121] In step 420, the client can parse the retrieved message stream to determine the message type of each message, i.e., whether each message belongs to a session message or a command message. If a message in the message stream belongs to a session message, the client continues to check the next message in the message stream. If a message in the message stream belongs to a command message, the client continues to check whether it belongs to a delete command message. In this way, each message in the message stream can be traversed to determine the various delete command messages in the message stream.

[0122] In some embodiments, the currently retrieved message stream may not contain any deletion instruction messages. In this case, it indicates that the target object does not have a request to delete session messages, and the corresponding session message deletion job does not need to be executed. Conversely, in other embodiments, the currently retrieved message stream contains deletion instruction messages. In this case, it indicates that the target object has a request to delete session messages, and the corresponding session message deletion job needs to be executed.

[0123] In step 420, if there is a deletion instruction message in the message stream, the session identifier corresponding to the deletion instruction message can be obtained, which is recorded as the first session identifier in this embodiment; and the message identifier contained in the message content of the deletion instruction message can be obtained, which is recorded as the first message identifier in this embodiment.

[0124] Based on the foregoing description of each message entry in the message stream, it can be understood that the first session identifier in this application embodiment can be used to identify which session's message needs to be deleted. In this application embodiment, the session whose message needs to be deleted is recorded as the target session. The first message identifier can be used to indicate the position to which the message in the target session should be deleted, that is, to indicate the deletion of the message in the target session corresponding to the first message identifier, as well as the message in the target session preceding the message corresponding to the first message identifier.

[0125] Here, the first message identifier can be used to indicate the deletion of all session messages in a target session. For example, the first message identifier may be the message identifier corresponding to the latest session message in the target session. The first message identifier may also be used to indicate the deletion of some session messages in a target session. For example, the first message identifier may be the message identifier corresponding to an earlier session message in the target session. This application does not limit this.

[0126] It should be noted that in this embodiment, if there are deletion instruction messages in the message stream, there may be one or more of them. In the case of multiple deletion instruction messages, each message can be responded to individually. Each deletion instruction message corresponds to a first session identifier and a first message identifier. The specific implementation process is similar to that of a single deletion instruction message, and will not be specifically distinguished here.

[0127] In step 430, the target session for which the message deletion operation needs to be performed can be determined based on the first session identifier. After the target session is determined, an asynchronous deletion task can be started based on the first message identifier, thereby realizing the message deletion operation for the target session.

[0128] In this embodiment, the deletion of session messages is performed through an asynchronous deletion task, which does not block the normal session functions of the client. The target object can still use the client's session functions for interaction and information transmission normally. In this way, even if the amount of session messages to be deleted in the target session is large, the client's session functions remain available. The target object does not need to wait for the task of deleting session messages to complete before it can use the service as usual, which can reduce interference with normal session communication and improve the user experience of the application's session functions.

[0129] In step 440, when starting the asynchronous deletion task, the client's session functionality can be used as usual. The target object can open any existing session or create a new session based on the client. In some cases, the target object may open the target session. Understandably, when the target session is opened, its corresponding asynchronous deletion task may still be executing, meaning that the session message in the target session that the target object instructed to delete may not have been completely deleted from the client's message stream.

[0130] To address this issue, in this embodiment, when a target object initiates an interactive operation on a target session and needs to display the target session, it can filter the session messages in the target session based on the first message identifier. Only session messages with a message identifier greater than the first message identifier are retained, while other session messages are filtered out and not displayed. Thus, from the client's perspective, the displayed session messages achieve the same effect as if the session message deletion task has been completed. However, in the actual client's message stream, there may still be session messages that need to be deleted but have not been completely deleted, but these will not be displayed and will be imperceptible to the target object. Even if the target object immediately opens the target session after initiating the deletion operation, the displayed content will be consistent with the effect of a completed deletion, improving the efficiency and accuracy of information display.

[0131] It is understood that the session message processing method provided in this application embodiment pulls the message stream corresponding to the target object from the server, parses the message stream to determine the deletion instruction message, and then obtains the first session identifier and the first message identifier corresponding to the deletion instruction message. Based on the first session identifier, the target session for which session message deletion needs to be performed is determined, and based on the first message identifier, the deletion cutoff position of the session message is determined. Next, an asynchronous deletion task is started to perform message deletion on the target session. By asynchronously processing the session message deletion task, the client's session function can be kept available, reducing interference with normal session communication. For the target session, session messages are first filtered based on the first message identifier before being displayed, achieving the same display effect as if the session message deletion task has been completed. This improves the efficiency and accuracy of message display and enhances the user experience of the application's session function.

[0132] Specifically, in some embodiments, the message stream generation process includes the following steps:

[0133] The server receives the message corresponding to the target object and the associated information of the message; the message is either a session message or a command message, and the associated information includes the session identifier, the sending timestamp, and the message type.

[0134] The server assigns a corresponding message identifier to each message.

[0135] The server generates a message entry corresponding to the message based on the message identifier, association information, and message content.

[0136] The server adds the message entry to the message stream corresponding to the target object.

[0137] In this embodiment, the message stream of the target object is generated on the server side. Specifically, when generating the message stream of the target object, the server can receive messages corresponding to the target object and associated information corresponding to those messages. Here, the messages received by the server corresponding to the target object are session messages in the session where the target object resides, as well as instruction messages for these session messages. Specifically, these session messages can be sent by the target object itself or by other objects in the same session as the target object; this application does not impose any restrictions on this.

[0138] The instruction messages for the session messages can be the aforementioned delete instruction messages, or other types of instruction messages, such as quote instruction messages, withdraw instruction messages, hide instruction messages, read instruction messages, or star instruction messages, etc. Furthermore, the triggering object of these instruction messages can be the target object, and the triggering object of some instruction messages (such as quote instruction messages, withdraw instruction messages, etc.) can also be other objects. This application does not impose any restrictions on this.

[0139] In this embodiment, the associated information of a message may include, but is not limited to, the session identifier corresponding to the message, the sending timestamp, and the message type. For a description of each type of associated information, please refer to the foregoing. Figure 5 as well as Figure 6 The specific implementation is not detailed here. In this embodiment, the server can assign a corresponding message identifier to each message. Specifically, the message identifier for each message can be determined sequentially according to the time the message arrives at the server, with the message identifier increasing as the number of message entries in the message stream increases. Then, the server can generate a corresponding message entry based on the message identifier, associated information, and message content, and add the message entry to the message stream corresponding to the target object, such as... Figure 5 as well as Figure 6 As shown in the embodiments, message entries can be sorted according to the size of the message identifier.

[0140] It is understood that in the embodiments of this application, the number of sessions corresponding to the target object may be multiple. In the case of multiple sessions, their respective messages can be aggregated into a message stream. This application does not limit the specific number of sessions or the number of session messages involved in the message stream corresponding to the target object.

[0141] In this embodiment, the server constructs a message stream corresponding to the target object by generating message entries, which facilitates the client to pull and execute the corresponding processing, thereby improving the efficiency and accuracy of message transmission and processing.

[0142] Specifically, in some embodiments, parsing the message stream includes:

[0143] Parse each message entry in the message stream to determine the associated information for each message;

[0144] Based on the message type in the associated information, determine whether the message belongs to a deletion instruction message.

[0145] In this embodiment, for the application that constructs the message stream corresponding to the target object by generating message entries in the aforementioned embodiments, when the client parses the message stream, it can parse each message entry after pulling the message stream and extract the specific field content of each message entry. Then, it can determine the associated information corresponding to each message, such as session identifier, sending timestamp, and message type.

[0146] For each message in the message stream, its message type can be used to determine whether it belongs to a session message or a deletion command message, thus facilitating subsequent processing. If the message type field in the associated information of a message in the message stream indicates that the message belongs to a deletion command message, then it can be determined that a deletion command message exists in the message stream. If none of the associated information for any message in the message stream contains a message type field indicating that the message belongs to a deletion command message, then it can be determined that a deletion command message does not exist in the message stream.

[0147] It should be noted that, in this embodiment of the application, the specific meaning indicated by the field content of the message type is not limited. For example... Figure 6 As shown, the value 2055 can be used to represent a message type as a deletion instruction message. In other embodiments, other values ​​or characters can also be used to represent a message type as a deletion instruction message. This application does not impose any restrictions on this.

[0148] Specifically, in some embodiments, a target session is determined based on a first session identifier, and an asynchronous deletion task is initiated based on a first message identifier to perform message deletion operations on the target session, including:

[0149] Save the first session identifier and the first message identifier to a pre-established cursor table;

[0150] Establish an asynchronous message deletion thread, and retrieve the first session identifier and the first message identifier from the cursor table through the message deletion thread;

[0151] The message deletion thread queries the target session corresponding to the first session identifier and retrieves the first session message in the target session;

[0152] The message deletion thread queries the second message identifier corresponding to each first session message, and filters and deletes the first session messages based on the first message identifier and the second message identifier.

[0153] Reference Figure 7 , Figure 7 This illustration shows a flowchart of a message deletion operation for a target session according to an embodiment of this application. In this embodiment, when performing a message deletion operation on a target session, a cursor table can be pre-established. This cursor table can be used specifically to store the first session identifier of the target session requiring deletion and the first message identifier indicating the deletion deadline for session messages. For example, please refer to... Figure 8 , Figure 8 A schematic diagram of a vernier table provided in an embodiment of this application is shown. For example... Figure 8 As shown, the cursor table can store the first session identifier and the first message identifier corresponding to each asynchronous deletion task.

[0154] Reference Figure 7 In this embodiment, each message stream retrieved from the server can be processed. For session messages, they are synchronized to the client's local machine, and for command messages, their corresponding tasks are executed. Specifically, in this embodiment, it is determined whether there is a deletion command message in the message stream. If not, the action of retrieving the message stream can continue until no message stream can be retrieved, indicating that there are no new messages in the target object's session. In this case, processing can be paused or the current session message processing task can be terminated.

[0155] In some embodiments, if the retrieved message stream contains deletion instruction messages, the first session identifier and first message identifier corresponding to these deletion instruction messages can be obtained and saved to a pre-established cursor table. For example... Figure 8 As shown, for example, in the currently retrieved data stream, there are three deletion instruction messages with corresponding first session identifiers of 20000, 30000, and 40000. Among them, the target session with the first session identifier of 20000 has a corresponding first message identifier of 102, indicating that the session messages with the corresponding message identifier of 102 or earlier in the target session with the first session identifier of 20000 need to be deleted; the target session with the first session identifier of 30000 has a corresponding first message identifier of 120, indicating that the session messages with the corresponding message identifier of 120 or earlier in the target session with the first session identifier of 30000 need to be deleted; and the target session with the first session identifier of 40000 has a corresponding first message identifier of 143, indicating that the session messages with the corresponding message identifier of 143 or earlier in the target session with the first session identifier of 40000 need to be deleted.

[0156] Next, an asynchronous message deletion thread can be established. This thread retrieves the first session identifier and the first message identifier from the cursor table and then queries the target session corresponding to the first session identifier. Once the target session is identified, the session messages within it can be retrieved; in this embodiment, these are designated as first session messages. For each first session message, its corresponding message identifier can be queried; in this embodiment, these are designated as second message identifiers. Then, the first session messages in the target session can be filtered and deleted based on the first and second message identifiers. Specifically, the sizes of each second message identifier and the first message identifier can be compared. If the second message identifier is less than or equal to the first message identifier, the first session message corresponding to that second message identifier can be deleted; if the second message identifier is greater than the first message identifier, the first session message corresponding to that second message identifier can be retained.

[0157] Reference Figure 9 , Figure 9 This diagram illustrates a flowchart of a message deletion operation for a target session, as provided in related technologies. Based on... Figure 9 As can be seen, unlike the technical solution provided in the embodiments of this application, in related technologies, after parsing the message stream, if a deletion instruction message is found, the deletion task of the session message will be directly started in the main thread of the client. This implementation method obviously occupies the resources of the main thread, causing the client's session function to be temporarily suspended, waiting for the deletion task of the session message to be completed before the message stream retrieval and display tasks can continue. However, in the embodiments of this application, such as Figure 7 As shown, the deletion of session messages is achieved through asynchronous deletion tasks, which has no impact on the client's main thread, can keep the client's session functionality available, and reduces interference with normal session communication.

[0158] Of course, it should be noted that, Figure 9 The illustrated process is only used to illustrate the advantages of the technical solutions in the embodiments of this application, and does not imply any wrongdoing. Figure 9 It belongs to existing technology that has already been disclosed.

[0159] Specifically, in some embodiments, the method further includes:

[0160] Monitor the processing progress of the asynchronous deletion task corresponding to the current first session identifier and first message identifier;

[0161] If the asynchronous deletion task corresponding to the current first session identifier and the first message identifier is completed, delete the current first session identifier and the first message identifier from the cursor table, and return to execute the step of retrieving the first session identifier and the first message identifier from the cursor table through the message deletion thread.

[0162] For example, please refer to Figure 10 , Figure 10 This illustration shows a schematic diagram of thread interaction provided in an embodiment of this application. For example... Figure 10 As shown, in the client, under normal circumstances, a message receiving thread can be maintained as the main thread to handle routine session message processing tasks (such as fetching and displaying). When a deletion instruction message is detected in the message stream, an asynchronous message deletion thread can be created outside the message receiving thread. The message deletion thread can be used to asynchronously execute session message deletion tasks without affecting the message receiving thread, which can still normally handle the client's message stream fetching and display tasks.

[0163] For each asynchronous deletion task corresponding to the first session identifier and the first message identifier, after the message deletion thread completes the task, it can send a completion message to the message receiving thread, informing the message receiving thread that a set of asynchronous deletion tasks corresponding to the first session identifier and the first message identifier has been completed. For example, for... Figure 8 The message deletion thread can first select the asynchronous deletion task corresponding to the first session identifier 20000 and the first message identifier 102 from the cursor table. After execution, it sends the corresponding completion information back to the message receiving thread. Then, the message receiving thread can delete the first session identifier and first message identifier of the currently completed task from the cursor table. The message deletion thread can then continue to select the next asynchronous deletion task corresponding to the first session identifier and first message identifier from the cursor table for execution, for example... Figure 8 The asynchronous deletion task has a first session identifier of 30000 and a first message identifier of 120. This process is repeated until there are no first session identifiers or first message identifiers in the cursor table, indicating that all asynchronous deletion tasks are complete. At this point, the message deletion thread can be deleted.

[0164] It is understood that, in this embodiment of the application, recording the first session identifier and the first message identifier through a cursor table can facilitate the message deletion thread to execute asynchronous deletion tasks in sequence, which is beneficial to improving the processing efficiency of session messages and reducing the risk of missing tasks.

[0165] Specifically, in some embodiments, a target session is determined based on a first session identifier, and an asynchronous deletion task is initiated based on a first message identifier to perform message deletion operations on the target session, including:

[0166] Save the first session identifier and the first message identifier to a pre-established cursor table;

[0167] Establish an asynchronous message deletion thread, and retrieve the first session identifier and the first message identifier from the cursor table through the message deletion thread;

[0168] The message deletion thread queries the target session corresponding to the first session identifier and retrieves the second session message in the target session; wherein the second session message is a session message in the target session whose second message identifier is less than or equal to the first message identifier;

[0169] The message deletion thread handles the deletion of messages in the second session.

[0170] In the aforementioned embodiments, when processing asynchronous deletion tasks, the message deletion thread queries the target session corresponding to the first session identifier, retrieves all first session information within the target session, and then filters and deletes the first session information. In this embodiment, after determining the target session, the session messages to be deleted within the target session can be directly determined based on the first message identifier.

[0171] Specifically, in this embodiment, after determining the target session corresponding to the first session identifier, the message deletion thread can directly retrieve session messages in the target session whose corresponding message identifiers are less than or equal to the first message identifier. In this embodiment, the message identifiers corresponding to each session message in the target session are recorded as the second message identifier, and the session messages whose corresponding second message identifiers are less than or equal to the first message identifier are recorded as the second session messages.

[0172] Understandably, based on the second message identifier, the second session message that needs to be deleted can be directly located, and then the deletion process can be performed on the second session message using the message deletion thread, without needing to analyze other session messages in the target session. This improves the efficiency of session message processing and reduces the amount of data processed.

[0173] Specifically, in some embodiments, obtaining the second session message in the target session includes:

[0174] Check whether all second session messages obtained in the previous batch have been deleted.

[0175] If it is determined that all second session messages obtained in the previous batch have been deleted, check whether there are still second session messages in the target session;

[0176] If there are still second session messages in the target session, retrieve several second session messages as the second session messages in the current batch.

[0177] In this embodiment of the application, when deleting second session messages obtained from the target session, a batch deletion strategy can be adopted in some cases. Specifically, please refer to... Figure 11 , Figure 11 This illustration shows a flowchart of deleting a second session message in a target session, as provided in an embodiment of this application.

[0178] In this embodiment, when deleting second session messages in a target session, the second session messages can be acquired in batches for deletion. For the target session, a batch of second session messages can be acquired from the message stream; the specific number is not limited in this application. These second session messages are then deleted. For the current batch, it can be checked whether all second session messages acquired in the previous batch have been deleted. If so, it can be checked whether second session messages still exist in the current target session. If they do, a further number of second session messages can be acquired as the current batch. If they do not exist, it indicates that the asynchronous deletion task for the target session has been completed, and the message receiving thread can be notified to clean up the first session identifier and first message identifier corresponding to the target session in the cursor table.

[0179] In this embodiment, the quantity of messages acquired in each batch can be pre-specified, such as 1000 or 500 messages; this application does not impose any restrictions on this. If there are second-session messages in the current target session, but the quantity is insufficient to meet the pre-set acquisition quantity, all remaining second-session messages in the current target session can be acquired as the second-session messages for the current batch.

[0180] It is understandable that in this embodiment, the batch processing method for obtaining the second session message and performing deletion ensures that the deletion of session messages is completed incrementally. Compared with the method of obtaining and deleting all at once in the previous embodiments, the implementation method in this embodiment avoids the problem of needing to re-obtain and delete session messages due to deletion failures under abnormal circumstances. It is easy to understand that if all session messages are deleted at once, exceptions may occur, leading to deletion failures and the need to re-execute, resulting in repeated execution. The strategy in this embodiment, by obtaining messages in batches and deleting them sequentially, effectively improves the efficiency and stability of deletion.

[0181] Specifically, in some embodiments, retrieving the message stream corresponding to the target object from the server includes:

[0182] Check whether all messages in the message stream fetched in the previous batch have been processed; the messages are either session messages or command messages.

[0183] If it is determined that all messages in the message stream fetched in the previous batch have been processed, query the first message at the end of the message stream fetched in the previous batch.

[0184] In the message stream corresponding to the target object stored on the server, starting from the next message after the first message, a predetermined number of messages are retrieved as the message stream for the current batch.

[0185] In this embodiment of the application, the server may also use a batch-based fetching method when fetching the message stream corresponding to the target object.

[0186] Specifically, when performing the message stream retrieval operation, it can first check whether all messages in the previous batch of retrieved messages have been processed. These messages can be session messages or command messages. In this embodiment, determining whether a message has been processed involves checking whether it has been synchronized to the client for session messages; if so, processing is confirmed. For command messages, it involves checking whether they have been read and executed; once execution begins, processing can be confirmed, even if the processing is incomplete. In other words, this embodiment does not restrict whether the execution of a command message is complete.

[0187] If it is determined that all messages in the message stream retrieved in the previous batch have been processed, the message at the end of the message stream retrieved in the previous batch can be queried. In this embodiment, this message is recorded as the first message. Specifically, the message identifier corresponding to the first message can be recorded. Then, when the task of retrieving the message stream is executed in the current batch, a predetermined number of messages can be retrieved starting from the next message corresponding to the first message as the message stream retrieved in the current batch. For example, the message identifier corresponding to the first message can be incremented by 1 to obtain the message identifier corresponding to the first message in the message stream retrieved in the current batch, and a predetermined number of messages can be retrieved to obtain the corresponding message stream.

[0188] It should be noted that in this embodiment of the application, if the number of messages currently retrieved from the message stream on the server side is less than the predetermined number, the processing can proceed as usual, and this application does not impose any restrictions on this.

[0189] Specifically, in some embodiments, detecting whether all messages in the previously fetched message stream have been processed includes:

[0190] Check if a deletion instruction message exists in the message stream retrieved in the previous batch;

[0191] If there is a delete instruction message in the message stream fetched in the previous batch, check whether the first session identifier and the first message identifier corresponding to the delete instruction message fetched in the previous batch have been saved to the cursor table;

[0192] If the first session identifier and the first message identifier corresponding to the deletion instruction messages fetched in the previous batch have been saved to the cursor table, it is determined that all deletion instruction messages in the message stream fetched in the previous batch have been processed.

[0193] In this embodiment, when detecting whether all messages in the previous batch of fetched message streams have been processed, it is possible to detect whether there is a delete instruction message in the previous batch of fetched message streams. If not, for session messages and other types of messages, it is possible to determine whether they have been processed in the manner described above, which will not be repeated here. If there is a delete instruction message in the previous batch of fetched message streams, it is possible to determine whether the first session identifier and the first message identifier corresponding to the delete instruction message in the previous batch have been saved to the cursor table. If not, it is necessary to wait for the processing task of the previous batch. If the first session identifier and the first message identifier corresponding to the delete instruction message in the previous batch have both been saved to the cursor table, it can be determined that all messages in the previous batch of fetched message streams have been processed.

[0194] Understandably, in this embodiment, when checking whether all messages in the previous batch of fetched message streams have been processed, for a delete instruction message, it is considered processed only if its corresponding first session identifier and first message identifier have been saved to the cursor table. This ensures that the previous batch of delete instruction messages has been recorded and executed before fetching a new batch of message streams for processing. This prevents the deletion operation from failing due to the loss of delete instruction messages.

[0195] Furthermore, in this embodiment, the new message stream is retrieved only after the first session identifier and the first message identifier corresponding to the deletion command message have been saved to the cursor table each time. In case of abnormal situations such as program crash or hard disk damage, the message stream can be retrieved again from the last recorded deletion command message, which can effectively connect the processing tasks of session messages and prevent the omission of command messages.

[0196] Specifically, in some embodiments, the method further includes:

[0197] In response to a deletion operation of a session message for the target session by the target object, obtain the first session identifier of the target session;

[0198] Based on the deletion operation, determine the deletion cutoff position indicated by the target object, and determine the first message identifier based on the session message at the deletion cutoff position;

[0199] Send a deletion request to the server carrying the first session identifier and the first message identifier, so that the server generates a deletion instruction message for the target session.

[0200] In this embodiment of the application, the deletion instruction message can be generated on the server side based on the deletion operation of the target object's session message for the target session.

[0201] Specifically, in this embodiment, the client can receive a deletion operation from the target object regarding session messages in the target session. This deletion operation can be to delete a portion of the session messages in the target session; for example, the target object can specify which previous session message to delete, or it can delete all session messages in the target session. This application does not impose any limitations on this. Furthermore, the deletion operation initiated by the target object can be triggered by clicking a corresponding virtual icon on the terminal device, or it can be triggered through other interactive methods.

[0202] In response to a deletion operation of session messages for a target session initiated by the target object, the first message identifier of the target session can be obtained, and the deletion cutoff position indicated by the target object can be determined. The first message identifier can be determined based on the session messages at the deletion cutoff position. For example, if the target object indicates to clear all session messages in the target session, the first message identifier can be determined based on the message identifier of the last session message in the target session. This application does not limit the specific circumstances of the deletion cutoff position indicated by the target object.

[0203] Next, the client can send a deletion request to the server carrying the first session identifier and the first message identifier, so that the server can generate a deletion instruction message for the target session. Specifically, with Figure 6 Taking the message entry shown as an example, the server can use the first message identifier as the message content of the deletion instruction message, and use the first session identifier as the session identifier field to assign a corresponding message identifier to the deletion instruction message, thereby generating the corresponding message entry.

[0204] Specifically, in some embodiments, the method further includes:

[0205] The message stream is parsed. If a deletion instruction message is found in the message stream, the session identifier corresponding to the deletion instruction message and the deletion deadline contained in the message content of the deletion instruction message are obtained.

[0206] The target session is determined based on the first session identifier, and an asynchronous deletion task is started based on the deletion deadline to perform message deletion on the target session.

[0207] In this application embodiment, in addition to indicating the deletion deadline position through message identifier, the target object can also perform the deletion task of session messages through the deletion deadline time in some embodiments.

[0208] Specifically, in this embodiment, the first message identifier in the message content of the deletion instruction message can be replaced with a time data, denoted as the deletion deadline. The deletion deadline can be used to indicate the deletion of session messages sent in the target session before the deletion deadline. Based on the deletion deadline and combined with the sending timestamps corresponding to each session message in the target session, a message deletion operation can be performed on the target session. The specific message deletion operation can be implemented using an asynchronous deletion task, and this application does not impose any restrictions on this.

[0209] Please refer to Figure 12 , Figure 12 This illustration shows a schematic diagram of filtering session messages in a target session according to an embodiment of this application, such as... Figure 12 As shown, assuming the target session with a first session identifier of 2000 has a first message identifier of 102 determined by the deletion command message, it needs to delete session messages in the target session with message identifiers of 102 or earlier. During the execution of the asynchronous deletion task, if the target object initiates an interactive operation for the target session with a session identifier of 2000 and needs to display the target session, the session messages of the target session can be filtered by the first message identifier, such as... Figure 12 As shown, assuming the current query retrieves four more session messages in the target session, with corresponding message identifiers 99, 100, 102, and 104, where message identifiers 99, 100, and 102 are less than or equal to the first message identifier, filtering can remove session messages with identifiers 99, 100, and 102, displaying only the session message with identifier 104. This achieves the same display effect as if the session message deletion task had been completed, improving message display efficiency and accuracy, and enhancing the user experience of the application's session functionality.

[0210] Reference Figure 13 In this embodiment of the application, a session message processing apparatus is also provided, which includes:

[0211] The pull unit 1310 is used to pull the message stream corresponding to the target object from the server; wherein, the message stream is used to carry the session messages of several sessions of the target object and the instruction messages for the session messages;

[0212] The parsing unit 1320 is used to parse the message stream. If it is determined that there is a deletion instruction message in the message stream, it obtains the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message. The first message identifier is used to indicate the deletion end position of the session message.

[0213] The startup unit 1330 is used to determine the target session based on the first session identifier and start an asynchronous deletion task based on the first message identifier to perform message deletion operations on the target session;

[0214] The display unit 1340 is used to respond to the interactive operation of the target object on the target session, filter the session messages in the target session according to the first message identifier, and display the filtered target session to the target object.

[0215] Optionally, in some embodiments, the message stream generation process includes the following steps:

[0216] The server receives the message corresponding to the target object and the associated information of the message; the message is either a session message or a command message, and the associated information includes the session identifier, the sending timestamp, and the message type.

[0217] The server assigns a corresponding message identifier to each message.

[0218] The server generates a message entry corresponding to the message based on the message identifier, association information, and message content.

[0219] The server adds the message entry to the message stream corresponding to the target object.

[0220] Optionally, in some embodiments, the parsing unit is specifically used for:

[0221] Parse each message entry in the message stream to determine the associated information for each message;

[0222] Based on the message type in the associated information, determine whether the message belongs to a deletion instruction message.

[0223] Optionally, in some embodiments, the startup unit is specifically used for:

[0224] Save the first session identifier and the first message identifier to a pre-established cursor table;

[0225] Establish an asynchronous message deletion thread, and retrieve the first session identifier and the first message identifier from the cursor table through the message deletion thread;

[0226] The message deletion thread queries the target session corresponding to the first session identifier and retrieves the first session message in the target session;

[0227] The message deletion thread queries the second message identifier corresponding to each first session message, and filters and deletes the first session messages based on the first message identifier and the second message identifier.

[0228] Optionally, in some embodiments, the startup unit is specifically used for:

[0229] Save the first session identifier and the first message identifier to a pre-established cursor table;

[0230] Establish an asynchronous message deletion thread, and retrieve the first session identifier and the first message identifier from the cursor table through the message deletion thread;

[0231] The message deletion thread queries the target session corresponding to the first session identifier and retrieves the second session message in the target session; wherein the second session message is a session message in the target session whose second message identifier is less than or equal to the first message identifier;

[0232] The message deletion thread handles the deletion of messages in the second session.

[0233] Optionally, in some embodiments, the startup unit is specifically used for:

[0234] Check whether all second session messages obtained in the previous batch have been deleted.

[0235] If it is determined that all second session messages obtained in the previous batch have been deleted, check whether there are still second session messages in the target session;

[0236] If there are still second session messages in the target session, retrieve several second session messages as the second session messages in the current batch.

[0237] Optionally, in some embodiments, the apparatus further includes a deletion unit, which is specifically used for:

[0238] Monitor the processing progress of the asynchronous deletion task corresponding to the current first session identifier and first message identifier;

[0239] If the asynchronous deletion task corresponding to the current first session identifier and the first message identifier is completed, delete the current first session identifier and the first message identifier from the cursor table, and return to execute the step of retrieving the first session identifier and the first message identifier from the cursor table through the message deletion thread.

[0240] Optionally, in some embodiments, the pull unit is specifically used for:

[0241] Check whether all messages in the message stream fetched in the previous batch have been processed; the messages are either session messages or command messages.

[0242] If it is determined that all messages in the message stream fetched in the previous batch have been processed, query the first message at the end of the message stream fetched in the previous batch.

[0243] In the message stream corresponding to the target object stored on the server, starting from the next message after the first message, a predetermined number of messages are retrieved as the message stream for the current batch.

[0244] Optionally, in some embodiments, the pull unit is specifically used for:

[0245] Check if a deletion instruction message exists in the message stream retrieved in the previous batch;

[0246] If there is a delete instruction message in the message stream fetched in the previous batch, check whether the first session identifier and the first message identifier corresponding to the delete instruction message fetched in the previous batch have been saved to the cursor table;

[0247] If the first session identifier and the first message identifier corresponding to the deletion instruction messages fetched in the previous batch have been saved to the cursor table, it is determined that all deletion instruction messages in the message stream fetched in the previous batch have been processed.

[0248] Optionally, in some embodiments, the apparatus further includes a generation unit, which is specifically used for:

[0249] In response to a deletion operation of a session message for the target session by the target object, obtain the first session identifier of the target session;

[0250] Based on the deletion operation, determine the deletion cutoff position indicated by the target object, and determine the first message identifier based on the session message at the deletion cutoff position;

[0251] Send a deletion request to the server carrying the first session identifier and the first message identifier, so that the server generates a deletion instruction message for the target session.

[0252] Optionally, in some embodiments, the apparatus further includes a second parsing unit, which is specifically used for:

[0253] The message stream is parsed. If a deletion instruction message is found in the message stream, the session identifier corresponding to the deletion instruction message and the deletion deadline contained in the message content of the deletion instruction message are obtained.

[0254] The target session is determined based on the first session identifier, and an asynchronous deletion task is started based on the deletion deadline to perform message deletion on the target session.

[0255] It is understandable that, such as Figure 4 The content of the session message processing method embodiments shown is applicable to the session message processing device embodiments of this invention. The specific functions implemented by the session message processing device embodiments of this invention are the same as those shown below. Figure 4 The method for processing session messages shown is the same as in the embodiment, and the beneficial effects achieved are the same as those described above. Figure 4The beneficial effects achieved by the illustrated method for processing session messages are also the same.

[0256] This application also discloses an electronic device, including:

[0257] At least one processor;

[0258] At least one memory for storing at least one program;

[0259] When at least one program is executed by at least one processor, such that at least one processor implements as Figure 4 The illustrated embodiment of the method for processing session messages.

[0260] The electronic device in the embodiments of this application may be a terminal device, a computer device, or a server device.

[0261] For example, refer to Figure 14 , Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Taking a terminal device as an example, Figure 14 In this context, the electronic device 1400 may include an RF (Radio Frequency) circuit 1410, a memory 1420 including one or more computer-readable storage media, an input unit 1430, a display unit 1440, a sensor 1450, an audio circuit 1460, a short-range wireless transmission module 1470, a processor 1480 including one or more processing cores, and a power supply 1490, among other components. Those skilled in the art will understand that... Figure 14 The device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0262] RF circuit 1410 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and hands it over to one or more processors 1480 for processing; additionally, it transmits uplink data to the base station. Typically, RF circuit 1410 includes, but is not limited to, an antenna, at least one amplifier, a tuner, one or more oscillators, a SIM card, a transceiver, a coupler, an LNA (Low Noise Amplifier), a duplexer, etc. Furthermore, RF circuit 1410 can also communicate wirelessly with networks and other devices. Wireless communication can use any communication standard or protocol, including but not limited to GSM (Global System for Mobile communication), GPRS (General Packet Radio Service), CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), LTE (Long Term Evolution), email, SMS (Short Messaging Service), etc.

[0263] Memory 1420 can be used to store software programs and modules (or units). Processor 1480 executes various functional applications and data processing by running the software programs and modules (or units) stored in memory 1420. Memory 1420 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created based on the use of electronic device 1400 (such as audio data, telephone directory, etc.). Furthermore, memory 1420 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory 1420 may also include a memory controller to provide access to memory 1420 for processor 1480 and input unit 1430. Although Figure 14 The RF circuit 1410 is shown, but it is understood that it is not a necessary component of the electronic device 1400 and can be omitted as needed without changing the nature of the invention.

[0264] The input unit 1430 can be used to receive input digital or character information, and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to object settings and function control. Specifically, the input unit 1430 may include a touch-sensitive surface 1431 and other input devices 1432. The touch-sensitive surface 1431, also known as a touch display screen or touchpad, can collect touch operations on or near the object (such as operations performed by the object using a finger, stylus, or any suitable object or accessory on or near the touch-sensitive surface 1431), and drive the corresponding connection device according to a pre-set program. Optionally, the touch-sensitive surface 1431 may include two parts: a touch detection device and a touch controller. The touch detection device detects the touch position of the object and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 1480, and can receive and execute instructions from the processor 1480. In addition, the touch-sensitive surface 1431 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. Besides the touch-sensitive surface 1431, the input unit 1430 may also include other input devices 1432. Specifically, other input devices 1432 may include, but are not limited to, one or more of the following: a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick.

[0265] Display unit 1440 can be used to display information input by an object or information provided to an object, as well as various graphical object interfaces for controlling electronic device 1400. These graphical object interfaces can be composed of graphics, text, icons, video, and any combination thereof. Display unit 1440 may include display panel 1441, optionally configured as LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), etc. Further, touch-sensitive surface 1431 may cover display panel 1441. When touch-sensitive surface 1431 detects a touch operation on or near it, it transmits the information to processor 1480 to determine the type of touch event. Subsequently, processor 1480 provides corresponding visual output on display panel 1441 according to the type of touch event. Although in Figure 14 In this embodiment, the touch-sensitive surface 1431 and the display panel 1441 are implemented as two separate components to realize input and output functions. However, in some embodiments, the touch-sensitive surface 1431 and the display panel 1441 can be integrated to realize input and output functions.

[0266] The electronic device 1400 may also include at least one sensor 1450, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 1441 according to the ambient light level, and the proximity sensor can turn off the display panel 1441 or the backlight when the electronic device 1400 is moved to the ear. As a type of motion sensor, a gravity acceleration sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometers, taps), etc. Other sensors that may be configured in the electronic device 1400, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0267] Audio circuitry 1460, speaker 1461, and microphone 1462 provide an audio interface between the device and electronic equipment 1400. Audio circuitry 1460 converts received audio data into electrical signals and transmits them to speaker 1461, where speaker 1461 converts them into sound signals for output. Conversely, microphone 1462 converts collected sound signals into electrical signals, which are then received by audio circuitry 1460, converted back into audio data, processed by processor 1480, and then transmitted via RF circuitry 1410 to another electronic device, or output to memory 1420 for further processing. Audio circuitry 1460 may also include an earphone jack to facilitate communication between external headphones and electronic equipment 1400.

[0268] The short-range wireless transmission module 1470 can be a WIFI (wireless fidelity) module, Bluetooth module, or infrared module, etc. The electronic device 1400 can transmit information with wireless transmission modules on other devices via the short-range wireless transmission module 1470.

[0269] Processor 1480 is the control center of electronic device 1400. It connects various parts of the device via various interfaces and lines, and performs various functions and processes data of electronic device 1400 by running or executing software programs or modules stored in memory 1420 and calling data stored in memory 1420, thereby providing overall control of the device. Optionally, processor 1480 may include one or more processing cores; optionally, processor 1480 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, object interface, and application programs, and the modem processor mainly handles wireless communication. It is understood that the aforementioned modem processor may also not be integrated into processor 1480.

[0270] Electronic device 1400 also includes a power supply 1490 (such as a battery) for supplying power to various components. Optionally, the power supply 1490 can be logically connected to the processor 1480 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 1490 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0271] Although not shown, the electronic device 1400 may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0272] This application also discloses a computer-readable storage medium storing a processor-executable program, which, when executed by a processor, is used to implement, for example... Figure 4 The illustrated embodiment of the method for processing session messages.

[0273] Understandable Figure 4 The content of the session message processing method embodiments shown is applicable to the embodiments of this computer-readable storage medium. The specific functions implemented by the embodiments of this computer-readable storage medium are the same as those shown in the embodiments. Figure 4 The method for processing session messages shown in the embodiment is the same, and the beneficial effects achieved are the same. Figure 4 The beneficial effects achieved by the illustrated method for processing session messages are also the same.

[0274] This application also discloses a computer program product or computer program, which includes computer instructions stored in the aforementioned computer-readable storage medium. Figure 14 The processor of the illustrated electronic device can read the computer instructions from the aforementioned computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform... Figure 4 The illustrated embodiment of the method for processing session messages.

[0275] Understandable Figure 4 The content of the session message processing method embodiments shown is applicable to this computer program product or computer program embodiment, and the specific functions implemented by this computer program product or computer program embodiment are the same as those described above. Figure 4 The method for processing session messages shown in the embodiment is the same, and the beneficial effects achieved are the same. Figure 4 The beneficial effects achieved by the illustrated method for processing session messages are also the same.

[0276] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0277] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0278] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0279] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0280] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0281] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0282] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0283] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0284] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for processing session messages, characterized in that, Applied to a client, the method includes: Retrieve message streams corresponding to the target object from the server; wherein, the message streams are used to carry session messages of several sessions of the target object and instruction messages for the session messages; The message stream is parsed. If it is determined that there is a deletion instruction message in the message stream, the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message are obtained; wherein, the first message identifier is used to indicate the deletion end position of the session message; The target session is determined based on the first session identifier, and an asynchronous deletion task is started based on the first message identifier to perform message deletion on the target session; In response to the target object's interactive operation on the target session, the session messages in the target session are filtered according to the first message identifier, and the filtered target session is displayed to the target object.

2. The method for processing session messages according to claim 1, characterized in that, The process of generating the message stream includes the following steps: The server receives a message corresponding to the target object and the associated information of the message; wherein the message is the session message or the instruction message, and the associated information includes the session identifier, the sending timestamp, and the message type corresponding to the message; The server assigns a corresponding message identifier to the message; The server generates a message entry corresponding to the message based on the message identifier, the association information, and the message content. The server adds the message entry to the message stream corresponding to the target object.

3. The method for processing session messages according to claim 2, characterized in that, The parsing of the message stream includes: Each message entry in the message stream is parsed to determine the associated information corresponding to each message; Based on the message type in the associated information, determine whether the message belongs to the deletion instruction message.

4. The method for processing session messages according to claim 1, characterized in that, The step of determining the target session based on the first session identifier and initiating an asynchronous deletion task based on the first message identifier to perform message deletion operations on the target session includes: Save the first session identifier and the first message identifier to a pre-established cursor table; An asynchronous message deletion thread is established, and the first session identifier and the first message identifier are obtained from the cursor table through the message deletion thread; The message deletion thread queries the target session corresponding to the first session identifier and retrieves the first session message in the target session; The message deletion thread queries the second message identifier corresponding to each first session message, and filters and deletes the first session messages based on the first message identifier and the second message identifier.

5. The method for processing session messages according to claim 1, characterized in that, The step of determining the target session based on the first session identifier and initiating an asynchronous deletion task based on the first message identifier to perform message deletion operations on the target session includes: Save the first session identifier and the first message identifier to a pre-established cursor table; An asynchronous message deletion thread is established, and the first session identifier and the first message identifier are obtained from the cursor table through the message deletion thread; The message deletion thread queries the target session corresponding to the first session identifier and obtains the second session message in the target session; wherein the second session message is a session message in the target session whose corresponding second message identifier is less than or equal to the first message identifier; The message deletion thread performs deletion processing on the second session message.

6. The method for processing session messages according to claim 5, characterized in that, The step of obtaining the second session message in the target session includes: Check whether all the second session messages obtained in the previous batch have been deleted. If it is determined that all the second session messages obtained in the previous batch have been deleted, check whether the second session messages still exist in the target session; If the target session still contains the second session messages, obtain several of the second session messages as the second session messages in the current batch.

7. The method for processing session messages according to any one of claims 4-6, characterized in that, The method further includes: Monitor the processing progress of the asynchronous deletion task corresponding to the current first session identifier and the first message identifier; If the asynchronous deletion task corresponding to the current first session identifier and the first message identifier is completed, delete the current first session identifier and the first message identifier from the cursor table, and return to the step of retrieving the first session identifier and the first message identifier from the cursor table through the message deletion thread.

8. The method for processing session messages according to any one of claims 4-6, characterized in that, The step of retrieving the message stream corresponding to the target object from the server includes: Check whether all messages in the message stream fetched in the previous batch have been processed; wherein, the message is the session message or the instruction message; If it is determined that all messages in the message stream retrieved in the previous batch have been processed, query the first message at the end of the message stream retrieved in the previous batch; In the message stream corresponding to the target object stored on the server, starting from the next message after the first message, a predetermined number of messages are retrieved as the message stream for the current batch.

9. The method for processing session messages according to claim 8, characterized in that, The step of detecting whether all messages in the message stream pulled in the previous batch have been processed includes: Check if the deletion instruction message exists in the message stream retrieved in the previous batch; If the deletion instruction message exists in the message stream fetched in the previous batch, check whether the first session identifier and the first message identifier corresponding to the deletion instruction message fetched in the previous batch have been saved to the cursor table; If the first session identifier and the first message identifier corresponding to the deletion instruction messages retrieved in the previous batch have been saved to the cursor table, it is determined that all deletion instruction messages in the message stream retrieved in the previous batch have been processed.

10. The method for processing session messages according to claim 1, characterized in that, The method further includes: In response to the deletion operation of the target object on the session message of the target session, the first session identifier of the target session is obtained; Based on the deletion operation, determine the deletion cutoff position indicated by the target object, and determine the first message identifier based on the session message at the deletion cutoff position; A deletion request carrying the first session identifier and the first message identifier is sent to the server, so that the server generates the deletion instruction message for the target session.

11. The method for processing session messages according to claim 1, characterized in that, The method further includes: The message stream is parsed, and if it is determined that there is a deletion instruction message in the message stream, the session identifier corresponding to the deletion instruction message and the deletion deadline contained in the message content of the deletion instruction message are obtained; The target session is determined based on the first session identifier, and an asynchronous deletion task is started according to the deletion deadline to perform message deletion on the target session.

12. A device for processing session messages, characterized in that, Applied to a client, the device includes: A retrieval unit is used to retrieve a message stream corresponding to a target object from the server; wherein the message stream is used to carry session messages of several sessions of the target object and instruction messages for the session messages; The parsing unit is used to parse the message stream. If it is determined that there is a deletion instruction message in the message stream, it obtains the first session identifier corresponding to the deletion instruction message and the first message identifier contained in the message content of the deletion instruction message; wherein, the first message identifier is used to indicate the deletion cutoff position of the session message. The initiation unit is used to determine the target session based on the first session identifier and to initiate an asynchronous deletion task based on the first message identifier to perform message deletion operations on the target session; The display unit is used to respond to the interactive operation of the target object on the target session, filter the session messages in the target session according to the first message identifier, and display the filtered target session to the target object.

13. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the session message processing method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the session message processing method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the session message processing method according to any one of claims 1 to 11.

Images