Message storage method, message system, computer equipment and storage medium

Abstract

The embodiment of the invention relates to a communication system, and discloses a message storage method, a message system, computer equipment and a storage medium. According to the invention, interaction data of each main body is stored in an interaction database, and the interaction data at least comprises a receiving main body ID and a sending main body ID; the interactive message content is stored in a message detail library, the interactive message sending sequence is stored in a message sequence library, the message sending sequence at least comprises a receiving main body ID, a sending main body ID and a unique message key, and the unique message key is associated with the message content; and caching the interaction data, the message content and the message sending sequence according to the message sending time. Wherein the message sequence library is associated with the interaction database through the receiving main body ID and the sending main body ID, and the message sequence library is associated with the message detail library through the unique message key. Therefore, the message can be stored at the server side, the storage space of the main body equipment is liberated, the message query request of the main body can be quickly responded, and the experience of the main body is improved.

Description

Technical Field

[0001] Embodiments of the present invention relate to a communication system, and particularly to a message storage technology in a communication system. Background Art

[0002] In existing instant messaging (IM) systems, message storage usually relies on the local storage of the main device, such as being stored in a mobile phone. Although this storage method is simple, it has significant limitations. As the user usage time increases, message data accumulates continuously, resulting in the gradual increase of the storage space of the main device, thereby affecting the device performance. In addition, the local storage method cannot meet the requirements of multi-device login and message roaming. When the main body switches between different devices, it may not be able to obtain the complete historical message records.

[0003] To solve the limitations of local storage, some systems attempt to store messages on the server side. However, server-side storage also faces many challenges. First, with the increase in the number of main bodies (i.e., the number of users) and the complexity of business forms, the server needs to process and store a large amount of message data, which brings huge pressure to the server. Second, the increase in the amount of data will lead to a slowdown in the message reading speed, affecting the user experience. For example, in a high-concurrency scenario, the server may not be able to respond to the main body's message query request in time due to high load, resulting in a long waiting time for the main body. Summary of the Invention

[0004] Embodiments of the present invention aim to provide a message storage method, a message system, a computer device, and a storage medium, such that messages can not only be stored on the server side to free up the storage space of the main device, but also can quickly respond to the main body's message query request and improve the main body's experience.

[0005] To solve the above technical problems, embodiments of the present invention provide a message storage method, including: Storing the interaction data of each main body in an interaction database, where the interaction data at least includes a receiving main body ID and a sending main body ID; storing the message content of the interaction in a message details library, and storing the message sending order of the interaction in a message order library, the message sending order at least includes a receiving main body ID, a sending main body ID, and a message unique key, and the message unique key is associated with the message content; caching the interaction data, the message content, and the message sending order according to the message sending time; wherein, the message order library is associated with the interaction database through the receiving main body ID and the sending main body ID, and the message order library is associated with the message details library through the message unique key.

[0006] An embodiment of the present invention also provides a message system, including: a storage module, a cache module, an interaction database, a message details library, and a message sequence library; the storage module is used to store the interaction data of each subject in the interaction database, store the message content of the interaction in the message details library, and store the message sending sequence of the interaction in the message sequence library; wherein, the interaction data at least includes a receiving subject ID and a sending subject ID, the message sending sequence at least includes a receiving subject ID, a sending subject ID, and a message unique key, and the message unique key is associated with the message content; the cache module is used to cache the interaction data, the message content, and the message sending sequence according to the message sending time; wherein, the message sequence library is associated with the interaction database through the receiving subject ID and the sending subject ID, and the message sequence library is associated with the message details library through the message unique key.

[0007] An embodiment of the present invention also provides a computer device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the above-mentioned message storage method.

[0008] An embodiment of the present invention also provides a computer-readable storage medium storing a computer program, which implements the above-mentioned message storage method when executed by a processor.

[0009] In the embodiment of the present invention, by storing messages on the server side instead of relying on the local storage of the subject device, the subject device does not need to store a large amount of message data, thus releasing valuable storage space and avoiding device performance problems caused by insufficient storage space. Moreover, the subject can log in to the account on different devices and obtain the complete historical message records without worrying about message loss or incompleteness. Furthermore, separating the storage of the message content, the message sending sequence, and the interaction data, associating the interaction data with the message sending sequences of both parties of the interaction, and then associating the specific message content based on the message unique key from the message sending sequence makes the storage structure clearer and avoids waste of storage resources caused by repeated storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a flowchart of a message storage method according to an embodiment of the present invention; Figure 2 is a flowchart for reading unread messages in a message storage method according to an embodiment of the present invention; Figure 3 is a schematic structural diagram of a message system according to an embodiment of the present invention; Figure 4 is a schematic structural diagram of a computer device according to an embodiment of the present invention. Detailed implementation manners

[0011] In a traditional instant messaging system, message data is usually stored on a main device (such as a mobile phone). Although this method is simple, as the message data accumulates continuously, the storage space of the main device will gradually increase, thereby affecting the device performance. For example, after long-term use, the storage space of the mobile phone may be occupied by a large number of chat records, resulting in slow device operation or even freezing. Although server-side storage solves the limitations of local storage, the server needs to process and store a huge amount of message data, which will also cause the message reading speed to slow down. Especially in high-concurrency scenarios, the server may not be able to respond to the message query requests of the main body in time due to high load, thus affecting the main body experience.

[0012] To solve the above technical problems, the embodiments of the present application provide a message storage method in a message system, which can be applied to a server. The method includes: storing the interaction data of each main body in an interaction database, where the interaction data at least includes a receiving main body ID and a sending main body ID; storing the message content of the interaction in a message details library, and storing the message sending order of the interaction in a message order library, where the message sending order at least includes a receiving main body ID, a sending main body ID, and a message unique key, and the message unique key is associated with the message content; caching the interaction data, the message content, and the message sending order according to the message sending time; wherein, the message order library is associated with the interaction database through the receiving main body ID and the sending main body ID, and the message order library is associated with the message details library through the message unique key. This enables the main device not to store a large amount of message data, avoiding device performance problems caused by insufficient storage space. Moreover, the main body can log in to the account on different devices and obtain the complete historical message records without worrying about message loss or incompleteness. In addition, through the caching mechanism, the system can quickly respond to the query requests of the main body without reading data from the database every time, thereby significantly improving the query efficiency, especially suitable for high-concurrency scenarios, and effectively improving the main body experience.

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will elaborate on each embodiment of the present invention with reference to the accompanying drawings. However, those of ordinary skill in the art can understand that in each embodiment of the present invention, many technical details are provided to help readers better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions required to be protected by the present application can still be implemented. The following division of each embodiment is for convenience of description and should not constitute any limitation on the specific implementation manner of the present invention. Each embodiment can be combined and cross-referenced with each other without conflict.

