Pan Tanglei, a development engineer of Tencent WXG (WeChat Business Group), graduated from Sun Yat-sen University. The content has been revised.

1. Content overview

This paper summarizes the IM messaging system architecture design of enterprise WeChat, expounds the technical difficulties and challenges brought by enterprise business to IM architecture design, and compares and analyzes the technical solutions. At the same time, some common methods of IM background development are summarized, which are applicable to IM message system.

  • Recommended reading: The Enterprise WeChat team shares another article, “Optimizing the Synchronization Update Scheme of Organizational Structure Data in the Enterprise WeChat Client”, which is also worth reading.

Learning Exchange:

  • Instant Messaging/Push Technology Development Exchange 5 Group: 215477170
  • An Introduction to Mobile IM: One Beginner Is Enough: Developing Mobile IM from scratch
  • Open source IM framework source: https://github.com/JackJiang2…

(synchronous published in this article: http://www.52im.net/thread-36.)

2

The following are the abbreviations of technical terms involved in the content of this article. The specific meanings are as follows:

  • 1) Seq: self-growing serial number, one for each message (see: “WeChat’s massive IM chat message serial number generation practice”);
  • 2) ImUnion: message interchange system, used for enterprise WeChat and WeChat messages to get through;
  • 3) Control message: control instruction, which is invisible message, is a reliable notification mechanism for reusing message channels;
  • 4) Application message: the message sent by the system application;
  • 5) API messages: messages sent by third-party applications;
  • 6) AppInfo: Each message corresponds to a unique strid, globally unique. The AppInfo of the same message is the same for all recipients.

3. Technical background

Enterprise WeChat as an office collaboration product, chat message sending and receiving is the most basic function. The stability, reliability and security of the message system are especially important.

In the process of constructing and designing the message system, there are many difficulties. And messaging systems for TOB scenarios need to support more complex business scenarios.

The specific services for TOB scenarios are:

  • 1) Message authentication: the relationship types include group relationship, colleague relationship with the enterprise, friend relationship, group enterprise relationship and circle enterprise relationship. There must be at least one relationship between the two parties to send the message.
  • 2) Return receipt message: each message needs to record the list of read and unread personnel, which involves frequent status read and write operations;
  • 3) Recall message: support 24 hours expiration of the recall action;
  • 4) Message storage: Cloud storage has a long time span and can support message storage for up to 180 days. Hundreds of TB user messages need to be optimized to reduce machine costs;
  • 5) Crowd chat: the maximum number of group can support 10,000 people, a group message is like a small DDoS attack;
  • 6) WeChat interconnection: two heterogeneous IM systems are directly connected, and reliability and consistency are especially important.

4. Overall architecture design 1: Layered architecture

As shown above, the overall architecture is layered as follows.

1) Access layer: unified entry, receiving client requests and forwarding them to the corresponding CGI layer according to the type. Clients can connect to WWProxy via long or short connections. An active client, preferentially initiates a request with a long connection. If the long connection fails, a short connection is selected to retry.

2) CGI layer: HTTP service, which receives WWProxy packets, verifies the user’s session state, unpacks the secret keys distributed by the background, and rejects the request if decryption fails. If decryption is successful, the plaintext packet body is forwarded to the corresponding SVR in the back-end logical layer.

3) Logic layer: a large number of micro-services and asynchronous processing services, using self-developed HiKit RPC framework, and using TCP short connection for communication between SVR. Perform data integration and logic processing. Communication with external systems, through HTTP protocol, including WeChat interchange, mobile phone manufacturers push platform, etc.

4) Storage layer: message storage is developed based on the LevelDB model MsgKV. SeqSVR is a serial number generator, which ensures that the monotonic increment of the distributed SEQ does not fall back. It is used for the protocol of sending and receiving messages.

5. Overall architecture design 2. Message receiving and receiving model

The enterprise WeChat message receiving and receiving model adopts the push-pull mode, which has high reliability and simple design.

Here’s a timeline diagram of the push and pull of messages:

PS: As shown in the figure above, the sender requests the backend, writes the message to the receiver’s storage, and then pushes the notification to the receiver. The receiving side received push, take the initiative to come up the background to receive the message.

