Timyang Sina Weibo Conference share notes

About the first version

If a user with 10 million fans publishes a message, the user needs to save 10 million copies of the message, that is, the message needs to be stored once for each fan;

I personally think the advantages and disadvantages:

Advantages:

Stores a message for each user, which is easy to implement and facilitates rapid development;

Disadvantages:

Storing a message for each user will lead to super redundancy of data. Instructor Yang mentioned the issue of slow Publishing. In my opinion, if the frontend waits for users to store a message separately, the publishing will be slow. Of course, I think Sina will not return the message only when the backend completes the data, so I don't know why there is a problem.

Regarding the slow posting, instructor Yang mentioned adopting the asynchronous mode for handling. This is worth learning. The frontend is only responsible for pushing data into the backend processing queue, and the backend is responsible for complicated data processing. In our point achievement system, we can also make such modifications later: the data required by the front-end is processed in real time, and the front-end does not need to put the data into the message queue for the time being, and the cronProgramAnd provide the frontend response speed. It seems that this method is also a little effective for reducing the pressure on data, I guess.

 

About Version 2

Asynchronous processing and message push optimization for the right-side Publishing

I am not very familiar with the asynchronous processing of the posts on the right. I don't know if it is about Asynchronization of Weibo data on the right, but it seems that it is not. It is often seen that the data display on the Right of Weibo seems to be performed through Ajax, because each time the page is opened, it is found that the data is always displayed at the end. It is not clear whether the post is asynchronous.

The optimization of message pushing is the operation in the background, which is not observed when Weibo is used. However, it is worth learning the idea of dividing users into valid users and non-valid users for delivery. Effective users can see the latest feed in a timely manner, which is the service purpose of the product. delayed message pushing can reduce the pressure on the system for non-effective users. (The user who has logged on to the current day is a valid user; otherwise, the user is not a valid user)

Data Splitting: I don't fully understand it. If you have any understanding of shoes, I 'd like to post them.

The asynchronous processing method is very good. I am not very familiar with the mentioned memcacheq product. I have time to learn it.

 

About the Third Edition

It's even more of a super Nb thing, but a lot of things are not understood. Really fucking tragedy.

 

The Weibo system architecture is just like the fucking Nb.

 

The multi-master solution is mentioned in the middle, which requires in-depth understanding.

 

Personal experience:

1) for basic services, a unified interface is provided for upper-layer services, especially for data operations. The underlying layer obtains data and processes data. As mentioned by instructor Yang, if the data operation layer is bound to the data acquisition layer, the acquisition will lead to a large number of program changes. Individuals can try to obtain data in a way similar to this situation, which can be provided by the underlying layer. In this way, when the data volume needs to update the underlying data structure, you can quickly iterate when you need to deploy sub-tables or multiple memcache instances.

2) I haven't figured it out yet. Well, there must be two things.