[0014] The following combines Figure 1A message storage method according to an embodiment of the present invention will be described. As Figure 1 shown, in step 101, the server stores the interaction data of each subject in the interaction database, and the interaction data includes at least the receiving subject ID and the sending subject ID.

[0015] In an instant messaging system, each subject has a unique ID. An interaction (i.e., a chat box where two subjects chat) can be uniquely confirmed by the receiving subject ID + the sending subject ID, that is, the chat box of the two is unique. However, it is also necessary to distinguish between the sender and the receiver because the data seen by the two subjects in the message list may be different. For example, the unread count is different. It is possible that subject A has viewed all the data, while subject B has only viewed part of the data. Therefore, when the server stores the interaction data in real time, it can store a piece of data from the perspectives of the two subjects of each interaction to distinguish the information seen by both parties. That is, for an interaction between subject A and subject B, it is necessary to store an interaction data with subject A as the sender and subject B as the receiver, and at the same time store an interaction data with subject B as the sender and subject A as the receiver.

[0016] In step 102, the server stores the message content of the interaction in the message details library, and stores the message sending order of the interaction in the message order library. The message sending order includes at least the receiving subject ID, the sending subject ID, and the message unique key, and the message unique key is associated with the message content.

[0017] In step 103, the interaction data, the message content, and the message sending order are cached according to the message sending time. For example, according to the message sending time, the latest multiple pieces of interaction data, the message content, and the message sending order are cached.

[0018] It should be noted that steps 101 to 103 can all be real-time operations. Once new interaction data of a subject appears, the interaction database, the message details library, and the message order library are synchronously updated. At the same time, the cached interaction data, the message content, and the message sending order also need to be updated. The message order library is associated with the interaction database through the receiving subject ID and the sending subject ID, and the message order library is associated with the message details library through the message unique key. Separating the storage of the message content, the message sending order, and the interaction data, associating the message sending order of both parties of the interaction through the interaction data, and then associating the specific message content based on the message unique key from the message sending order makes the storage structure clearer and avoids waste of storage resources caused by repeated storage.

[0019] Since the interaction data of each entity is stored on the server side in real time, one piece of data is stored for each interaction from the perspectives of the two entities respectively, which is used to distinguish the information seen by both parties (such as unread count, read time, etc.). At the same time, the message content and the message sending order (including the receiving entity ID, the sending entity ID, and the unique identifier of the message) are also stored in real time, so that when querying, the communication messages between the two parties of the interaction can be queried through this interaction data first, and then the message content can be quickly queried based on the unique identifier of the message. At the same time, according to the sending time of the message, the latest multiple pieces of interaction data, message content, and message sending order are cached. Through the caching mechanism, the system can quickly respond to the query requests of entities without reading data from the database every time, thus significantly improving the query efficiency. It is especially suitable for high-concurrency scenarios and can effectively improve the entity experience. By storing one piece of data for each interaction from the perspectives of the two entities respectively, the accuracy of the information seen by each entity is effectively ensured, and the message content and sending order are stored only once, avoiding repeated storage of the message content in the interaction records of each entity, thereby reducing data redundancy, making the storage structure clearer, and avoiding waste of storage resources caused by repeated storage.

[0020] The following specifically describes the above-mentioned steps. The following content is only implementation details provided for easy understanding and is not necessary for implementing this solution.

[0021] In the step of storing the interaction data of each entity in the interaction database on the server side, the interaction data of each entity is stored in real time in the interaction data table on the server side in a sharded database and sharded table manner. The interaction data table at least includes: receiving entity ID, sending entity ID, latest update time, and message unread count, as shown in Table 1: Table 1

[0022] Of course, it can be understood that the interaction data table may also include other important fields, such as: interaction status, number of sent messages, read time, etc., which are not listed one by one here. In addition, in the instant messaging system, there may also be some special scenarios, such as pinning (set to be pinned and need to be displayed first), folding (put into the fold and not displayed by default), or classification results according to business logic (such as mutual follow, one-way follow, unfollow), etc. Therefore, the interaction data may also include data for indicating special scenarios. For example, a new category field can be added to the interaction data table for distinction, such as adding fields such as whether the sender follows the receiver, whether the receiver follows the sender, whether it is pinned, and the pinning time. Or, a new table can also be considered for distinction, which is not limited in this embodiment.

[0023] In addition, to optimize storage and query performance, database and table partitioning can also be performed based on the recipient ID or the sender ID. In one example, database partitioning can be performed according to the value at the first predetermined position in the recipient ID or the sender ID, and table partitioning can be performed according to the values at the second and third predetermined positions in the recipient ID or the sender ID.

[0024] The following is an illustration with the third digit from the right of the recipient ID as the basis for database partitioning and the last two digits of the recipient ID as the basis for table partitioning: Taking the recipient ID as 12345 as an example, since the database and table partitioning strategy is as follows: The third digit from the right (for database partitioning): used to determine which database to store in. The last two digits (for table partitioning): used to determine which table to store in. Then, assuming the database number starts from 0 and the table number starts from 0, the interaction data of this recipient ID will be stored in database: db_3, and the interaction data table: table_45.