Not heavy, not lost, timely reach, these three are the core indicators of the message system:

  • 1) Real-time touch: the client guarantees the real-time touch of message push by establishing a long connection with the background;
  • 2) Timely notification: if the client long connection is not available and the process is killed, use the push platform of the mobile phone manufacturer, push notification, or directly pull up the process to receive the message;
  • 3) Message reachable: in case of message flood peak, the backstage push lags behind, the client has a rotation training mechanism to guarantee the message reachable;
  • 4) Message loss prevention: In order to prevent message loss, as long as the background logical layer receives the request, it ensures that the message is written to the storage of the receiver. Failure will result in retry. If the request fails at the CGI layer, a red dot is returned to the client.
  • 5) Message scheduling: in the scenario of weak network, the client may have successfully written the request to the storage, and the packet back timeout will cause the client to retry and launch the same message, which will result in message duplication. To avoid this, each message will generate a unique AppInfo, which will be reordered by setting up an index in the background, and the same message will be returned to success directly, ensuring that only one message is stored.

6. Overall architecture design 3: message diffusion writing

There are two typical ways to distribute messages in IM:

  • 1) Diffuse reading;
  • 2) Diffuse writing.

6.1 Diffusion reading means that only one copy of each message is stored, and all members of the group chat read the same data.

Pros: Save storage capacity.

Disadvantages:

  • ① Each user needs to store the session list and pull the session message through the session ID;
  • ② The protocol of receiving messages is complex, and each session needs incremental synchronization messages, so each session needs to maintain a sequence number.

6.2 Diffusion writing means that each message is stored in multiple copies, and each group chat member has one copy in his own storage.

Advantages:

  • ① Only through a serial number can incrementally synchronize all messages, receiving message protocol is simple;
  • ② Fast reading speed, good front-end experience;
  • ③ Satisfying more business scenarios of TOB: return receipt message, cloud deletion.

The same message will appear differently from each person’s point of view. For example: return receipt message, the sender can see the read and unread list, the receiver can only see the state of whether it has been read. When a group message is deleted from the cloud, it disappears in its own message list and others are still visible.

Disadvantages: increased storage capacity.

Enterprise WeChat adopts the way of diffuse writing, and the message receiving and receiving is simple and stable. The increase of storage capacity can be solved by the solution of cold and hot separation. Cold data is stored to the cheap SATA disk, and the diffusion reading experience is slightly worse. The protocol design is also relatively complex.

The following is the protocol design for diffusion writing:

As shown in the figure above:

  • 1) There is only one separate message flow per user. Multiple copies of the same message exist in each user’s message flow;
  • 2) Each message has a seq. In the message flow of the same user, the seq is monotonically increasing;
  • 3) The client saves the largest seq in the message list, indicating that the client has owned all messages smaller than this seq. If the client is pushed and a new message arrives, the seq will be used to request incremental data from the backend, and the backend will return the message data larger than the seq.

7. System stability design 1: flexible strategy

7.1 background

Enterprise WeChat, as a chat IM tool for To B scene, is used for communication in work scenes and has a relatively obvious peak effect (as shown in the figure below).

As is shown in the figure above: working hours from 9:00 a.m. to 12:00 a.m. and from 14:00 p.m. to 18:00 p.m., are peak hours for chatting, and the amount of messages increases dramatically. The contrast between weekdays and holidays can also be marked.

High system stress during peak periods, occasional network fluctuations, or machine overloads can cause a large number of system failures. IM system requires high timeliness, so peak clipping is not possible. Then it is necessary to introduce some flexible strategies to ensure the stability and availability of the system.

The specific approach is to activate the overload protection policy: when the SVR has reached the maximum processing capacity, it indicates that it is in an overloaded state, and the service capacity will decrease sharply with the increase of the load. If the SVR is overloaded, part of the normal request is rejected to prevent the machine from being overwhelmed and still available for external service. Determining whether the SVR is in overload state through statistics of the time taken to be transferred and worker usage. Overload protection policies protect the system against avalanche effects during peak requests.

Here is the request that was rejected due to overload:

7.2 The problem caused by the overload protection strategy in the summary of the problem is that the system fails to return overload, and the front-end fails to send messages and displays red dots, which will seriously affect the product experience.

Messaging is the most basic function of an IM system, with almost 100% availability requirements, so this strategy definitely needs to be optimized.

The solution idea is: although the failure, also return to the front-end success, the backend to ensure the final success.

In order to ensure the availability of the message system, a lot of optimization has been done to avoid red dots in the front end caused by system overload failure in the peak period.

