The so-called "multi-terminal roaming" refers to the fact that users can obtain historical chat records after logging in to any device.
How to realize multi-terminal message roaming
Then let's take a look at how to make the sent and received messages roam in multiple terminals. Generally speaking, two preconditions are required to support message multi-terminal roaming:
1. It is achieved through the online status of the device dimension.
2. It is realized through offline message storage.
Online status of the device dimension
For users who log in at multiple terminals and are online at the same time, the IM server can push the message to multiple devices of the receiver after receiving the message, and also push it to other login devices of the sender.
In this case, it is required to be able to record the online status according to the user's device dimension, which is actually a prerequisite for supporting multi-terminal login.
Offline message storage
In addition, if only one device of the receiver or sender is online when the message is sent, it may be a period of time before logging in through other devices to view historical chat records. This kind of offline message multi-terminal roaming requires the message to be stored on the server. Up. When the user's offline device is online, the messages sent and received during the offline period can be obtained from the storage of the server.
"The process of sending and receiving messages when multiple terminals are online" and "The process of synchronizing messages when offline devices are online"
Several key points of offline message synchronization
For the situation where multiple terminals are online at the same time, the implementation is relatively simple, and multiple devices can be pushed simultaneously only by maintaining the online status of a set of device dimensions.
How to save offline messages?
A message stored on the server is generally divided into a message content table and a message index table. The message index table is designed according to the conversation dimension of the sender and receiver, so that it is convenient for the sender and receiver to view the chat content between the two.
So the question is: Can offline message storage directly use this message index table?
First of all, for the storage of offline messages, not only the messages need to be stored, but also the signaling of some operations. For example, user A deletes a message with user B on device 1. Although this signaling is not a message, it also needs to be stored. Store it in the offline message storage, so that when another device 2 of user A goes online, the signaling of the delete message can be obtained through the offline message storage, so that the message can be deleted locally on the device 2.
For these operation signaling, there is no concept of message ID and content-related information, and it is a one-time action, which does not need to be persisted, nor is it suitable for reusing the message index table; in addition, the message index table is the session dimension of the sender and receiver , And when obtaining offline messages, the receiver or sender’s single user dimension obtains the data. It is not necessary to store it by session, just store it by UID.
In addition, there is another point that needs to be considered. The storage cost of offline messages is relatively high, and we don’t know how many devices the user has. Therefore, the storage of offline messages is generally limited in time and number, such as retention 1. A maximum of 1,000 items are stored every week, so that if a user does not log in on a device for a long time and then goes online one day, he can only synchronize the history chat records of the last week from the offline message storage.
Multi-terminal message synchronization mechanism
Another important problem with offline message synchronization is that since we don’t know how many terminals the user will have to obtain messages offline, we will not delete these messages from offline storage after we synchronize offline messages on one terminal. It is to continue to be reserved to prevent other devices of the user from being pulled online in the future . The storage of offline messages is also under the premise of not exceeding the size limit and time limit, using the FIFO (first in first out) elimination mechanism.
In this case, the user needs to know which offline messages should be obtained when using a certain terminal to log in. Otherwise, if all offline messages are packaged and pushed down, two problems will be caused: one is a waste of traffic resources; the other may cause a lot of messages It already exists in the terminal, and all push-downs will cause repeated messages and repeated execution of signaling. Therefore, a mechanism is needed to ensure that offline messages can be pulled on demand
Solution: A common solution is to use the version number to achieve data synchronization between multiple terminals and servers. Let's briefly talk about the concept of version number.
1. Each user has his own version number sequence space.
2. Each version number is unique in the user's sequence space, generally 64 bits.
3. When there is a message or signaling that needs to be pushed to the user, a version number will be generated for each message or signaling, and stored in offline storage together with the message or signaling, and the latest version of the user maintained by the server will be updated at the same time version number.
4. After the client receives the message or signaling, it needs to update the local latest version number to the version number of the last message or signaling received.
5. When an offline user goes online, it will submit the latest local version number to the server. The server compares the user’s latest version number maintained by the server with the version number submitted by the client. If they are inconsistent, the server will follow the client’s The version number obtains messages and signaling "newer than the client version number" from offline storage, and pushes them to the currently online client.
The process of offline synchronization of messages
What should I do if the offline message storage exceeds the limit?
When users go online to get offline messages, the version numbers of the client and server will be compared first. If the version numbers are inconsistent, the "incremental messages" will be obtained from the offline message storage according to the latest version number uploaded by the client. If the offline message storage capacity exceeds the limit, some incremental messages will be eliminated, which will cause the failure to obtain incremental messages based on the latest version number of the client.
Solution: The way to deal with this situation can be: directly push down all offline messages or get some of the latest messages of recent contacts from the contact list and index table of the message, and then let the client browse according to the "time related "" message ID to get the remaining messages by page, and for repeated messages, let the client de-duplicate according to the message ID.
Because only messages are stored in the message index table, and no operation signaling is stored, this processing method may cause part of the operation signaling to be lost, but there will be no message loss. Therefore, for business scenarios with sufficient resources and high requirements for consistency, the capacity of offline message storage can be increased as much as possible to improve the hit rate of offline storage.
What happens if the offline storage write fails?
In the process of processing the message sending, the IM server may fail to write offline message storage after obtaining the version number. In this case, if the version number itself is only incremented, it will cause offline messages to be fetched It is impossible to sense that a message fails when writing to offline storage.
Because if this message fails to be written to the offline cache, and the next message succeeds again, when you take the client version number to fetch the offline message, you find that the client version number is inside, and you can still get the offline message normally. Will miss the previous one that failed. So, how to avoid this problem of unaware offline storage write failure?
Solution: A feasible solution is to store not only the current version number, but also the version number of the previous message or signaling when storing offline messages. Not only does it require the latest version number of the client to exist in the offline message storage, but also Messages that require offline storage can be connected in series through the previous version number and current version number carried in each message. Otherwise, if the offline storage write fails, the two version numbers of all messages cannot be connected in series. In this way, when a user pulls offline messages online, after the IM server finds that the user’s offline message version number is not continuous, it can use the same processing method as the offline message storage limit, from the message contact list and index Table to get some of the latest news from recent contacts.
Message package push down and compression
For users who have not been online for a long time, there are more offline messages that need to be pulled after going online. If one push down will cause the whole process to be very long, the client will see one message popping out, and the experience will be very poor.
Solution: Generally, for offline message pushdown, multiple messages will be merged into one big packet by the overall packaging method. At the same time, the merged large packet can be further compressed. By reducing the size of the packet, not only can the network transmission be reduced Time can also save users' data consumption.
Synchronization problem of the sending device
There is another issue that is easy to overlook. In the version number mechanism, we will carry the version number of each message when pushing down the message, and then update it to the latest version number of the client. The problem is that the device used by the sender to send the message does not need to push the current message anymore, and it is impossible to update the latest version number of this device through message push down. In this case, if this device goes offline and then goes online, The reported version number is still old, which will cause the IM server to misjudge and push down existing messages repeatedly.
Solution: To solve this problem, a relatively common solution is: the sender device of the message still pushes a separate message that only carries the version number, and the sender device only needs to update the local latest version number to receive the message. It is synchronized with the version number of the server.
to sum up:
Message multi-terminal roaming is a feature that needs to be supported in many instant messaging scenarios. To support message multi-terminal roaming, there are two implementation methods:
1. It is required that the online status needs to support user equipment dimension maintenance;
2. It requires that messages and signaling be stored offline in the user dimension on the server.
In addition, a "multi-terminal and server-side state synchronization mechanism" is needed to ensure the final consistency of the data. The most common solution in the industry is to use the version number mechanism to determine the difference between the client version and the server version. When users go online, they get "incremental messages and signaling". When the offline message storage misses, you can use the persistent recent contact list and index table to remedy the damage. The pushdown of offline messages can also optimize the online experience through "multiple message packaging and compression".