[0025] In the above example, the system can support 10 databases (db_0 to db_9), and each database supports 100 tables (table_00 to table_99), enabling the system to disperse the interaction data of each subject and store it in 9 databases and a total of 999 tables, avoiding the problem of single-point overload, improving the overall performance and stability of the system, and being applicable to large-scale user scenarios. Moreover, the database and table partitioning strategy based on the subject ID (such as the third digit from the right for database partitioning and the last two digits for table partitioning) has a certain degree of randomness, and this randomness can ensure the uniform distribution of data among different databases and tables. Compared with other database and table partitioning strategies based on business logic, the digital randomness strategy in this embodiment is easier to implement and maintain.

[0026] Those skilled in the art can understand that in other examples, database and table partitioning can also be performed based on the sender ID, or based on the values at other positions in the ID, or other strategies for database and table partitioning, which will not be elaborated here one by one.

[0027] To relieve the pressure on the database and improve the response speed of the system, in this embodiment, a caching mechanism is also introduced to cache the latest multiple pieces of interaction data according to the time of message sending. The cache design starts from the most frequently accessed business dimension, which is mainly interaction data. The characteristics of interaction data are ordered data + including the details of each interaction (time, recipient ID, unread count...). Therefore, the recipient ID and sender ID in the interaction data can be cached through the first data storage structure, and the most recent update time and / or unread message count in the interaction data can be cached through the second data storage structure. Among them, the first data storage structure stores the recipient ID in the interaction data table through the primary key, stores the sender ID in the interaction data table through the member, and each member is associated with a score for storing the most recent update time in the interaction data table; the first data storage structure is sorted in reverse order by the most recent update time of the interaction and has a length less than a preset value; the second data storage structure stores the recipient ID through the primary key, stores the sender ID through the field, and stores the most recent update time and / or unread message count through the value of the field.

[0028] In one example, the first data storage structure adopts the ordered set type ZSet in the redis cache structure, and the second data storage structure adopts the hash type Hash in the redis cache structure. The Key of ZSet is used to store the recipient ID (recv_uid) in the interaction data table, the Member of ZSet is used to store the sender ID (send_uid) in the interaction data table, the Score of ZSet is used to store the most recent update time in the interaction data table, and is sorted in reverse order by the most recent update time of the interaction, and the length of ZSet is less than a preset value. The Key of the hash type is used to store the recipient ID, the field of the hash type is used to store the sender ID, and the value of the hash type is used to store interaction details, such as the most recent update time and / or unread message count and other data. After the interaction data is updated, the cached data in ZSet and Hash needs to be synchronously updated.

[0029] Those skilled in the art can understand that ZSet (ordered set), as a data structure, combines the characteristics of set and sorted. Its set characteristic is reflected in that the members in the set are unique and will not repeat. Its sorting characteristic is reflected in that each member has a score associated with it, and the members will be automatically sorted according to the score value. Therefore, the order of the list can be ensured through ZSet. The key is prefix+recv_uid, where prefix is a prefix that can be used to distinguish different data types or business scenarios. The member is send_uid, that is, the sender ID. The score is the latest message sending time, and finally it is sorted in reverse order according to the sending time. Hash is used to ensure that the cached data is sufficient. The key is prefix+recv_uid, the field is send_uid, and the value is the specific interaction details, which can be in json format.

[0030] To avoid excessive amount of cached data, it can be considered to only limit the length of the zset and perform truncation processing when it exceeds a certain value. When the data requested by the subject cannot be found in the cached data, go back to the database to query and update the cache. That is to say, if querying through the cache, it needs to be queried twice. The first time, the sorted result (sender ID) is obtained in the cached ZSet structure data in order. The second time, according to the result of the first time, the interaction details information is retrieved in the cached Hash structure data. Since there are various types of sequential queries and some may have duplicate interaction details, specifically using hash to store the interaction details can reduce the storage space.

[0031] In terms of business functions, the message storage architecture of the instant messaging system is divided into a general part and a special part. The general part is essential for each instant messaging system, such as ordered interactive data and ordered message data. The special part refers to special scenarios that can be customized according to the website, such as pinned messages, follow pages, and stranger pages. For the above special scenarios in the instant messaging system, such as pinning (messages set to be pinned need to be displayed first), folding (put into the fold and not displayed by default), or classification results according to business logic (such as mutual follow, one-way follow, unfollow), dedicated first data storage structures such as Zset data can be maintained for different special scenarios. For example, for the case of mutual follow, a dedicated Zset data is maintained to cache all receiving entity IDs, sending entity IDs, and the most recent update time in this mutual follow scenario. When querying entity data belonging to special scenarios, the corresponding Zset cache data can be queried first to improve query efficiency. Considering that the interaction details in special scenarios are repetitive with those in ordinary scenarios, the special scenarios and ordinary scenarios can share the same second data storage structure such as Hash. By adding fields to the interaction data table or introducing a new table and combining with Redis cache structures (ZSet and Hash), support for special scenarios such as pinning, folding, and classification according to business logic is achieved, which not only ensures the flexibility of data storage but also improves the system performance and user experience.

[0032] In one example, in the steps of storing the content of the interactive messages in the message details library and storing the sending order of the interactive messages in the message order library, the content of each message between the two parties of the interaction is stored in the message details table on the server side in a sharded and partitioned manner, and the sending order of the messages between the two parties of the interaction is stored in the message order list on the server side in a sharded and partitioned manner. Among them, the message details table at least includes: the message content and the message unique key; the message order list at least includes the receiving entity ID, the sending entity ID, the message unique key, and the most recent update time, where the message unique key is used to uniquely identify the message and is associated with time. As shown in Table 2 for the message details table and Table 3 for the message order list, the status in Table 2 can be used to indicate whether the message is sendable. For example, when the value is 1, it means sendable, and when the value is 2, it means not sendable. Of course, Table 2 and Table 3 can also include other fields, which will not be elaborated here.

[0033] Table 2 (Message Details Table)

[0034] Table 3 (Message Order List)

[0035] That is to say, through two lists (message details table and message sequence list), the message details (i.e., the specific message content) and the message sending order between every two entities are maintained respectively. The message details table and the message sequence list are associated through a message unique key. The message unique key (msg_key) needs to be globally unique and associated with time. For example, some bits in the message unique key are generated based on the message sending time, some bits are generated based on the physical device ID that sends and / or receives the message, and a random number can also be combined to ensure its global uniqueness. In one example, the Snowflake algorithm can be used to construct it to ensure its uniqueness and time correlation.

