Im instant messaging develops a message delivery scheme for 10000 people

In the traditional sense IM Group chat , It's usually like wechat 500 The crowd , perhaps QQ Of 2000 The crowd （QQ Yes 3000 The crowd , But that's a separate charge , This means that it is not a standard configuration without threshold , Not many people can use it ）.

 

Since a foreign country is known as “ The safest in the world IM” After ten thousand people talk , Million people were quickly accepted by domestic users . With the development of mobile Internet , Instant messaging services are widely used in various industries （ Yijing is no longer limited to tradition IM Social applications ）, With the rapid development of business , Traditional hundred people 、 Group chat with a maximum of 1000 people can no longer meet the needs of many business scenarios , Therefore, a super large group of 10000 or even 100000 people can be considered to be born together 、 Follow the trend .

IM Group chat has always been IM One of the more difficult hot technologies in application , Group chat in the usual sense , does 500 The crowd 、1000 The crowd 、2000 The crowd is like this , The technical implementation is much more complicated than a single chat . But for thousands of people （ Even a hundred thousand people chatted ） Come on , Compared with a hundred people 、 Thousands of people talk , In terms of technical implementation, it's almost another technical dimension , Much more difficult .

The technical challenges faced by super large groups

With a hundred people 、 Compared with thousands of people , ten thousand people 、 Even 100000 people, a huge group , Greatly increased the number of people touching the group , For many business scenarios , The benefits are self-evident .

However, the members of a single group are so large , to IM The flow impact of the system is very huge , The technical difficulty can be imagined . Let's first analyze the technical challenges of super large groups .

Take a model of 10000 people as an example ：

    1） If someone in the group sends a message , Then this message needs to follow 1:9999 Distribution and delivery in proportion to , If we follow the normal message processing flow , Then the message processing service is under great pressure ;

    2） In case of large message volume , The processing speed of the server directly pushing messages to the client will become the bottleneck of the system , Once the user's message is sent, the queue is squeezed , It will affect the normal message distribution , It will also lead to a surge in service cache usage ;

    3） In the microservices architecture , Services and storage （DB, cache ） Between QPS And network traffic will also increase sharply ;

    4） Group based message caching , Memory and storage overhead is high （ The storage of the message body is magnified ten thousand times ）.

Based on these technical challenges , To really achieve the technical goal of super large group , It is bound to do specific technical optimization to deal with .

Message delivery model of general group chat

Let's take a look at the message delivery model of ordinary group chat .

When the user sends a message in the ordinary group , The delivery path is ：

    1） Message first to group service ;

    2） Then the group relationship cached by the group service , Lock the target users of this message that will eventually need to be distributed ;

    3） Then distribute it to the message service according to a certain strategy ;

    4） The message service then judges that the message is a direct push according to the user's online status and message status 、 Notice whether to pull or transfer Push, Finally delivered to the target user .

Message delivery of ordinary group chat , Just as you expected , Basically, everyone's implementation means are not bad . However, for 10000 people , This is obviously not enough .

Ten thousand people chat about the optimization means of message delivery 1： Speed control

Message delivery for 10000 people , One of our main means is to control the speed .

First ： We will establish multiple group message distribution queues according to the number of cores of the server , For these queues, we set different sleep time and different number of consuming threads .

Popular speaking , The queue can be divided into fast 、 in 、 Slow waiting queue .

secondly ： We map all groups to the corresponding queue according to the number of group members .

The rule is ：

    1） Small groups are mapped to fast queues ;

    2） Large groups are mapped to the corresponding slow queue .

then ： Because of the small number of people , The impact on service is minimal , So the service uses the fast queue to quickly distribute the group messages , Large group messages use the relatively high delay time of the slow queue to control the speed . Instant messaging chat software app Development of the v：weikeyun24 consulting

 

Ten thousand people chat about the optimization means of message delivery 2： Merge

In section 3 The technical challenges faced by 10000 people mentioned in this section , The main challenge is actually the diffusion, distribution and delivery of messages , The message was cloned N strip , Message traffic is instantly amplified .

for instance ： When a group message is sent to IM After the server , It needs to be delivered from the group service to the message service , If each group member delivers once , And if the content of the delivered group message is consistent , That will certainly cause the corresponding waste of resources and service pressure .

So in this case , Our solution is to merge and deliver messages .

The principle is ： In the service placement calculation, we use the consistency hash , The falling point of group members is relatively fixed , Therefore, we can merge the group members with the same location into one request for delivery , This greatly improves the delivery efficiency and reduces the pressure of service .

One hundred thousand 、 Mega scale super large group processing scheme

In the actual group chat business , Another business scenario is a super large-scale group , The number of this group has reached hundreds of thousands or even millions .

If this group follows the above delivery scheme , It is bound to cause great pressure on the message nodes .

For example, we have a group of 100000 people , Five message nodes , The maximum number of messages that the messaging service can process is one second 4000 strip , Then each message node will be divided into 2 Ten thousand group messages , This has greatly exceeded the processing capacity of the message node .

So to avoid these problems , We will put the group members online for more than 3000 The group is identified as 10000 people 、 Supergroup , This level of group can be adjusted according to the number of servers and server configuration. For this super group, a special queue will be used to process the delivery of group messages .

This particular queue 1 The number of messages delivered by the end message service in seconds is half of the maximum processing limit of the message service （ Leave the ability to handle other messages ）, If a single message service processes QPS The upper limit is 4000, The group service delivers the most messages to a single message service in one second 2000 strip .