I am participating in the 2022 Spring Recruitment series – experience review, click here for more details.

I. Project Introduction:

Review:

  • My project is a background system that displays orders from mobile phones in real time
  • My goal was to synchronize data in real time

Ii. Project Background

In fact, data synchronization is often encountered in business. Here are some examples of common apps:

  1. For example, Didi Chuxing has a passenger terminal and a driver terminal. The status of the driver terminal needs to be synchronized to passengers in real time, so that passengers can see whether the driver has arrived at the pick-up point.
  2. For example, Meituan takeout has rider terminal and client terminal. The rider’s receiving status needs to be synchronized to the user in real time, so that the user can know whether the rider has delivered.
  3. The ordering system needs to obtain the ordering situation of users who order by scanning code in real time and process the orders of users in time.

All of these involve data synchronization between multiple terminals. How to ensure the timeliness and accuracy of data is the difficulty of the project. We also need to consider various emergencies, such as poor user network, orders cannot be updated in time, unstable data cannot be updated in time and so on.

Iii. Practice Process:

  1. Technology selection: Websocket + heartbeat packet + reconnection + polling

My project scenario is that the background needs to display orders from the mobile terminal in real time. It is no problem if we simply use Websocket, but the problem encountered in practice is that the mobile phone is disconnected from the network. If WebSocket does not send messages, WebSocket will not immediately trigger error events. As a result, the order is not updated in time, so we need to add heartbeat packets.

What is a heartbeat packet? Even if the client sends a message to the server every once in a while, the server also needs to cooperate with us. After sending the message, it needs to reply to me immediately, and then the client knows that everything is ok and sends the message again after a few seconds. This ensures that everything is normal between the two ends.

Client: Are you there? Server: in client: Are you in? Server: in client: Are you in? Server: yesCopy the code

How I asked you “Are you there?” But you haven’t replied to me for a long time, that means you have a problem. At this time, you can close websocket and reconnect. Disconnection reconnection is an important link for us. Once we find that the message has not been replied for a long time or error events are triggered, we should immediately close the WebSocket connection for reconnection. Reconnection is best to add a number of limits, such as reconnection 10 times no reaction is no longer connected. At this time, we can change the polling mode to regularly pull the data of the service.

In fact, it is not enough for the server data to rely on websocket notification alone, but the problem encountered in practice is that the server push mechanism is always blocked and abnormal, and the server cannot send the message to the client in time. Websocket + polling is needed at the same time. If one fails, the other can continue to be used, but if both fail, it really doesn’t work.

In the design process, Websocket and polling are used together. Considering performance problems, we can increase the polling interval a bit, such as 5s polling interface once, after all, the message can be sent by adding Websocket. Once we find that webSocket is out of order, we can change the polling time to be shorter like 1s update.

Due to the two ways of Websocket + polling at the same time, the timeliness of data can be improved a lot, but some people will ask, that simply use polling to make so much trouble, in fact, polling due to the existence of time interval, do not know when the server data update, Websocket allows the server to immediately notify the client of data updates.

As a final note, using polling will put pressure on the server, so if your server is not able to resist, it is best not to add webSocket stability. After all, what suits you is the best.

V. Summary and thinking:

It is really important to ensure the stability of real-time data synchronization. At the beginning of my project, only Websocket was used, which would lead to the failure of the background system to receive orders from the mobile terminal in time. In addition, order information is very important, so we need to do a good job in performance. Faced with such a problem, we can use a variety of laws to blend together, one can be broken the other can continue to use.

There are also some edge cases that need to be taken care of. Since webSocket + polling is a performance drain, these need to be removed when you leave the page, that is, close the connection and close the polling.

So my best practice is:

If the network is normal: WebSocket and heartbeat packets + 5s polling If the network is abnormal: WebSocket (for 10 reconnections) + 1s polling If the reconnection fails for 10 times, disable the webSocket and use only 1s polling. If the reconnection fails for 10 times, use 5s pollingCopy the code