[0036] It can be understood that when storing, since the message unique key msg_key is time-related, the message details table can be sharded by database and table according to time. For example, one database per year and one table per month to optimize storage and query efficiency. Similar to the interactive data table, as long as the sender and receiver confirm, the message sequence list is unique. Therefore, the message sequence list can be sharded by database and table according to the receiving entity ID or the sending entity ID to support efficient query. The specific database and table sharding rules of the message sequence list can be the same as or similar to those of the interactive data table, which will not be elaborated here.

[0037] To relieve the database pressure and achieve a fast response for entity message query, the message content and the message sending order also need to be cached according to the message sending time. For example, cache the message content in the third data storage structure and cache the message sending order in the first data storage structure. Among them, the third data storage structure stores the message unique key in the message details table through the primary key and stores the message content in the message details table through the value of the key; the first data storage structure stores the receiving entity ID and the sending entity ID in the message sequence list through the primary key, stores the message unique key in the message sequence list through the member, and each member is associated with a score for storing the most recent update time in the message sequence list.

[0038] In one example, the message content and the message sending order are cached using a Redis cache structure. The Redis cache structure includes: a key-value pair (KV) structure and a ZSet structure. The KV structure is used to store data in the message details table. Specifically, the Key of the KV structure is used to store the unique message key in the message details table, and the Value of the KV structure is used to store the message content in the message details table, which can be stored in JSON format. The ZSet structure is used to store data in the message order list. Specifically, the Key of the ZSet structure is used to store the recipient ID and the sender ID in the message order list, the Member of the ZSet is used to store the unique message key in the message order list, and the Score of the ZSet is used to store the most recent update time in the message order list. It can be understood that after the message content and the message sending order are updated, the data in the KV used to store the message details and the data in the ZSet used to store the message sending order also need to be updated synchronously.

[0039] When responding to the query request of the response body, first query in the cached interaction data, message content, and message sending order. If the requested data cannot be found, then query in the interaction data table, message order list, and message details table. The amount of cached data can also be adjusted according to the actual situation. For example, the query frequency of the database can be monitored. If the query frequency is too high, then increase the amount of cached data to relieve the pressure on the database and ensure a quick response. If the query frequency is too low, then reduce the amount of cached data to release the cache resources and reduce costs. Or, the amount of cached data can also be dynamically adjusted based on system performance metrics such as response time. By dynamically adjusting the amount of cached data based on the system load and the query requirements of the body, performance can be optimized, resource utilization can be improved, and at the same time, the body experience can be enhanced.

[0040] In one example, this embodiment further includes: in response to the query request of the target body, using the ID of the target body as the recipient ID, and querying for each sender ID that interacts with the recipient ID in the cached interaction data; where, in the case where the cached interaction data cannot be queried, query in the interaction database; according to the combination of each queried sender ID and the ID of the target body respectively, query for the unique message key corresponding to the combination in the cached message sending order; where, in the case where the cached message sending order cannot be queried, query in the message order database; query for the message content identified by the corresponding unique message key in the cached message content; where, in the case where the cached message content cannot be queried, query in the message details database.

[0041] For ease of understanding, an example is given below for illustration: When the target entity with ID number 55555 sends a query request, the server queries for each member with Key 55555 (i.e., the ID of each sending entity that interacts with 55555) in the ZSet used for caching interaction data. If each member with Key 55555 can be found in the ZSet, it then queries for the interaction details of each interaction, such as the most recent update time and / or the number of unread messages, etc., in the Hash used for caching interaction data. If each member with Key 55555 cannot be found in the ZSet, it then returns to the interaction database to query for the ID of each sending entity that interacts with 55555, and the interaction details of each interaction.

[0042] Based on the combination of the ID of each query - obtained sending entity and the ID of the target entity, the server queries for the unique message keys corresponding to each combination in the ZSet used for caching the message sending order. For example, if the IDs of the sending entities that interact with 55555 are 12345 and 12356 respectively, then in the ZSet, 55555 and 12345 are used as one Key to query for the corresponding unique message key, and 55555 and 12356 are used as another Key to query for the corresponding unique message key. Similarly, if the query fails in the ZSet, it then returns to the message order database to query.

[0043] Based on all the unique message keys of the interaction between 55555 and 12345 obtained from the query, it queries for the message content corresponding to each unique message key in the KV used for caching message content. Based on all the unique message keys of the interaction between 55555 and 12356 obtained from the query, it queries for the message content corresponding to each unique message key in the KV used for caching message content. Similarly, if the query fails in the KV, it then returns to the message details database to query.

[0044] In this embodiment, by storing messages on the server - side and combining with the caching mechanism, the following comprehensive advantages are achieved: Free up the storage space of the main device: The main device does not need to store a large amount of message data, avoiding problems such as insufficient storage space and performance degradation.

[0045] Multi - device support: The main entity can log in to the account on different devices and obtain the complete historical message records, meeting the requirements of multi - device login and message roaming.

[0046] Fast response: By caching the latest interaction data, message content, and message sending order, the system can quickly respond to the message query requests of the main entity, and can maintain high - efficient reading performance even in high - concurrency scenarios.

[0047] In some embodiments, it not only involves the storage of the above-mentioned ordinary messages, but also involves the storage of interactive notification messages in a communication system. For the subject, an interactive notification is a specific notification one by one. Each notification can be understood as a card, including entity information and interactive information. For example, a certain video of a subject with 10 comments can be a card, with video information + 10 comment counts. Clicking in shows 10 comments, or it can be 10 cards, directly showing the video + comment information. The business characteristics of interactive notifications include but are not limited to: (1) A large amount of business data: Taking a community as an example, data in various scenarios need to enter the interactive notification to notify the subject, including comments, likes, @, favorites, coin tosses, bullet screens, etc.; (2) Low latency requirements: It is required to be pushed to the subject as fast as possible without much latency; (3) No repeated sending: The same interactive operation cannot be sent multiple times; (4) Special query tabs: Some special scenarios require special situations such as pinning and following interactive notifications; (5) Special data aggregation. Some data needs to be aggregated. For example, for comments under a video, it is hoped that only one piece of data is shown, and clicking in shows multiple specific comment information.