Specific strategies are as follows:

  • 1) The logical layer holds the failed request and returns the front-end success without red dots. The back-end asynchronously retries until success;
  • 2) In order to prevent the retry request from filling the queue when the system fails in a large area, it can only hold the failed request for half an hour, and the new request will directly return to the front end and fail after half an hour;
  • 3) To avoid retry exacerbating system overload, retry should be delayed exponentially;
  • 4) Complex message authentication (friend relationship, enterprise relationship, group relationship, circle relationship), time-consuming, background fluctuations are easy to cause failure. If it is not clear that the authority does not pass, then idempotent retry;
  • 5) To prevent evil requests, limit the number of concurrent requests for a single user and a single enterprise. For example, if the number of workers consumed by a single user exceeds 20%, the user’s request is simply discarded without retry.

After optimization, the fluctuation of the background is basically not perceived by the front end.

The process comparison before and after optimization is as follows:

8. System stability design 2: system decoupling

Due to the product form, the enterprise WeChat message system will rely on many external modules, or even external systems.

For example, when communicating with WeChat messages, the permission to send messages needs to be determined by imUnion, which is an external system and takes a long time to call.

Another example: the financial version of the message audit function, the need to synchronize the message to the audit module, increase RPC call.

Another example: the single chat group chat message of customer service needs to be synchronized to the CRM module and add RPC call. In order to avoid external system or external module failure, drag down the message system, resulting in increased time consumption, system decoupling is required.

Our solution: all interactions with external systems are designed to be asynchronous.

Point to Consider: How can requests that need to return results synchronously be designed to be asynchronous?

For example, group chat messages need to be authenticated by ImUnion to return results, and the front end is used to show whether the message has been sent successfully. First let the client succeed, asynchronous failure, then call back to the client to make a red dot.

If it is not the main process, the asynchronous retry is guaranteed to succeed and the main process is not affected, such as the message audit synchronization function. Then, as long as the internal system is stable, the main process of sending messages can be unaffected.

Decoupling effect drawing:

9. System stability design 3: business isolation

Enterprise WeChat has a variety of message types:

  • 1) Single chat group chat: basic chat with high priority;
  • 2) API messages: messages sent by enterprises through API interfaces have frequency limits and their priority is medium;
  • 3) Application messages: messages sent by the system application, such as announcements, have frequency limits and are in priority;
  • 4) Control messages: invisible messages. For example, if the group information changes, a control message will be sent to notify the group members, with a low priority.

Group chat is divided into three categories according to the number of people in the group:

  • 1) Ordinary group: group with less than 100 people, with high priority;
  • 2) Large groups: groups with less than 2000 people, medium in priority;
  • 3) 10,000 people: low priority.

There are many services: if not isolated, the fluctuation of one of them can bring down the entire messaging system.

Top priority: the need to ensure the stability of the core link, is the enterprise’s internal single chat and group chat of less than 100 people, because this business is the most basic, but also the most sensitive, a little problem, a huge number of complaints.

The rest of the business: Isolation from each other, reducing involvement. Isolation is carried out according to priority and importance, and the corresponding degree of concurrency is adjusted to ensure the stability of the core link as far as possible.

Renderings of decoupling and isolation:

10. To B business function design and optimization

10.1 Technical Background The upper limit of the group size of enterprise WeChat is 10000. As long as everyone in the group sends a message, the diffusion is 10000 * 10000 = 100 million calls, which is very huge.

It takes a long time to complete the delivery of 10,000 people, which affects the timeliness of the message.

10.2 Analysis of the problem Since the supergroup diffusion has a large amount of writing and a long time to spend, it is natural to think: whether the supergroup can be carried out separately to make the diffusion reading.

The following is an analysis of the difficulties of designing a supergroup into a single copy:

  • ① a super-large group, a message stream, the group members are synchronized with the message of this stream;
  • ② If the user has several large groups, multiple streams need to be synchronized, and the client needs to maintain the seq of each stream;
  • (3) The client unloads and reinstates, and does not know what message flow it has, so it needs to be stored and informed in the background;
  • ④ A new message comes to a super large group, and all group members need to be notified. If push is not reached, the client cannot perceive the new message, and it is impossible to train all message flows in rotation.

To sum up: the cost of a single copy scheme is too high.

The following will introduce our plan for ten thousand people chat spread write, do some optimization practices.

10.3 Optimization 1: Concurrency limit of ten thousand people has a large diffusion amount. In order to make the message arrive as timely as possible, multi-coroutine is used to distribute the message. But there is no limit to increasing concurrency.

