1. A method for synchronizing multiple terminals of instant messaging based on a timeline model is characterized by comprising the following steps: the method comprises the following steps:

the method comprises the following steps: sending, reading and caching a message synchronization library;

step two: the message synchronization library stores the message queue of each user;

step three: and amplifying and storing the message synchronization library.

2. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: the specific operation of the first step is as follows: all messages are sent to a Rabbitmq server, a message consumption program reads from a message queue, and due to the fact that group chat has the problem of write amplification, a batch insertion mode is adopted, one message in a group is written into message queues of N members in a batch mode, redundant storage of the message occurs here, message contents are stored into a redis cache space, only a message Id is inserted into redundancy in an ElasticSearch, and the space occupied by message storage is greatly reduced.

3. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: the sync vault stores a message queue for each user, and each time a message related to the user is stored in the message queue for the user, in order to implement the message queue, the stored fields include a sourceUid field identifying a message to which the message belongs, an isReaded field identifying whether the message has been read, a created timestamp identifying the message storage, an msgId identifying the ID of the message, a targetGid identifying the ID of a group message, and a targetUid identifying the ID of the other party when chatting alone.

4. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: the concrete operation of the third step is as follows: a single chat message can be inserted into a message queue of a sender and also can be inserted into a message queue of a receiver, namely, two single chat writes and amplifies are carried out, N groups of chat writes and amplifies are amplified, message content is written into a Redis cache, expiration time is set to be one month, in addition, one copy is written into a mysql database, the message can be inquired from the database after cache failure is ensured, the complete message is not required to be written when the message is stored into the message queue, only a message id is required to be recorded, and the complete message content can be inquired from Redis or msyql through the message id during inquiry.

5. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: in the process of writing and amplifying the stored messages in the third step, 2 parts of single chat and N parts of group chat are amplified, batch insertion api provided by ElasticSearch is adopted, 2 messages of the single chat are inserted in batches, and N parts of messages of the group chat are also inserted in batches, so that the message storage efficiency is greatly improved.

6. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: the message storage occasion in the step two is that when the message arrives at the client, the client has a receipt message to send to the server, and the server can confirm that the message arrives at the client when receiving the message, and the server stores the message at the moment.

7. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: the message storage mode in the step two is to send the message to a message queue Rabbitmq according to the group chat and the single chat for asynchronous message storage, that is, after the message is sent to the message queue, the message is immediately pushed to the client, at this time, the message may not be stored, and the message pushing and the message storage are performed asynchronously.

8. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: the message data storage and amplification storage mode in the third step is as follows:

single chat, queue store details:

from: sender id;

to: a recipient id;

IsReaded: whether the message has been read;

msgs: a message body;

and (4) Created: a time stamp;

MsgId: a message unique identifier id;

group chat, queue store details:

a Sender: sender id;

gid: group id;

IsReaded: whether the message has been read;

and (4) Created: a time stamp;

MsgId: a message unique identifier id;

members: group member array information;

the amplified storage, namely the single chat message, needs to store two parts, the sourceUid and the targetGid are exchanged and stored respectively, and N parts are stored in group chat.

9. The method for multi-end synchronization of instant messaging based on a timeline model as claimed in claim 1, wherein: message write amplification in step three:

the single chat message is stored in two parts:

the storage fields are:

sourceUid: id of the current message sender;

created: a timestamp of the message;

msgs: storing a message body;

targetUid: the id of the other party;

traversal registers, each traversed id as sorceUid, and the remaining fields:

gid: group id;

msgid: a message id;

created: a message timestamp;

IsReaded: whether the message has been read;

the message needs to be stored in two parts when the user is amplified, namely the message is single chatting, sourceUid and targetGid are exchanged and stored in one part respectively, and N parts are stored when the user is group chatting.

Background

Timeline is a logical model of message abstraction that helps us to simplify the understanding of the message synchronization and storage model, and the design and implementation of the message synchronization library is also expanded around the characteristics and requirements of Timeline. The Timeline model is designed for a message data scene, can meet the special requirements of the message data scene on message order preservation, mass message storage and real-time synchronization, and simultaneously supports full-text retrieval and multi-dimensional combined query. The method can be simultaneously applied to the realization of message scenes such as IM, Feed stream and the like.

The TimeLine model has very high requirements on the database, mainly including:

1) the table structure design can meet the functional requirements of the Timeline model: a relational model is not required, and a queue model can be realized;

2) the method can support high concurrent writing and range reading, and the scale is in a TPS of hundred thousand grade;

3) hundred TB-level mass data can be stored;

4) a lifecycle can be defined for the data.

At present, the timeline model for realizing IM mainly adopts tableElasticSearchtore (Ali cloud table storage)

The defects and shortcomings of the prior art are as follows:

1) the Ariiyun table storage price is expensive when the message volume is large, and the cost performance is low;

2) if a package with high price is not purchased, the performance is poor, and the phenomenon of request timeout often occurs;