[0048] There are multiple different demand scenarios for interactive notifications to query data, and corresponding data structures need to be constructed for these scenarios. Therefore, in this embodiment, the interactive notification messages are cached according to different demand scenarios, respectively, with a preset data storage structure corresponding to the demand scenario, such as a redis cache structure. Among them, the demand scenarios include general scenarios, pinning scenarios, and following scenarios. The data storage structure corresponding to the general scenario is a key-value pair type, the data storage structure corresponding to the pinning scenario is an ordered set type; the data storage structure corresponding to the following scenario is a custom structure, and the custom structure includes: a first key-value pair for loading on the subject side, a second key-value pair for deleting on the subject side, a third key-value pair for judging duplicates when writing, a fourth key-value pair for canceling the following relationship, and a fifth key-value pair for associating new and old cards.

[0049] In one example, the general scenario can include the following four types: (1) Loading the interactive notification list on the subject side: The subject needs to load the interactive notification list from its own perspective. The notification list can be divided by business type, and the query conditions are the subject ID and business type. The cached redis data structure is KV: The key is used to store the subject ID (uid) + business type (type) + card update time (ts), and the value is used to store the card details, including information such as card ID and content. When pulling, use the SCAN command of Redis to pull n notification cards within a specified time range according to uid + type.

[0050] (2)Subject-side Deletion of Interaction Notifications: The subject needs to delete a certain interaction notification, and the query conditions are the card ID and business type. The cached Redis data structure is KV: the key is used to store the card ID + business type (type), and the value is used to store the subject ID (uid) + business type (type) + card update time (ts). Quickly find the corresponding key through the card ID and business type, and then directly delete it.

[0051] (3)Judgment of Duplication during Writing: When writing a notification, it is necessary to determine whether the same business-unique information already exists, such as video ID + interactors, etc. The cached Redis data structure is KV: the key is used to store the business-unique information (such as video id + interactors) + business type (type), and the value is used to store the subject ID + business type (type) + card update time (ts). When writing, query the cached data through the business-unique information to determine whether the same key already exists. If it exists, skip the writing; if it does not exist, create a new key.

[0052] (4)Writing Historical Aggregation Cards: If it is necessary to aggregate interaction notification messages by business information (such as aggregating by video), then it is necessary to query historical aggregation cards when writing. The cached Redis data structure is KV: the key is used to store the business aggregation information (such as video ID) + business type (type), and the value is used to store the subject ID + business type (type) + card update time (ts). When writing, query the cached data according to the business aggregation information (such as video ID). If there is a historical aggregation card, update the aggregation card; if not, create a new aggregation card.

[0053] In addition to the above general scenarios, in actual applications, there are also some special scenarios, such as the top - pinning scenario and the following scenario. Special scenarios require additional data structures and logics to support the priority display of top - pinned cards and the secondary screening function of followed cards.

[0054] In one example, for the top - pinned scenario, the user can set certain notification cards to the top - pinned state. These cards will be preferentially displayed at the top of the notification list until the user cancels the top - pinning or the card becomes invalid. The top - pinned cards need to be maintained separately to ensure that they are preferentially displayed during normal data loading and do not appear repeatedly in the normal notification list. The Redis data structure for caching is a ZSet: the key is used to store the user ID (uid), the member is the card ID, and the score is the update time of the card. Each time the user top - pins a card, the card ID and the update time are stored in the ZSet. When querying, first pull all the top - pinned card IDs through the ZSet. After pulling all the top - pinned card IDs, pull the detailed data based on the card IDs and then return. When returning normal data, the already top - pinned data needs to be excluded.

[0055] The follow - up scenario can be understood as the user performing a follow - up operation on certain specific notification cards. These cards may be fan operations, interactions of people the user follows, etc. Depending on the specific business logic, after meeting the custom conditions, data needs to be written to the follow - up tab. The follow - up cards are a subset of the normal cards and are used to meet specific business requirements (such as secondary screening), that is, a secondary screening list for meeting business needs. Therefore, in addition to constructing the keys required for the normal query scenario, a key dimension for the follow - up state also needs to be constructed. Because if the follow - up is cancelled, the card needs to be deleted, and it also needs to be associated with the old card. Since the two cards are logically the same card, when one is deleted, the other also needs to be deleted simultaneously. The follow - up cards need to support the following operations: writing follow - up cards, deleting follow - up cards, when cancelling the follow - up, deleting the associated normal card, and maintaining the association relationship between the old and new cards. Therefore, the Redis cache structure corresponding to the follow - up scenario is a custom structure, which includes: the first key - value pair for loading on the user side, the second key - value pair for deleting on the user side, the third key - value pair for judging duplicates when writing, the fourth key - value pair for cancelling the follow - up relationship, and the fifth key - value pair for associating the old and new cards.

[0056] The specific structure settings are as follows: First, three KV structures similar to the above - mentioned general scenarios need to be set, which are: (1) For loading on the user side: the key is used to store the user ID (uid) + business type (type) + card update time (ts), and the value is used to store the card details; (2) For deleting on the user side: the key is used to store the card ID + business type (type), and the value is used to store the user ID (uid) + business type (type) + card update time (ts); (3)It is necessary to judge whether there is a repetition during writing: The key is used to store the unique business information (such as video id + interactive person) + business type (type), and the value is used to store the subject ID + business type (type) + card update time (ts).

[0057] In addition, two special KV structures need to be maintained, which are respectively: For unfollowing, it is required that: the key is used to store the subject ID + followed object ID + card ID, and the value is used to store the specific card information. The query condition is the subject ID + followed object ID. Using the scan command, all followed card information is pulled through the subject ID + followed object ID and then deleted.

[0058] For the association between the old and new cards, it is required that: the key is used to store the old card ID (old_id) + new card ID + business type (type), and the value is empty. Since it is not known how the old card is associated with the new card, this key needs to be maintained to ensure logical consistency. The new card contains the data of the old card, so no additional maintenance is required.