In order to avoid the high frequency of messages among a group of ten thousand people and the pressure on the whole message system, message distribution takes the group ID as the dimension, which limits the distribution concurrency of a single group. The time to distribute the message to one person is 8ms, so the total time to distribute the message for 10,000 people is the time to 80s, and the concurrency ceiling is 5, so it takes 16s to complete the message distribution. The time of 16s is acceptable from the point of view of the product, and the large group is not sensitive to timeliness. At the same time, the degree of concurrency is controlled within a reasonable range.

In addition to limiting the concurrency of a single group ID, it also limits the concurrency of a total of ten thousand people. For a single machine, the number of workers in a small group is 250, and the number of workers in a crowd of 10,000 is 30.

Frequent messaging among 10,000 people, the number of workers is full, resulting in backlog in the queue:

Due to concurrency constraints, the number of calls is flattened, no requests are rising indefinitely, and the system is stable:

10.4 Optimization 2: merge and insert chats in work scenarios. Most chats are completed in small groups. Large groups are used for administrators to send notifications or bosses to send red packets.

A common rule with large groups of messages is that they suddenly become active when there are few messages at normal times. For example: the boss in the group to send a big red envelope, the group members heckling, this time will produce a large number of messages.

Message volume increases, concurrency is limited, tasks cannot be processed, and the queue naturally becomes backlogged. There may be multiple messages in a backlog that need to be distributed to group members of the same group.

At this point, these messages can be combined into a single request and written to the message store, and the throughput of the message system can be multiplied.

In daily monitoring, this scenario can be captured, and the peak can insert 20 messages at the same time, which is system-friendly.

10.5 Optimization 3: Business degradation such as group staff change, group name change, group setting change, will spread an invisible control message within the group. The group member receives this control message and requests the backend to synchronize the new data.

For example, in a group of 10,000 people, the messages are too frequent, causing harassment to the group members, and some of the group members choose to quit the group to refuse the messages. Suppose there are 1,000 people choose to quit the group. Then the amount of diffused control messages is 1000W, and when the user receives the control message and requests data from the background, it will bring additional 1000W data requests, causing huge pressure on the system.

It is necessary to control messages in small groups so that the group members can perceive changes in the group information in real time.

But in large groups: changes in the group information are not real time and are not felt by users. Therefore, combined with the business scenario, the de-escalation service is implemented to control the message in the large group can be directly discarded, not distributed, and reduce the call to the system.

11. To B service function design and optimization 2: return receipt message

11.1 Technical Background The return message is a feature often used in office scenarios to see the reading status of the message recipient.

The reading status of a return message will be modified frequently, and the number of times a group message will be modified is proportional to the number of group members. With hundreds of millions of messages every day, frequent reading and writing, and a huge amount of requests, how to ensure that the state of each message is consistent between the recipient and the recipient is a difficulty.

11.2 Implement two schemes for storing the reading state of schema messages.

Solution a:

Ideas: Using the message store, insert a new message pointing to an old message that has the latest read state. When the client receives a new message, it replaces the content display of the old message with the content of the new message to achieve the effect of displaying the reading state.

Advantages: multiplexing message channel, incremental synchronous message can be obtained to the receipt status, multiplexing notification mechanism and transceiver protocol, small front and back end transformation.

Disadvantages:

(1) Multiple messages need to be inserted if the storage is redundant and the state has changed many times; ② Both receivers and receivers need to modify the reading state (the receiver needs to mark the message as read state), and there is a problem of data consistency between the receivers and receivers. Scheme 2:

Idea: Store the read state of each message independently, and the message sender pulls the data through the message ID.

Advantage: Consistent state.

Disadvantages:

  • ① Build a reliable notification mechanism to inform the client that a message property has changed;
  • ② Synchronization protocol is complex, the client needs to know exactly which message state has changed;
  • (3) message expiration deletion, reading status data should also be automatically expired deletion.

Enterprise WeChat uses scheme 1 to achieve, simple and reliable, small changes: storage redundancy can be through LevelDB when the merge data, only retain the final state of the message can; Consistency issues are addressed below.

The above diagram shows the protocol flow (REFERID: the message ID being pointed to, SENDERID: the msgid of the message sender) :

