Previous blog I mentioned that each channel has its own leveldb cache. At the same time, a friend suggested I do not use the cache, after thinking, I still decided to use the cache. Why would I do that?
As shown above in the scene, a sender, two reciver. One of the reciver is a user who has been online, while the other reciver is a small piece of work offline for some reason. On the way channel K is the key and V is the data.
We can analyze it in 2 main cases:
Reciver is temporarily offline with Sync key.
Reciver a new channel without sync key.
For the first case:
We can quickly synchronize the user to the k:seqn-1, if sender at this time to send data, then the user with K:seqn-1 again Sync channel message when the K:SEQN will find the existence.
for the second case:
by dividing the data by the hour, it is easy to calculate the current hour interval, and we know how much data is in the hour queue. We can quickly give the last N-1 data and synchronize the user to k:seqn-1. If the user wants to look through the previous history, we can also use K:SEQ1 to forward synchronization.
So the advantage of this is that all groups of users see the message sequence is consistent, rather than the same as the QQ group, the occasional occurrence of an individual and the group of people in the message sequence is inconsistent.
Simple implementation of the model Https://github.com/DavidAlphaFox/mm_channel
Group message synchronization for IM specific design