Swiping on Weibo is a “routine finger exercise” for many people every day. With a swipe, you can comment on hot topics and subscribe to hot news. Of course, there are also many people who are not interested in celebrities and turn to Reddit, Tieba, Hupu, Knowledge Planet or other BBS communities. As for the later 90s and 80s, the objects that were "swiped" may be the once instant, embarrassing, Tianya, and Maopu. Follow [Rongyun Global Internet Communication Cloud] to learn more
It can be said that "gathering the crowd to watch the fun" is an eternal hobby of human beings, but the way we watch the fun is not rich: either brush the BBS community, or plunge into the group chat of social software.
I don’t know if you have ever thought about it, if you combine the two into one, all communities such as Weibo and Tieba will become instant chats, and the dynamics of various bloggers and bar friends will be pushed to you in the form of group chat messages. , you can instantly reply, interact, and even make videos with these bloggers and friends. What will the situation be like?
This will be a super community, or more accurately, a "super group" with no limit on the number of people.
But this "super group" will be very difficult to achieve. The moment a programmer sees a product design, there is a risk of a nervous breakdown.
(real server stress)
"Crash" mainly stems from technical challenges, more precisely, the huge read and write pressure and storage pressure faced by the server.
There have been several well-known failures on Weibo: Zhao Liying's certificate, Guan Xiaotong's official announcement, and Wang Baoqiang's divorce. Behind the various network jokes ridiculing the collapse of Weibo, what we can see is the helpless figure of an architect who added tens of thousands of comments to a Weibo in a few seconds, and the pressure on the server skyrocketed dozens of times in an instant.
Similar to this is the distribution scene of live barrage. Whether it’s the recent Mayday New Year’s Eve concert on the video account or the Spring Festival Gala at Station B, it’s easy to get over a million barrages (the “Best Night in 2019” bilibili Gala has over 1.7 million barrages).
In theory, each barrage must be fully distributed to the audience in the live broadcast room. Taking the Mayday New Year's Eve concert as an example, 16.8 million people watched online that night. If it is conservatively assumed that 1 million bullet screens were sent that night, then the writing operation of bullet screens alone would have to be executed at least 16,800,000 x 1,000,000 times.
Because the actual support is difficult, and the user's screen cannot display tens of thousands of comments on the same screen, the forwarding of the bullet screen is generally downgraded - a small part is distributed for you to see, and the rest is skipped.
And if Weibo comments and live broadcast barrage are all "group chat", the problem will be even more terrifying. After the "group chat", the product form becomes "super group", and the problem enters the IM scene, and the corresponding flow control can be done, but the information cannot be discarded. And whether it is a Weibo comment or a live barrage, the attention to the context of the information is not high, but this is precisely the focus of IM.
It can be said that at least 3 years ago, there were not many people who could systematically solve these problems and polish them into a mature product. It was not until 2018 that a software called Discord appeared abroad that netizens experienced this new form of community.
Discord initially only served game voice connection, but it quickly evolved into a super community. In 2021, according to CNN, Discord has more than 140 million registered users, and Microsoft is in talks to buy it for $10 billion.
In an interview with npr, an 18-year-old in the Chicago area said he spent most of 2020 hanging out on Discord, describing it as a "mix of Reddit and group chat."
Metaverse supporters are also surprised to find that the so-called "Discord mode" is not the basic mode of the future metaverse virtual community? In the metaverse, you can't start a chat with a group of 500 people.
Putting aside model innovation, if we want to delve into the technical core of Discord, it is precisely the "super group" we described earlier. On January 11, 2022, Rongyun also released a PaaS product called "Super Cluster". Taking this as an example, we may be able to figure out what is this kind of sci-fi future community? how to achieve.
(Supergroup Design Architecture and Implementation)
The underlying technical support capabilities of the super group can be simply divided into two parts, namely the business capabilities of the super group and the underlying technical capabilities of IM.
The business capabilities of the super cluster are divided into four layers at the architectural design level, namely, the acceleration network, the access layer, the core service layer, and the underlying storage. The reason for this division is to make full use of Rongyun's own unified acceleration network mechanism to ensure network connectivity and connection quality, so that supergroups can concentrate on realizing more efficient network connections based on their own business needs and on the basis of connection channels. business interaction.
In Rongyun, the traditional group messaging is based on the sending and receiving model (inbox, outbox), and maintains the conversation list and historical message storage independently. From the user to send group messages, to the group (the number of members is N) to receive group messages. The whole process will generate four types of messages:
- A sender's outbox record;
- N-1 records of the recipient's inbox;
- 1 group history message record;
- N session list records.
The message storage delivery process is:
Terminal A -> send message -> access service -> group management (group message upstream) -> distribution -> group chat message distribution node -> message node -> notification pull (direct send) -> terminal B/C/ D
Under such a process, the message distribution node interacts closely with the message node and is usually deployed together. At the same time, the message node will also directly trigger the message storage of the inbox and outbox.
However, in the scenario of a super group, there is no theoretical upper limit on the number of group members. Whether it is the upstream or downstream of messages, or the writing and querying of messages in the storage layer, it will lead to unprecedented service load pressure, so the above solutions are no longer applicable. . Therefore, based on the existing connection mechanism, Rongyun optimized the interaction design for the super group, and designed two distribution models: the message-driven model and the session-driven model.
For the message-driven model, message nodes will no longer directly trigger inbox store operations.
Rongyun has specially designed a ring-shaped message queue, which completes the cache of the latest N messages through the combination of memory and external cache, and completes the fast read and write of hot data by optimizing the message storage model. For downlink messages, aggregate processing is performed to ensure that the client can handle a large number of message change notifications, and minimize the number of interactions, which also makes message pulling faster and more accurate.
The session-driven model is based on the message-driven model and further optimized.
First, the message node will no longer notify the client to pull the message, but will notify the client that the session has changed by triggering a real-time session. The real-time session here is the basis for implementing the client subscription mechanism, so that the client can only know the subscribed session change messages, thereby further reducing the number of sessions and messages that need to be processed.
Secondly, after receiving the session change notification, the client will determine whether to initiate a session message query operation according to the notification. If so, query the latest or special range of messages according to a certain mechanism.
In addition to the optimization of the message distribution level, the optimization of storage is also very critical. All services of Rongyun Super Group are distributed according to the business dimension consistent hash. For example, upstream services can be hashed by group ID or channel ID, and distribution services can be hashed by receiver ID. The core goal is to ensure the hit of hot data, giving priority to memory, LRU cache, distributed cache, and disk cold storage.
Flow control at the APP, group, and signaling levels is another guarantee. It transforms a seemingly borderless product requirement into a ponderable and achievable technical problem. Therefore, although flow control is not the focus of the supergroup implementation, it is still indispensable.
Overall, Rongyun's super cluster construction plan has four main points:
- Weakening the original outbox/inbox model, especially the inbox, to greatly improve read and write performance and avoid performance bottlenecks caused by I/O;
- Through "change notification" aggregation and other methods, try to reduce the number of interactions between the terminal and the server, and reduce the delay caused by network interaction;
- Design a dedicated data structure (ring queue), and set up multi-level cache structures such as memory and external cache to improve the speed of message distribution and storage under super-large scale, and provide fast query capabilities;
- Through the session-driven model, the amount of data to be transmitted during network interaction is further reduced.
So, with the above solutions, can a "super group" be constructed? Obviously not enough, in the supergroup scenario, the accumulation of IM's underlying technical capabilities may be more important.
(IM underlying technical capabilities and network layer performance optimization)
If you want to interpret the basic IM capabilities that Rongyun Super Group relies on, I am afraid that a mini-book cannot be finished. The rough architecture diagram is as follows:
But fortunately, with regard to supergroups, we only need to focus on their dependencies at the network level.
As with all IM services, the acceleration capability of the underlying network is key. The full name of Rongyun's underlying service network is Rongyun Global Communication Network (hereinafter referred to as SD-CAN, Software Defined - Communication Accelerate Network), which integrates BGP anycast, SD-WAN, peer-to-peer connection, dynamic CDN, smart DNS and other various Network acceleration method.
For the super cluster, SD-CAN allows the client SDK to determine the region, operator and the last mile network through query and detection, and dispatch users to the network edge node of Rongyun nearby. The edge node is based on the request target of the signaling The address is delivered to the routing node to complete the data collection, which is then identified by the routing node and forwarded to the corresponding data center.
For example, if a North American user wants to access a data center in China, the typical two paths are:
- North American users -> direct connection -> domestic data center access services -> business services;
- North American users -> anycast -> North American data center edge nodes -> North American data center routing nodes -> SD-WAN/peering connections -> domestic data center routing nodes -> domestic data center access services -> business services.
The client will perform parallel detection and establish a connection at the same time according to the policy issued by the service. The selection of the optimal link depends on information such as connection establishment delay, heartbeat interval, and link sending and receiving status. The server will also regularly check the health of the connection, actively close the long-tail connection, and combine the client's reconnection mechanism to ensure the call to the optimal link.
(PaaS products are nearly complete, or will fill the gap before the arrival of the metaverse)
In addition to technical implementation, challenges also arise at the product design level.
Due to the large amount of information in the super group, it is necessary to support dividing the group into different channels, similar to the traditional topic or channel. Even with the same group and group members, conversations, messages, and unreads can still be aggregated into categories through different channels. Users can pay more attention to the parts they are interested in and increase user stickiness.
This also reflects the real needs of users in the supergroup scenario: I may wish to establish social relationships in a supergroup with hundreds of thousands of netizens, but I don’t want to be disturbed by hundreds of thousands of messages.
In addition, for Rongyun, Super Cluster is a PaaS product, which means that there is ample customizable space for clients. In different scenarios, there are different requirements for the way, logic, and frequency of information push. At the same time, scenarios that combine information and chat generally have multiple needs. Different platforms, such as Android, iOS, Web, etc., have different technical characteristics in terms of network request and storage of massive messages, and even the push channel characteristics of different manufacturers of the same platform are different, all of which need to be considered one by one.
In recent years, there have been few new companies in the social field, and the overall growth has been on a downward trend. On the one hand, it is because the traffic is highly concentrated to the head, which squeezes the space for new players; on the other hand, because of the lack of new models, everyone is still competing around the existing users.
The new application form of super group may have a huge traction on the overall development of social software, thus bringing new opportunities. At the same time, the completion of PaaS products also marks that the technical foundation for product innovation has been consolidated, which may fill the last gap in the metaverse from WeChat and Yuchaofang at the product level.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。