1) Each message has a unique MSGID, which is unique within a single user and automatically generated by KV storage; 2) Receiver B has read the message, the client with msgid=b1 request to the background; 3) in the receiving party b to add a message, msgid = b2, referid = b1, pointing to the msgid = b1. And sets the message content of msgid=b2 to be read. Sgid =b1 The body of the message containing the sender’s msgid, i.e. SenderId = A1; 4) sender a, read out the message body msgid=a1, add b to the read list, save the new read list to the message body, generate a new message msgid=a2, referid=a1, append the message stream written to a; 5) The receiver C has read the same message, and follows the same logic in the message flow of C; 6) sender a, read out the message body msgid=a1, add c to the read list, save the new read list in the message body, generate a new message msgid=a3, referid=a1, append the message flow written to a. A3, >, a2, with msgid large a3 as the final state. 11.3 Optimization 1: Asynchronize the receiver to read the message, so that the client synchronous perception is successful, but the sender’s state is not necessary to synchronize. Because of the sender’s status change, the receiver is not aware of it. Then, the strategy of asynchrony can be adopted to reduce the time consuming of synchronous invocation.

Specific practices are as follows:

  • 1) Synchronized writing of the data of the recipient, so that the client can immediately perceive that the message has been read successfully;
  • 2) The data of the sender is written asynchronously to reduce synchronous requests;
  • 3) Asynchronous write through retry to ensure success, to achieve the final state consistent purpose.

11.4 Optimisation 2: Merge processing client receives a large number of messages. Instead of a single message being read and acknowledged, multiple messages are read and acknowledged together. In order to improve the processing efficiency of return receipt message, multiple messages can be combined.

As shown in the figure above:

  • 1) X>>A: X sent A message to A;
  • 2) A confirms 3 messages by merging and B confirms 3 messages by merging. It only takes two processing to mark six messages as read;
  • 3) After MQ distribution, the same sender can also be combined for processing. On the sender side, X merges two messages, Y merges two messages, and Z merges two messages, so three merges mark six messages.

The processing efficiency is greatly improved after the combined processing. The following figure is the collection of the call data during the peak hours. As you can see, the result of the optimization is a total write savings of 44%.

11.5 Read/write overwrite solves the message processing way of the sender is to read the data first, and then rewrite the write storage after modification. If there are more than one receiver, then the sender data will be written concurrently, and the problem of overwriting writes cannot be avoided.

The process is as follows:

  • 1) The read state of a message from the sender is X;
  • 2) Receiving Party A confirms that it has read, and the read state is modified to X+ A;
  • 3) Receiving Party B confirms that it has read, and the read state is modified to X+ B;
  • 4) The state of receiver A is written first, and the state of receiver B is written later. This final state is X plus b;
  • 5) The correct state is actually X+a+b.

There are only a few ways to deal with this kind of problem.

Scheme 1: Because concurrent operations are distributed, distributed locking can be adopted to ensure consistency. Apply a distributed lock before manipulating the storage. This scheme is too heavy, not suitable for this high-frequency multi-account scenario.

Scheme two: read and write with version number. The message flow of an account has only one version lock. In the scenario of frequent writing, it is easy to produce version conflict, resulting in low writing efficiency.

Scheme 3: MQ serialization. The key to avoiding overwrite problems is to play a good role in merging scenarios. Serialization of requests from the same account, even if the queue backlogs, the consolidation strategy can also improve processing efficiency.

Enterprise WeChat uses scheme 3, the same ID user request serialization processing, simple and easy to operate, less logical changes.

Design and optimization of To B service function 3: Recall message

12.1 Technical Difficulty “Recall message” is equivalent to updating the status of the original message, can it also be referred to by referid?

The return message must be referred to by the referid. You must know the msgid of the original message.

Distinguished from return receipt messages: Recall messages require modifying the message state of all recipients, not just the sender and individual recipients. Messages are written to each recipient’s message flow, and each message flow has a different MSGID. If you follow the referid method, you need to record the MSGID of all recipients.

12.2 Solution analysis: Recall message is simpler than return receipt message in that Recall message only needs to update the status of the message without knowing the content of the original message. The recipient’s message has the same AppInfo and can be pointed to through AppInfo.

Agreement process:

  • 1) A, B, C, all have the same message, appInfo =s, sendTime =t;
  • 2) A withdraws the message, then insert a withdrawn control message in A’s message flow, the message body contains {appInfo = S, sendTime = T};
  • 3) The client sync to the withdrawn control message, get the message body AppInfo and SendTime, display the original message with local AppInfo = S and SendTime = T as the withdrawn state, and delete the original message data. The reason why SendTime field is introduced is to prevent AppInfo collision, add double check;
  • 4) The receiver’s withdrawal process is the same as that of the sender, and the control message that is withdrawn is also inserted.