3) the data is stored in a third party, and the data cannot be stored in a privatized mode.

In view of this, we propose a method for instant messaging multi-end synchronization based on a timeline model.

Disclosure of Invention

In order to make up for the defects, the invention provides an instant messaging multi-terminal synchronization method based on a timeline model.

The technical scheme of the invention is as follows:

a method for synchronizing multiple terminals of instant messaging based on a timeline model comprises the following steps:

the method comprises the following steps: sending, reading and caching a message synchronization library;

step two: the message synchronization library stores the message queue of each user;

step three: and amplifying and storing the message synchronization library.

As a preferred technical scheme, the specific operation of the step one is as follows: all messages are sent to a Rabbitmq server, a message consumption program reads from a message queue, and due to the fact that group chat has the problem of write amplification, a batch insertion mode is adopted, one message in a group is written into message queues of N members in a batch mode, redundant storage of the message occurs here, message contents are stored into a redis cache space, only a message Id is inserted into redundancy in an ElasticSearch, and the space occupied by message storage is greatly reduced.

As a preferred technical solution, the sync base stores a message queue of each user, and whenever a message related to the user is stored in the message queue of the user, in order to implement the message queue, a stored field includes sourceUid, which identifies a message to which the message belongs, isread identifies whether the message has been read, a timestamp stored in a message is identified, msgId identifies an ID of the message, targetGid identifies an ID of a group message, and targetUid identifies an ID of the other party in single chat.

As a preferred technical scheme, the specific operation of the third step is as follows: a single chat message can be inserted into a message queue of a sender and also can be inserted into a message queue of a receiver, namely, two parts of single chat writing and amplifying are performed, N parts of group chat writing and amplifying are performed, message content is written into a Redis cache, expiration time is set to be one month, and one part of the message content is written into a mysql database, so that the message can be inquired from the database after cache failure, a complete message is not required to be written when the message content is stored into the message queue, only a message id needs to be recorded, and the complete message content can be inquired from Redis or msyql through the message id during inquiry.

As a preferred technical scheme, in the process of writing and amplifying the stored messages in the third step, the single chat amplifies 2 copies, and the group chat amplifies N copies, wherein a batch insertion api provided by ElasticSearch is adopted, 2 documents of the single chat are inserted in batch, and N messages of the group chat are also inserted in batch, so that the message storage efficiency is greatly improved.

As a preferred technical solution, the message storage timing in step two is that when the message arrives at the client, the client has a receipt message to send to the server, and the server receives the message, and then can confirm that the message has arrived at the client, and the server stores the message at this time.

As a preferred technical solution, the message storage manner in the step two is to send the message to the message queue Rabbitmq according to the group chat and the single chat to perform asynchronous message storage, that is, after the message is sent to the message queue, the message is immediately pushed to the client, at this time, the message may not be stored yet, and the message pushing and the message storage are performed asynchronously.

As a preferred technical solution, the message data storage and enlarged storage mode in step three is as follows:

single chat, queue store details:

from: sender id;

to: a recipient id;

IsReaded: whether the message has been read;

msgs: a message body;

and (4) Created: a time stamp;

MsgId: a message unique identifier id;

group chat, queue store details:

a Sender: sender id;

gid: group id;

IsReaded: whether the message has been read;

and (4) Created: a time stamp;

MsgId: a message unique identifier id;

members: group member array information;

the amplified storage, namely the single chat message, needs to store two parts, the sourceUid and the targetGid are exchanged and stored respectively, and N parts are stored in group chat.

As a preferred technical solution, the message in step three is written and amplified:

the single chat message is stored in two parts:

the storage fields are:

sourceUid: id of the current message sender;

created: a timestamp of the message;

msgs: storing a message body;

targetUid: the id of the other party;

traversal registers, each traversed id as sorceUid, and the remaining fields:

gid: group id;

msgid: a message id;

created: a message timestamp;

IsReaded: whether the message has been read;

the message needs to be stored in two parts when the user is amplified, namely the message is single chatting, sourceUid and targetGid are exchanged and stored in one part respectively, and N parts are stored when the user is group chatting.

Compared with the prior art, the invention has the beneficial effects that:

the invention adopts the ElasticSearch open source free storage synchronous message, greatly saves the cost, simultaneously carries out data privatization storage, and perfectly meets the requirements of message storage and query for excellent retrieval data performance of the ElasticSearch; when the data volume is small, the data volume can be directly inserted into one index of a single machine, the performance of the ElasticSearch is enough to cope, when the data volume becomes large, the index of the ElasticSearch can be divided into slices, the slices can be distributed to different machines, parallel search is carried out to meet the performance requirement, when massive data is inserted into the index of the ElasticSearch, the data in one slice becomes large, the search performance is reduced at the moment, and the horizontal expansion cannot be carried out freely due to the cost consideration. According to the time locality of data, namely data near time is frequently accessed (namely hot data), data far time is frequently accessed (namely cold data), the data can be split into different indexes, and hot data indexes can be provided with more fragments and distributed to machines with higher performance. The cold data index is provided with fewer pieces to save storage space and is distributed to machines with ordinary performance. This can save cost to the utmost, while ensuring the vast majority of access performance.

