Recently, a friend asked a question: how to implement a real-time message push architecture. At that time, only a relatively general concept was mentioned, and no in-depth discussion was carried out. Coupled with the time comparison, there is no summary. Just had a rehearsal today. The details are as follows
Then the overall design is as above. Next, we analyze each piece
1, the choice of agreement
Regarding the selection of protocols, the more commonly used methods are: XMPP, MQTT, custom protocols, etc., then we will not describe the advantages and disadvantages of each protocol in detail here. Just know the ultimate purpose:
(1), the protocol is lightweight, and the encoding and decoding speed is fast;
(2), the flow consumption is small
2. Connection methods Common connection methods:
Polling, long connection, websocket and other methods also have different advantages and disadvantages, the specific purpose
(1), the connection is stable;
(2) Different network environments use different heartbeat intervals;
(3), app connection consumption balance;
3. Massive connections will use load balancing for massive connections; common methods:
Lvs/nginx does load balancing, server load balancing, and client load balancing; first of all, we should understand the domestic network environment about dns; it can be done directly through ip; by pre-buying ip or providing webservice to obtain relevant ip, etc. Way;
About load balancing:
(1) There is a single point problem with lvs load balancing: high availability can be achieved by providing a vip
(2), server load balancing: select the server with low load
(3) Client load balancing: The horse racing strategy is used to complete load balancing, and at the same time, it also solves the problem of slow cross-operator network
4. Message repetition In general, when the network is normal, the sending of messages may be in a balanced state. However, in different network environments such as 2G/3G/4G/WIFI, we may face the problem of message duplication. On this issue, the way we generally take is to convert the receipt--response to
(1) To request in the first stage: the server sends a notification to the client, and the client returns the maximum sequence number of the most recently received message after receiving the notification (bind msg to the sequence number);
(2) The server verifies the serial number to avoid message duplication;
(3), the second stage formally sends a message: send a message
5. Operation and maintenance, expansion There is no service management, operation monitoring and pre-embedded services in the above architecture (solving the dns problem)
6. Architecture Introduction The entire architecture is logically divided into four layers:
(1) Interface service: provide push service access
(2) Distribution service: It mainly completes the routing of downlink messages and uplink messages; at the same time, it provides a corresponding routing table, which mainly provides the relationship mapping between clientId, GroupId, and ServerId.
(3) Subscription information: Complete the push of the corresponding message through the different messages subscribed to
(4) Storage: To prevent the loss of messages, basically the whole architecture is like this. There are many details that have not been elaborated in detail. At the same time, there are many pitfalls in building a real-time push system. There is no detailed description and analysis here.