[0059] For the pinning scenario, the pinned cards are stored using ZSet. Using the subject ID as the key, the card ID as the member, and the update time as the score. When loading notifications, the pinned cards are preferentially displayed, and the pinned cards are excluded from the normal notifications. For the following scenario, not only the three KV structures that are the same as those in the general scenario, namely the requirements for loading on the subject side, deleting on the subject side, and judging whether there is a repetition during writing, are set, but also two special keys are maintained: one is for the unfollowing operation of the following relationship, and the other is for the association between the old and new cards, to support the association operations during writing, deleting, and unfollowing. Utilizing the flexible data structures of redis, it efficiently supports the pinning and following functions, while meeting the complex requirements of the business and being suitable for the vast majority of interactive notification scenarios.

[0060] In some embodiments, it not only involves the storage of the above-mentioned ordinary messages, but also involves the storage of the full-station notification messages in the communication system. The characteristic of the full-station notification is that all the data seen by everyone in the whole station is the same, so the data only needs to be stored once. However, the progress seen by each subject is different, that is, the unread count is different. Therefore, each subject needs to maintain a separate copy of the data, and it is required that the data of the full-station notification has a time-related cursor field. Then, for each subject, a viewing cursor for the full-station notification is stored, which is used to indicate which full-station notification the subject is currently viewing. By virtue of this viewing cursor, the specific viewing progress of the subject can be known, and then the unread count can be known. Therefore, in this embodiment, the full-station notification data is stored in the full-station notification data table, and the full-station notification data table at least includes: the notification content, and the cursor generated based on the time stamp. The viewing progress of each subject for the full-station notification data is stored in the subject viewing cursor table, and the subject viewing cursor table at least includes: the subject ID and the position of the read cursor.

[0061] In one example, when the amount of full-station notification data is not too large, such as less than a preset threshold, it can be directly stored in a single table in the database. The core fields of the full-station notification data table can include: content, which is used to store the specific content of the notification; cursor, which stores the unique identifier generated according to the time stamp and is used to record the order of the notifications; status, which is used to support the background management of the notifications, such as deletion, recall, etc.; purpose, which stores the unified content of the full-station notification. Of course, the full-station notification data table can also include other fields, which will not be listed one by one here.

[0062] For the business characteristics of less change and more query of the full-station notification data, in some examples, it is also possible to consider caching the full-station notification data to cope with high-concurrency reading and reduce the database pressure. Specifically, the following caching strategies can be adopted: in the case of a small amount of data, use a timed task (Job) to load the full amount of notification data into the local cache; in the case of normal data volume: use a distributed cache, such as adopting the Zset cache structure of Redis, where the key is a fixed value, the member is the detailed content, and the score is the cursor. Each time, directly query according to the cursor that the subject needs to view.

[0063] In the subject viewing cursor table, since each subject has one piece of data, if the number of subjects is large, database sharding and table partitioning can be performed according to the subject ID. For example, use the third-to-last digit of the subject ID as the basis for database sharding, and use the last two digits of the subject ID as the basis for table partitioning, so that the system can store the viewing progress of each subject separately in 9 databases and a total of 999 tables, avoiding the problem of single-point overload, improving the overall performance and stability of the system, being applicable to large-scale subject scenarios, and this randomness can ensure the uniform distribution of data among different databases and tables, which is easy to implement and maintain.

[0064] To reduce the database pressure, the following caching strategy is also adopted for the main body view cursor table: use the KV structure to cache part of the data in the main body view cursor table, where the key is used to store the main body ID and the Value is used to store the read cursor position of the main body.

[0065] The reading process of the site-wide notifications for a single main body is as Figure 2 shown: Read the read cursor position of the main body. Specifically, first try to read the read cursor position of the target main body from the cached main body view cursor data (as shown in step 201); if the data of the target main body exists in the cache, directly obtain the read cursor position of the target main body from the cache. If the data of the target main body does not exist in the cache, then go back to the database and query through the main body view cursor table to obtain the cursor of the last read site-wide notification of the target main body (see steps 202 and 203). That is to say, whether reading from the cache or the database, ultimately ensure that the read cursor position of the target main body is obtained. Then, obtain the latest cursor number from the site-wide notification table, that is, the total number of all current site-wide notifications (see step 204). If the cursor number in the site-wide notification table is greater than the read cursor position of the target main body, it means that the target main body has unread site-wide notifications. If there are unread site-wide notifications for the target main body, return all the unread site-wide notifications of the target main body to the target main body, default that the target main body has read these notifications, and update the read cursor position of the target main body to the latest cursor number in the site-wide notification table. The update of the read cursor position of the target main body includes the update in the cached data and the update of the main body view cursor table in the database (see steps 205 and 206). The purpose of updating the read cursor position is to mark all unread site-wide notifications as "read", which not only enables the main body to quickly obtain unread notifications, but also ensures the accuracy of the unread count and improves the main body experience.

[0066] By only maintaining the site-wide notification data and the main body view cursor data, redundant data storage can be effectively avoided, and the reading speed can be increased by adding multiple caches to handle high-traffic concurrent operations, especially meeting the requirements of small and medium-sized systems.

[0067] The step division of the above method is only for clear description. When implementing, it can be combined into one step or some steps can be split into multiple steps. As long as the same logical relationship is included, it is within the protection scope of this patent; adding insignificant modifications or introducing insignificant designs to the algorithm or process, but not changing the core design of its algorithm and process are all within the protection scope of this patent.

[0068] In addition, the examples mentioned in the above embodiments can be freely combined, and any combination can be understood as an embodiment. The "embodiment" or "example" mentioned at various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art can understand that the embodiments described herein can be combined with other embodiments.

[0069] Another embodiment of the present invention relates to a message system, as Figure 3 shown, including: a storage module, a cache module, an interaction database, a message details database, and a message sequence database.