The scheme has obvious advantages, high reliability and simple protocol.

Logical diagram of the withdrawal message:

13. Thinking and summary

Enterprise WeChat’s IM messaging architecture is similar to WeChat’s, but presents some new challenges in the To B business scenario. The reliability, stability and security of the message system can be ensured through the optimization scheme combined with the product form and analysis strategy.

Enterprise WeChat to B business is complex, there are a lot of customized requirements, the design of the message system needs to consider the universality and expansibility, in order to support various requirements. For example, the scheme of revoking a message can be applied to updates of any attribute of the message, satisfying more scenarios.

Appendix: More Essential Articles

[1] An article about IM architecture design:

Brief Introduction to the Architecture Design of IM System, Brief Introduction to the Pits of Mobile IM Development: Architecture Design, Communication Protocol and Client, A Set of Mobile IM Architecture Design Practice Sharing for a Mass of Online Users (including detailed pictures and pictures), A Set of Original Distributed Instant Messenger (IM) System Theoretical Architecture Scheme, From Zero to Excellence: The technical architecture evolution of JD customer service instant messaging system, the architecture selection of Mogujie instant messaging /IM server development, the technical challenges and architecture evolution of Tencent QQ140 million online users PPT, the design practice of the time-sequence based massive data cold and hot grading architecture of WeChat background, WeChat technical director talk about the architecture: “How to Interpret” WeChat Technical Director Talk about Architecture: WeChat “” Fast Fission: Witness the Evolution of WeChat’s Powerful Backend Architecture from 0 to 1 (I)” “17 Years of Practice: Technical Methodologies of Tencent’s Massive Products How to Ensure the Efficiency and Real Time of the Push of Massive Group Messages in Mobile Terminal IM? Discussion on the Synchronization and Storage Scheme of Chat Messages in Modern IM System, Technical Challenges and Practice Summarization behind the 100 Billion Visits of WeChat Moments, Taking Microblog Application Scenes as an Example, Summarizing the Architectural Design Steps of Massive Social System, Behind the Brilliant Bullet Messages: Technical Practice of 100 Million IM Platform Sharing by Chief Architect of netease, Tutoring of Basic IM Development (5) : Easy to Understand, Correctly Understand and Good MQ Message Queue, WeChat Technology Sharing: Practice of Generating Massive IM Chat Message Sequence Numbers of WeChat (Algorithm Principle), WeChat Technology Sharing: WeChat mass IM chat message sequence number generated practice disaster (scheme) “the new entry: zero basis to understand the evolution of large distributed architecture history, technical principles, best practices,” “a set of high availability, easy expansion, high concurrency IM group chat, single chat architecture design practice the social software red envelope technology decryption (a) : Comprehensive decryption QQ red envelope technology plan, architecture, technical implementation, such as the social software red envelope technology decryption (2) : decryption WeChat shake red envelopes from 0 to 1, the evolvement of the technology of the social software red envelope technology decryption (3) : WeChat shake red rain behind the technical details of the social software red envelope technology decryption (4) : How does the WeChat Lucky Money system cope with high concurrency? How does the WeChat Lucky Money system realize high availability? How does the WeChat Lucky Money system realize high availability? The massive and high concurrency technology practice of Alipay red envelope, the technical decryption of red envelope of social software (8) : the comprehensive decryption of micro-blog red envelope technical scheme, the technical decryption of red envelope of social software (9) : talk about the functional logic, disaster recovery, operation and maintenance, architecture, etc., and the technical decryption of red envelope of social software (10) : HandQ client for the 2020 Spring Festival red envelope technology practice “” Social software red envelope technology decryption (11) : decryption WeChat Lucky Money random algorithm (including code implementation)” “Instant messaging beginner: read what is NGINX? Can it achieve IM load balance? “From Guerrillas to Regular Army (I) : The Evolution of the IM System Architecture of Hornet’s Nest Tourism Network” “From Guerrillas to Regular Army (II) : The Evolution and Practice Summary of the IM Client Architecture of Hornet’s Nest Tourism Network” “From Guerrillas to Regular Army (III) : Go based hornet’s honeycomb tourism network distributed IM system technology practice “IM development basic knowledge tutorial (six) : database with NoSQL or SQL? Read this article is enough! The seeds IM data architecture design of the intelligent customer service system (from the speech, form a complete set of PPT) “, “ali nailing technology sharing: enterprise IM king – nailing the backend architecture on the edge of the WeChat background based on time sequence of a new generation of mass data storage architecture design practice of the IM development basic knowledge make up a missed lesson (9) : If you want to develop an IM cluster, first understand what RPC is! “Ali technology sharing: electricity IM message platform, live in group chat, practice of technical scenarios” grade a billion users IM architecture technology dry (last) : overall architecture, service resolution, “” a set of hundred million level user IM architecture technology dry (next) : reliability, orderliness, weak network optimization” “from novice to expert: How to Design a Distributed IM System with Billion Messages

