[Rongyun Technology] Setting and distributing custom attributes under ultra-large-scale concurrency

1. Introduction and application scenarios of custom properties

In the new era of rapid development of mobile Internet, IM instant messaging has developed rapidly. In addition to traditional graphic chats in IM, scene applications such as online show, online education, live delivery, and game interaction are also becoming more and more extensive. Especially in the live broadcasts of some first-line anchors, tens of thousands or even hundreds of thousands of people in the live broadcast room watch at the same time, which puts forward higher requirements on the concurrent communication capabilities of IM.

As the representative of IM instant messaging and audio and video communication cloud services, Rongyun provides live chat room SDK and audio and video live SDK. When providing these basic functions, the business layer may also need to set some of its own attributes, such as the synchronization of the venue attributes in the live voice chat room scene, the host’s microphone position information, role management, etc., or the card type such as Werewolf Killing. Record the user's role and game status in the game scene. These custom attributes can enrich the entire IM business form.

In this article, I focus on how to implement the setting and distribution of these custom properties under the super-large concurrency scale with the chat room as the background.

2. Technical challenges faced by a large number of users

The biggest difference between a chat room and an ordinary IM group is that it is a virtual organization, the chat room is unbounded, and everyone can enter and leave the chat room at will; the group is more like a room, it is a bounded , A private organization with a cap. With the vigorous development of the live broadcast industry and the rapid increase in the number of people watching live broadcasts, chat rooms in live broadcast rooms are more likely to have ultra-high concurrency scenarios, such as chat rooms in live broadcast rooms for first-line anchors.

After the custom attributes are set, these attributes need to be synchronized to all ends in the chat room in time. The biggest challenge in this process is distribution. Because if there are a large number of people in the chat room, and many scene custom attributes are time-sensitive, timely synchronization of custom attributes to all ends will test the service's distribution capabilities in high concurrency scenarios.

3. Implementation of custom attribute setting and distribution under high concurrency

In the distributed system architecture, in order to unify the behavior of the chat room, we will use the consistent hash to aggregate all the signaling of the same chat room into one instance. This has certain benefits. For example, it can improve the cache hit rate of the service. For example, the black/white list setting and judgment of the chat room personnel can use the cache in the memory, and there is no need to access the third-party cache every time, thereby improving The response speed of the chat room. But the problem that this brings is that if the number of people in the chat room is too large, the distribution capacity of the chat room will be the bottleneck of the system, and once the delivery capacity of a single host reaches the upper limit, the problem cannot be solved by expansion, because no matter how the expansion is done , All the signaling of a chat room will still be aggregated into this instance.

In order to improve the distribution capabilities of the service, we have independently developed a separate set of distribution services (chat room message service), as shown in the following figure:

In this architecture system, we divide the chat room system into a chat room service and a chat room message service. The role of the chat room service is still to receive all the uplink signaling related to the chat room, such as personnel entry and exit, custom attribute settings, etc. . The chat room message service focuses more on the distribution of chat room messages and custom attributes.

After the user joins the chat room, he needs to perform a consistent hash based on the user's own ID to figure out which chat room message service they need to fall into, and then join. The users of such a chat room will be evenly distributed to the chat room messaging service. This also solves the problem that the system cannot be expanded after encountering pressure. After the custom attributes are synchronized to the chat room message service, the distribution node needs to put the attributes in the memory, and then send a notification pull signaling to the user of the current node. After the client receives the notification pull signaling Pull custom attributes.

4. Memory storage of custom attributes and quick pull from the client

When the chat room message service receives a custom attribute change request, it will save this data in the full attribute collection. This collection stores all the custom attribute collections. If this data is eliminated by LRU or the service is restarted If so, a copy of the data will be reconstructed from the third-party cache.

The full amount of data in the memory is more suitable for people who have just joined the chat room. After they join the chat room, they can directly pull the full amount of data. But if you are already in the chat room and have already pulled all the attributes, then if the chat room sets a new custom attribute or deletes a custom attribute, if the client wants to know the behavior of the custom attribute just now , You need to compare the client-side custom attributes with the server-side custom attributes. Regardless of whether the comparison behavior is placed on the server side or on the client side, it will increase a certain amount of computational pressure. In order to solve the synchronization of incremental data, we built a collection of attribute change records, as shown in the figure:

The attribute change record uses an ordered map set. The key is the change timestamp, the value stores the type of change and the content of the custom attribute, and the type of change is mainly set and delete. This ordered map provides actions for all custom attributes during this period. After the client receives the notification of the pull of the custom attribute change, it will pull it up with the timestamp of the largest local custom attribute, for example In the scenario in the figure, if the client transmits a timestamp of 6, it will pull two records with a timestamp of 7 and a timestamp of 8. After the client pulls the incremental content, it plays it back locally, and then performs related operations on its own local content.

V. Concluding remarks

The article roughly analyzes the infrastructure of Rongyun chat room and how to set and distribute custom attributes under ultra-large-scale concurrency under this architecture. With the rapid development of the Internet, the setting and application of custom attributes will become more and more extensive, and the scale of concurrency may continue to increase. At that time, our architecture will also iterate and continue to provide customers with low-latency and high-reliability services.