[0070] The storage module is used to store the interaction data of each entity in the interaction database, store the message content of the interaction in the message details database, and store the message sending order of the interaction in the message sequence database; wherein, the interaction data at least includes a receiving entity ID and a sending entity ID, the message sending order at least includes a receiving entity ID, a sending entity ID, and a message unique key, and the message unique key is associated with the message content; The cache module is used to cache the interaction data, the message content, and the message sending order according to the message sending time; Among them, the message sequence database is associated with the interaction database through the receiving entity ID and the sending entity ID, and the message sequence database is associated with the message details database through the message unique key.

[0071] In an example, the interaction data of each entity is stored in the interaction data table in a sub-database and sub-table manner. The interaction data table at least includes: a receiving entity ID, a sending entity ID, a most recent update time, and the number of unread messages; and / or, the content of each message between the two parties of the interaction is stored in the message details table in a sub-database and sub-table manner, and the message sending order between the two parties of the interaction is stored in the message sequence list in a sub-database and sub-table manner; wherein, the message details table at least includes: the message content and the message unique key; the message sequence list at least includes a receiving entity ID, a sending entity ID, a message unique key, and a most recent update time; wherein, the message unique key is used to uniquely identify the message and is associated with the time.

[0072] It can be understood that the interaction data table can be sub-database and sub-table divided according to the receiving entity ID or the sending entity ID, the message details table can be sub-database and sub-table divided according to the time, and the message sequence list can be sub-database and sub-table divided according to the receiving entity ID or the sending entity ID.

[0073] In one example, the receiving entity ID and the sending entity ID in the interaction data are cached through a first data storage structure, and the most recent update time and / or the unread message count in the interaction data are cached through a second data storage structure. Among them, the first data storage structure stores the receiving entity ID in the interaction data table through the primary key, stores the sending entity ID in the interaction data table through the member, and each member is associated with a score for storing the most recent update time in the interaction data table; the first data storage structure is sorted in reverse order by the most recent update time of the interaction and has a length less than a preset value; the second data storage structure stores the receiving entity ID through the primary key, stores the sending entity ID through the field, and stores the most recent update time and / or the unread message count through the value of the field. The message content is cached through a third data storage structure, and the message sending order is cached through the first data storage structure. Among them, the third data storage structure stores the message unique key in the message details table through the primary key and stores the message content in the message details table through the value of the key; the first data storage structure stores the receiving entity ID and the sending entity ID in the message order list through the primary key, stores the message unique key in the message order list through the member, and each member is associated with a score for storing the most recent update time in the message order list.

[0074] In some examples, the message system further includes: a query module, which, in response to a query request of a target entity, uses the ID of the target entity as the receiving entity ID to query each sending entity ID that interacts with the receiving entity ID in the cached interaction data; among them, in the case where it cannot be queried in the cached interaction data, it queries in the interaction database; according to the combination of each query obtained sending entity ID and the ID of the target entity, it queries the message unique key corresponding to each combination in the cached message sending order; among them, in the case where it cannot be queried in the cached message sending order, it queries in the message order database; it queries the message content identified by the corresponding message unique key in the cached message content; among them, in the case where it cannot be queried in the cached message content, it queries in the message details database.

[0075] In some examples, the caching module is further configured to cache the interactive notification messages in data storage structures corresponding to different demand scenarios respectively according to preset rules; where the demand scenarios include a general scenario, a top - pinned scenario, and a followed scenario. The data storage structure corresponding to the general scenario is of the key - value pair type, the data storage structure corresponding to the top - pinned scenario is of the ordered set type; the data storage structure corresponding to the followed scenario is a custom structure, and the custom structure includes: a first key - value pair for loading on the entity side, a second key - value pair for deleting on the entity side, a third key - value pair for judging duplication during writing, a fourth key - value pair for canceling the following relationship, and a fifth key - value pair for associating new and old cards.

[0076] In some examples, the storage module is also used to store the global notification data in the global notification data table, and store the viewing progress of each entity on the global notification data in the entity viewing cursor table. Among them, the global notification data table at least includes: notification content, and a cursor generated based on the timestamp; the entity viewing cursor table at least includes: entity ID and the position of the read cursor.

[0077] By storing the messages on the server side instead of relying on the local storage of the entity device, the entity device does not need to store a large amount of message data, thus freeing up valuable storage space and avoiding device performance problems caused by insufficient storage space. Moreover, the entity can log in to the account on different devices and obtain the complete historical message records without worrying about message loss or incompleteness. Furthermore, by storing the message content, message sending order and interaction data separately, associating the interaction data with the message sending order of both parties of the interaction, and then associating with the specific message content based on the message unique key, the storage structure is clearer, avoiding waste of storage resources caused by repeated storage.

[0078] It is not difficult to find that this embodiment is a device embodiment corresponding to the above method embodiment, and this embodiment can be implemented in cooperation with the above method embodiment. The relevant technical details mentioned in the above method embodiment are still valid in this embodiment. To avoid repetition, they will not be elaborated here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied in the above method embodiment.

[0079] It is worth mentioning that each module involved in this embodiment is a logical module. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, to highlight the innovative part of the present invention, units that are not closely related to solving the technical problems proposed by the present invention are not introduced in this embodiment, but this does not mean that there are no other units in this embodiment.

[0080] Another embodiment of the present invention relates to a computer device, as Figure 4 shown, including at least one processor 401; and, a memory 402 communicatively connected to the at least one processor; wherein, the memory 402 stores instructions executable by the at least one processor 401, and the instructions are executed by the at least one processor 401 to enable the at least one processor 401 to execute the message storage method as described above.

[0081] Among them, the memory and the processor are connected in a bus manner. The bus can include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and the memory together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are well known in the art, so they will not be further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be an element or multiple elements, such as multiple receivers and transmitters, and provides a unit for communicating with various other devices on the transmission medium. The data processed by the processor is transmitted on the wireless medium through the antenna. Further, the antenna also receives data and transmits the data to the processor.

[0082] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. The memory can be used to store the data used by the processor when executing operations.

[0083] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When the computer program is executed by the processor, the above method embodiment is implemented.

[0084] That is, those skilled in the art can understand that all or part of the steps in implementing the above method embodiments can be completed by instructing relevant hardware through a program. The program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs, etc., which can store program codes.

