Whenever I send a WeChat message, I hope that the other party will see it as soon as possible and reply as soon as possible, but I still don't know whether the other party has read it or not. Whenever I receive a WeChat message that cannot be replied immediately, I will return silently, pretending not to see it. WeChat is used for personal social networking, product design, online status, and mandatory read receipts may expose personal privacy, so WeChat has no related functions. DingTalk is used for business communication, and its "mandatory read receipt" function makes it impossible for people in the workplace to "pretend not to be online" or "pretend not to have received it". What's more, DingTalk's group has a "mandatory read receipt" function. When you send a message in the group, you can know who has read the message and who has not.
What is the process of the group message, how does the receiver ensure that the group message is received, how does the sender receive the read receipt, and whether to pull or push are the issues to be discussed today.
1. Group message delivery process and reachability guarantee
Core question 1: Only one copy of group messages? Or, one copy for each member?
Answer : Save a copy and set up a group message queue for each member. There will be a lot of data redundancy, which is not suitable.
Core question 2: If there is only one copy of group messages, how do you know which messages each member has read?
Answer : You can use the partial order relationship of group messages to record the last_ack_msgid (last_ack_time) of each member. The message before this message has been read, and the message after this message has not been read. This solution means that for each user in the group, only one value needs to be recorded.
After answering the above two core questions, it is easy to get the core data structure of the group message .
Group message table : record group messages.
group_msgs(msgid, gid, sender_uid, time, content); The meaning of each field is: message ID, group ID, sender UID, sending time, sending content.
Group member table : record the members in the group, and the last group message received by each member.
group_users(gid, uid, last_ack_msgid); The meaning of each field is: group ID, group member UID, and the last group message ID received by group members.
After the core data structure is designed, let's take a look at the process of sending group messages .
Business scene:
(1) There are four members A, uid1, uid2, uid3 in a group;
(2) A, uid1, uid2 are online and expect to receive online messages in real time;
(3) uid3 is offline, expecting to fetch offline messages in the future;
The entire message sending process 1-4 is shown in the figure above:
(1) A sends a group message;
(2) After the server receives the message, it first needs to send the group message to the ground, and second, it needs to check which group members are in the group so as to implement the push;
(3) For group members, query the online status;
(4) For online group members, implement push;
In this process, as long as the second step of the message landing is completed, it can be guaranteed that the group message will not be lost.
Core question 3: How to ensure that the receiver will receive the group message?
Answer : After receiving the message, each member should modify the last_ack_msgid of each group member to tell the system that this message has been confirmed received.
The modification of last_ack_msgid of online messages and offline messages is different.
For online group friends , after receiving group messages, they will ack immediately and modify last_ack_msgid.
For offline group friends , all unread group offline messages will be fetched at the next login, and last_ack_msgid will be changed to the latest message.
Core question 4: If the ack is lost, will the group members pull duplicate group messages?
Answer : Yes, deduplication can be done locally on the client side based on msgid . Even if duplicate messages are received at the system level, a good user experience can still be guaranteed.
The above process can only ensure that the receiver receives the message. The sender still does not know who has read the message online and who has not read the message offline. The read receipt has not been implemented. What kind of read receipt will have on the system design? What about the impact?
2. Read receipt process
For any group message sent by the sender, it is necessary to know how many people have read the message and how many people have not read it. A basic table is needed to record this relationship .
Message receipt table : used to record the read receipt of the message.
msg_acks(sender_uid, msgid, recv_uid, gid, if_ack); The meanings of each field are: sender UID, message ID, return receipt party UID, group ID, receipt mark.
After adding the read receipt logic, the flow of group messages will be slightly changed.
Step 2, after the server receives the message, in addition to:
Land the group message;
Query which group members are in the group in order to implement push;
In addition, you need:
-
Insert the initial receipt status for each message;
The procedure for the receiver to modify last_ack_msgid will become:
(1) Send an ack request;
(2) Modify last_ack_msgid, and modify the read receipt if_ack status;
(3) Query the online status of the sender;
(4) Push the read receipt to the sender in real time (if the sender is online);
If the sender is offline, ta will log in next time:
(5) Pull the read receipt of each message from the association table.
The preliminary conclusions here are:
If the sender is online , the read receipt will be pushed in real time;
If the sender is not online , the read receipt will be pulled the next time it is online ;
3. Process optimization plan
Under the detailed analysis again, the "message storm diffusion coefficient" of the group message read receipt assumes that each group has 200 users, and 20% of the users are online, that is, 40 users are online. Every time a group user sends a group message, there will be:
40 messages to be notified to group friends;
40 acks modify last_ack_msgid and send to the server;
40 read receipts, notified to the sender;
It can be seen that its news storm diffusion coefficient is very large .
At the same time: need to store 40 ack records;
As the number of groups, group friends, and group messages increase, storage will also become a problem.
Is there an optimization plan?
Can the push of group messages be changed to polling and pulling by the receiver?
Answer : No, message reception and real-time performance are the core indicators.
For the modification of last_ack_msgid, is it really necessary to ack each group message?
Answer : In fact, it is not necessary. You can ack in batches , receive N group messages (for example, 10) in total, and then send a last_ack_msgid modification request to the server, and at the same time modify the read receipts of all requests before this request, so that 40 The amount of ack requests sent to the server is reduced to 1/10 of the original.
What are the side effects?
Answer : The function of last_ack_msgid is to record a group message recently fetched by the receiver. If it is not updated in real time, it may cause some group messages to fail to update last_ack_msgid when an abnormal exit occurs, so that the next time you log in, you will get duplicate messages. group message. But this is not a problem, the client can deduplicate according to msgid, and the user experience will not be affected.
When the sender is online, does it really need real-time push for sending the read receipt?
Answer : Actually, it is not necessary. The sender will receive 40 read receipts for each message sent. Using polling (for example, once a minute, 60 requests per hour) can greatly reduce the amount of requests.
What are the side effects?
Answer : The read receipt is not updated in real time. In the worst case, the receipt is updated within 1 minute. Of course, this polling time can be configured as a compromise based on performance and product experience.
How to reduce data volume?
Answer: Receipt data is not core data;
-
Read messages can be physically deleted instead of marked for deletion;
-
Receipts longer than N, archive or delete ;
Four. Summary
For group message read receipts, generally speaking:
If the sender is online, the read receipt will be pushed in real time;
If the sender is not online, the read receipt will be pulled the next time it is online;
If you want to optimize for , you can:
The receiver receives N group messages in total and then batch acks;
The sender polls to pull the read receipt;
Physically delete read receipt data, regularly delete or archive non-core historical data.
---------------------
Reposted from: WeChat public account "The Road to Architects"