[2] Original technical articles of QQ and WeChat team: “Technical Challenges and Practice Summary Behind the 100 Billion Visits of WeChat Moments”, “Tencent Technology Share: How Tencent Decrease Bandwidth and Network Traffic (Image Compression)”, “Tencent Technology Share: How Tencent Reduce Bandwidth and Network Traffic (Audio and Video Technology), WeChat Team Share: Solution to WeChat Mobile Full-Text Retrieval Polyphonic Problem, Tencent Technology Share: Cache Monitoring and Optimization Practice for Android Mobile QQ, WeChat Team Share: “WeChat Team Share: How does WeChat on iOS prevent special characters from causing explosions and crashes?” “Tencent Technology Share: Technology Practice of Thread Dead-lock Monitoring System for Android Mobile Q”, “WeChat Team Original Share: Technology Practice of Memory Monitoring System for iOS WeChat”, “Make the Internet Founder: Technology Practice Share of the New Generation of Quic Protocol in Tencent”, “iOS Background Awakening Practice: WeChat receipts to the accounts voice remind technical summary of the tencent technology sharing: social network road to the bandwidth of the image compression technology evolution, the WeChat team sharing: video image super-resolution technology principle and application of the scene, the WeChat team sharing: WeChat real-time audio and video chat one hundred million times a day the technology behind the decryption, the QQ music team to share: Android image compression technology details (the first) “QQ music team share: Android image compression technology details (the second)” “Tencent team share: mobile QQ face recognition in the cool dazzling picture effect details” “Tencent team share: A hand in the qq chat screen images show bug tracking process to share “the WeChat team sharing: WeChat Android edition small video coding to fill the hole” WeChat phone the local data road to full text search optimization, the organization structure in enterprise WeChat client data synchronous update scheme optimization of actual combat the WeChat team disclosure: WeChat interface stuck super bug “15…” Decipher 800 million monthly QQ background service interface isolation technology, How to conduct the compatibility test of Android terminal with 889 million monthly super IM WeChat, Take mobile phone QQ as an example to explore the “light application” in mobile terminal IM, and get everything about WeChat open source mobile terminal database component WCDB in an article. “WeChat Client Team Leader Technical Interview: How to Start Monitoring and Optimization of Client Performance”, “WeChat Background Design Practice of Massive Data Hierarchical Structure Based on Time Sequence”, “WeChat Team Original Share: The Overstaffed Problem of Android WeChat and the Way of Modularization Practice”, “WeChat Background Team: WeChat Background Asynchronous Message Quue Optimization and Upgrade Practice Share, WeChat Team Original Share: WeChat Client SQLite Database Repair Practice for Failure, Tencent Original Share (I) : How to Enhance the Speed and Success Rate of Mobile QQ Image Transmission under Mobile Network How to Substantly Compress APP Traffic Consumption on Mobile Network (Part II), Tencent Original Sharing (Part III) : How to Substantly Compress APP Traffic Consumption on Mobile Network (Part I), WeChat MARS: The Network Layer Packaging Library that WeChat is Using, and Will Be Open Source soon, Coming as promised: WeChat’s self-use mobile terminal IM network layer cross-platform component library MARS has been officially open source, open source LIBCO library: a backend framework cornerstone for connecting thousands of single PCs and supporting WeChat 800 million users [source download], WeChat’s new generation communication security solution: TLS1.3 based MMTLS detail, WeChat team original share Android version WeChat background live actual combat share (process live) “WeChat team original share: Android version WeChat background live actual combat share (network live)” “Android version of WeChat from 300KB to 30MB technology evolution (PPT speech) [attachment download]” “WeChat team original share: Android version of WeChat from 300KB to 30MB technology evolution, WeChat technical director talk about architecture: WeChat road to simple (full text speech), WeChat technical director talk about architecture: WeChat road to simple (PPT speech) [download attachment], how to read “WeChat technical director talk about architecture: The Way of WeChat — The Way to Simplicity, the Backstage System Storage Structure (Video +PPT) Behind Massive WeChat Users [Download Attachment], and the Practice of WeChat Asynchronous Transformation: The background solution behind 800 million monthly life and 10 million single computer connections “, “WeChat Moments of Massive Technology PPT [Download Attachment]”, “WeChat Technology Test and Analysis on the Influence of Network (Full Paper)”, “A Summary Note on WeChat Background Technology Architecture”, “Architecture Architecture: “Fast Fission: Witness the Evolution of WeChat’s Powerful Backend Architecture from 0 to 1 (1)” “Fast Fission: Witness the Evolution of WeChat’s Powerful Backend Architecture from 0 to 1 (2)” “WeChat Team Original Share Android Memory Leak Monitoring and Optimization Tips Summarization of Android Memory Leak Monitoring and Optimization Tips Summarization of iOS WeChat Upgrade iOS9 All kinds of “Pits” WeChat Team Original Resource Confusing Tool: Make Your APK Subside by 1M Android version WeChat installation package “weight loss” actual combat record, iOS version WeChat installation package “weight loss” actual combat record, mobile terminal IM practice: iOS version WeChat interface lag monitoring scheme, technical problems behind WeChat “red packet photos”, mobile terminal IM practice: “Mobile terminal IM practice: Android version WeChat how to greatly improve the interactive performance (I)” “Mobile terminal IM practice: Android version WeChat how to greatly improve the interactive performance (II)” “Mobile terminal IM practice: Android version WeChat how to greatly improve the interactive performance (II)” Implement the Intelligent Heartbeat Mechanism of WeChat on Android, Mobile Terminal IM Practice: Heartbeat Strategy Analysis of WhatsApp, Line and WeChat, Mobile Terminal IM Practice: Research on Google Message Push Service (GCM) (from WeChat), Mobile Terminal IM Practice: Discussion on Multi-device Font Adaptation Scheme of iOS Version WeChat, Original Carrier Pigeons Team: Through the Pit of Message Push (APNS) on iOS10, Tencent Carrier Pigeons Technology Share: Practical Experience of Real-time Message Push of 10 Billion Level, IPv6 Technology Exposition: Basic Concepts, Application Status and Technical Practice (Part I), IPv6 Technology Exposition: Basic Concepts, Application Status and Technical Practice (Part I) Basic concepts, application status and technical practice (Part II), Tencent TEG team’s original: 10 years’ experience of TDSQL Forging distributed database based on MySQL, WeChat multimedia team interview: learning of audio and video development, audio and video technology and challenges of WeChat, etc., and one article about iOS news push is enough: Most complete history of iOS Push technology, rounding the tencent technology sharing: WeChat small program audio and video technology the story behind the tencent senior architects dry summary: article read all aspects of the large-scale distributed system design “, “WeChat multimedia team jun-bin liang interview: talk about what I know of the audio and video technology, the tencent audio-visual lab: Using AI Black Technology to Realize High-Definition Real-time Video Chat with Ultra Low Bit Rate, Tencent Technology Sharing: Technical Ideas and Practice of WeChat Audio and Video Interworking with WebRTC, Hand in Hand Teaching You to Read Chat Records of Android WeChat and Hand Q (Only for Technical Research and Learning), WeChat Technology Sharing: WeChat’s Massive IM Chat Message Serial Number Generation Practice (Algorithm Principle), WeChat Technology Share: WeChat’s Massive IM Chat Message Serial Number Generation Practice (Disaster Relief Plan), Tencent Technology Share: GIF Technology Details and Mobile QQ Dynamic Expression Compression Technology Practice, WeChat Team Share: Kotlin is gradually recognized, the technical taste of Android version WeChat, QQ design team share: the functional design ideas behind the new version of QQ 8.0 voice message revamp, WeChat team share: Extreme optimization, the practice summary of iOS version WeChat compiler speed 3 times improved, IM “scan” function is easy to do? See the complete technical realization of WeChat “scan recognition”, WeChat team share: Reflections on the mobile terminal software architecture brought about by the reconfiguration of WeChat payment code, IM development guide: The most complete collection of WeChat functional parameters and logical rules in history “WeChat Team Sharing: Evolution of WeChat Live Chatroom Single Room 15 Million Online Messages Architecture”

This article has been published simultaneously on the public account of “instant messaging technology circle”.



▲ The link to this article on the public number is: click here to enter. The synchronous publishing link is:http://www.52im.net/thread-36…