[0085] Those of ordinary skill in the art can understand that the above embodiments are specific embodiments for implementing the present invention, and in practical applications, various changes can be made in form and details without departing from the spirit and scope of the present invention.

Claims

1. A message storage method, characterized in that Including: Storing the interaction data of each entity in an interaction database, where the interaction data at least includes a receiving entity ID and a sending entity ID; Storing the content of the interaction message in a message details database, and storing the message sending order of the interaction in a message order database, where the message sending order at least includes the receiving entity ID, the sending entity ID, and a message unique key, and the message unique key is associated with the message content; Caching the interaction data, the message content, and the message sending order according to the time when the message is sent; Wherein, the message order database is associated with the interaction database through the receiving entity ID and the sending entity ID, and the message order database is associated with the message details database through the message unique key.

2. The message storage method according to claim 1, wherein The storing the interaction data of each entity in an interaction database includes: Storing the interaction data of each entity in an interaction data table in a sub-database and sub-table manner, where the interaction data table at least includes: a receiving entity ID, a sending entity ID, a most recent update time, and an unread message count; And / or, the storing the content of the interaction message in a message details database and storing the message sending order of the interaction in a message order database on the server side includes: Storing the content of each message of both parties of the interaction in a message details table in a sub-database and sub-table manner, and storing the message sending order of both parties of the interaction in a message order list in a sub-database and sub-table manner; wherein, the message details table at least includes: the message content and the message unique key; the message order list at least includes the receiving entity ID, the sending entity ID, the message unique key, and a most recent update time; Wherein, the message unique key is used to uniquely identify the message and is associated with the time.

3. The message storage method according to claim 2, wherein The interaction data table is sub-database and sub-table divided according to the receiving entity ID or the sending entity ID; And / or, the message details table is sub-database and sub-table divided according to the time, and the message order list is sub-database and sub-table divided according to the receiving entity ID or the sending entity ID.

4. The message storage method according to claim 3, wherein In the case where the interaction data table is sub-database and sub-table divided according to the receiving entity ID or the sending entity ID, the sub-database and sub-table division of the interaction data table includes: Sub-database dividing according to the value at a first predetermined position in the receiving entity ID or the sending entity ID; Sub-table dividing according to the values at a second predetermined position and a third predetermined position in the receiving entity ID or the sending entity ID.

5. The message storage method according to claim 2, wherein The step of caching the interaction data includes: Caching the receiving entity ID and the sending entity ID in the interaction data in a first data storage structure, Caching the most recent update time and / or the unread message count in the interaction data in a second data storage structure; Wherein, the first data storage structure stores the receiving entity ID in the interaction data table through a primary key, stores the sending entity ID in the interaction data table through a member, and each member is associated with a score for storing the most recent update time in the interaction data table; the first data storage structure is sorted in reverse order according to the most recent update time of the interaction, and the length is less than a preset value; The second data storage structure stores the receiving subject ID through a primary key, stores the sending subject ID through a field, and stores the most recent update time and / or the message unread count through a field value.

6. The message storage method according to claim 2, characterized in that, The cache of the message content and the message sending order includes: caching the message content in a third data storage structure; Cache the message sending order in a first data storage structure; Wherein, the third data storage structure stores the unique key of the message in the message details table through the primary key, and stores the message content in the message details table through the value of the key; The first data storage structure stores the receiving subject ID and the sending subject ID in the message sequence list through a primary key, stores the message unique key in the message sequence list through members, and each member is associated with a score for storing the most recent update time in the message sequence list.

7. The message storage method according to any one of claims 1 to 6, characterized in that, The method further comprises: In response to a query request from a target subject, the target subject ID is used as a receiving subject ID, and the IDs of the sending subjects that interact with the receiving subject ID are queried in the cached interaction data; wherein, if the IDs cannot be found in the cached interaction data, the interaction database is queried; According to the combination of each sending subject ID and the target subject ID, query the message unique key corresponding to the combination in the cached message sending sequence; wherein, if the message cannot be found in the cached message sending sequence, query the message sequence library; The message content identified by the corresponding message unique key is searched in the cached message content; wherein, if the message content cannot be found in the cached message content, the message details library is searched.

8. The message storage method according to any one of claims 1 to 6, characterized in that The method further comprises: The interactive notification messages are cached according to different demand scenarios using preset data storage structures corresponding to the demand scenarios; The demand scenarios include general scenarios, top scenarios and focus scenarios; The data storage structure corresponding to the general scenario is a key-value pair type, and the data storage structure corresponding to the top scenario is an ordered set type; the data storage structure corresponding to the focus scenario is a custom structure, and the custom structure includes: a first key-value pair for loading on the subject side, a second key-value pair for deleting on the subject side, a third key-value pair for judging duplication when writing, a fourth key-value pair for canceling the focus relationship, and a fifth key-value pair for associating new and old cards.

9. The message storage method according to any one of claims 1 to 6, characterized in that The method further comprises: The whole-station notification data is stored in a whole-station notification data table, wherein the whole-station notification data table at least includes: notification content and a cursor generated based on a timestamp; The viewing progress of each subject on the whole-site notification data is stored in a subject viewing cursor table, and the subject viewing cursor table at least includes: a subject ID and a read cursor position.

10. The message storage method according to claim 9, wherein The subject views the cursor table and divides the database and table into sub-libraries according to the subject ID.

11. A message system, characterized in that, include: Storage module, cache module, interaction database, message detail library and message sequence library; The storage module is used to store the interaction data of each entity in the interaction database, store the message content of the interaction in the message details library, and store the message sending order of the interaction in the message order library; wherein, the interaction data at least includes the receiving entity ID and the sending entity ID, the message sending order at least includes the receiving entity ID, the sending entity ID and the message unique key, and the message unique key is associated with the message content; The cache module is used to cache the interaction data, the message content and the message sending order according to the message sending time; Wherein, the message order library is associated with the interaction database through the receiving entity ID and the sending entity ID, and the message order library is associated with the message details library through the message unique key.

12. A computer device, characterized in that, At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the message storage method according to any one of claims 1 to 11.

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

Images