Drawings

FIG. 1 is a schematic diagram of a storage process of the present invention;

FIG. 2 is a schematic diagram of the Timeline model of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

In the description of the present invention, it is to be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", and the like, indicate orientations and positional relationships based on those shown in the drawings, and are used only for convenience of description and simplicity of description, and do not indicate or imply that the equipment or element being referred to must have a particular orientation, be constructed and operated in a particular orientation, and thus, should not be considered as limiting the present invention.

Referring to fig. 1-2, the present invention provides a technical solution:

a method for synchronizing multiple terminals of instant messaging based on a timeline model comprises the following steps:

the method comprises the following steps: sending, reading and caching a message synchronization library;

step two: the message synchronization library stores the message queue of each user;

step three: and amplifying and storing the message synchronization library.

As a preferred embodiment of the present invention, the specific operation of step one is: all messages are sent to a Rabbitmq server, a message consumption program reads from a message queue, and due to the fact that group chat has the problem of write amplification, a batch insertion mode is adopted, one message in a group is written into message queues of N members in a batch mode, redundant storage of the message occurs here, message contents are stored into a redis cache space, only a message Id is inserted into redundancy in an ElasticSearch, and the space occupied by message storage is greatly reduced.

Preferably, the sync vault stores a message queue of each user, and each time a message related to the user is stored in the message queue of the user, in order to implement the message queue, a stored field includes sourceUid, which identifies a message to which the message belongs, isread identifies whether the message has been read, a timestamp stored in a message is identified, msgId identifies an ID of the message, targetGid identifies an ID of a group message, and targetUid identifies an ID of a party.

As a preferred preference of this embodiment, the specific operation of step three is: a single chat message can be inserted into a message queue of a sender and also can be inserted into a message queue of a receiver, namely, two parts of single chat writing and amplifying are performed, N parts of group chat writing and amplifying are performed, message content is written into a Redis cache, expiration time is set to be one month, and one part of the message content is written into a mysql database, so that the message can be inquired from the database after cache failure, a complete message is not required to be written when the message content is stored into the message queue, only a message id needs to be recorded, and the complete message content can be inquired from Redis or msyql through the message id during inquiry.

Preferably, in the write-amplification process of the stored messages in the third step, the single chat amplifies 2 copies, and the group chat amplifies N copies, where a batch insertion api provided by ElasticSearch is adopted, 2 copies of documents of the single chat are inserted in batch, and N copies of messages of the group chat are also inserted in batch, so that the message storage efficiency is greatly improved.

Preferably, in the second step, the message is stored at a moment when the message arrives at the client, the client sends a receipt message to the server, and the server receives the message and can confirm that the message arrives at the client, and the server stores the message at the moment.

Preferably, the message storage manner in the step two is to send the message to the message queue Rabbitmq according to the group chat and the single chat to perform asynchronous message storage, that is, after the message is sent to the message queue, the message is immediately pushed to the client, at this time, the message may not be stored yet, and the message pushing and the message storage are performed asynchronously.

Preferably, the message data and the enlarged message data are stored in the third step as follows:

single chat, queue store details:

from: sender id;

to: a recipient id;

IsReaded: whether the message has been read;

msgs: a message body;

and (4) Created: a time stamp;

MsgId: a message unique identifier id;

group chat, queue store details:

a Sender: sender id;

gid: group id;

IsReaded: whether the message has been read;

and (4) Created: a time stamp;

MsgId: a message unique identifier id;

members: group member array information;

the amplified storage, namely the message needs to be stored in two parts during single chat, sourceUid and targetGid (id of chat object) are exchanged, one part is stored respectively, and N parts are stored during group chat.

As a preferred technical solution, the message in step three is written and amplified:

the single chat message is stored in two parts:

the storage fields are:

sourceUid: id of the current message sender;

created: a timestamp of the message;

msgs: storing a message body;

targetUid: the id of the other party;

traversal registers, each traversed id as sorceUid, and the remaining fields:

gid: group id;

msgid: a message id;

created: a message timestamp;

IsReaded: whether the message has been read;

the message needs to be stored in two parts when the user is amplified, namely the message is single chatting, sourceUid and targetGid are exchanged and stored in one part respectively, and N parts are stored when the user is group chatting.

The foregoing shows and describes the general principles, essential features, and advantages of the invention. It will be understood by those skilled in the art that the present invention is not limited to the embodiments described above, and the preferred embodiments of the present invention are described in the above embodiments and the description, and are not intended to limit the present invention. The scope of the invention is defined by the appended claims and equivalents thereof.