Micro blog comment architecture design

1.  Business background

The design architecture supports users to send microblog comments and view comments

Comment on

• The user writes a comment and clicks the send Comment button

• Comments are posted to the Weibo article comment area

See the comments

• Some comments will be displayed when viewing Weibo

• After the user clicks on more comments , The comments area shows more comments

2.  Constraints and restrictions

Micro-blog 、 Viewing the microblog function is prior to posting comments 、 See the comments

Consideration cost , Use appropriate resources to support comment Services

3.  Overall computing architecture

3.1  Analyze and evaluate

3.1.1  Performance requirements

According to statistics ,2020.9 Live every month 5.11 Billion , Diurnal activity 2.24 Billion ( Reference resources 《 Microblogging 2020 User development report 》).

Because the vast majority of microblog users watch microblogs for big V And stars , Therefore, we assume that the average number of people watching a microblog is 100 Time , The number of times you watch microblog is :

2.5 Billion  * 100 = 250 Billion .

Suppose most people tweet in the morning 8:00~9:00 spot , At noon, 12:00~13:00, evening 20:00~22:00, All in all 4 Hours , These periods 60% Reading Weibo . Read Weibo and make comments , Time coincides , Suppose one third of the people （20%） Will post comments , According to this estimate TPS by ：

250 Billion  * 20% / (4*3600) = 333k/s.

Microblogging involves several key processes : Content review ( Rely on the audit system )、 Write data to storage ( Dependent on storage system )、 Data write cache ( Rely on the cache system ). Writing a comment requires a similar process , Per server 、 Processing per second 500 To estimate , Without relying on buffers , Need roughly 700 Servers . Hot events may have a large number of read requests , There will also be more comments

It is obviously less important to write comments than to send microblogs , It is not economical to use a large number of servers to process comments . According to the course design, there are 25 Servers , Suppose you write comments using the same 25 Servers , Press 10k/s TPS Calculation , About as much as it takes to write a comment 400k/s TPS comparison , Difference between 40 times , You need to use a buffer to handle transient peaks . Due to the use of buffers , We can increase the buffer and reduce the number of comment servers , But that means users have to wait longer , To see the comments .

The estimation of reading comments is the same as that of reading microblogs . According to the learning text , Most people's time period of watching microblog basically coincides with that of sending microblog , So the average number of people watching microblog  QPS  The calculation is as follows :

250 Billion  * 60% / (4*3600) = 1000K/s.

3.1.2  High availability

Current limiting is required 、 Fuse 、 High availability can be achieved by degrading . Commenting is not as important as microblogging , Priority should be given to ensuring microblogging services , The number of comment servers should not be increased at will .

3.2  Microblogging comments on the design of high-performance computing architecture

Still use the microblog 4 Level load balancing architecture . On this basis , Add microblog comment server , Support the function of sending comments and viewing comments .

Use Weibo 5 Level cache architecture , On this basis, add the review service .

3.2.1  Non hot event high performance design

Split microblog comments into independent services , Because the comment function and microblogging 、 Reading Weibo is different , Decomposing into independent services is easier to extend .

The timeliness of commenting is not high , You can write to the buffer before processing , Even if the processing speed is lower than that of the general microblogging service , Still acceptable . The number of comment servers can be less than that of microblog servers , Easy to save costs .

When I read the microblog, I will also read the comments ,“ hypothesis  CDN  Capable of carrying 90% Of users , So the rest 10% The request to read microblog enters the system , Ask for  QPS  by 1000K/s * 10% = 100K/s, Because the processing logic of reading microblog is relatively simple , Mainly read cache system , Therefore, it is assumed that the processing capacity of a single business server is 1000/s, Then the number of machines is 100 platform , according to 20% Reserved quantity of , The final number of machines is 120 platform ”. Look at the same estimate that the comment server can use , It's also 120 Servers .

Due to different requirements for reading comments , We can add specific optimizations .

• Use buffering in case of irregular refresh , Add expiration time to the passive cache , Read cache from database again after invalidation . Multiple caches have different expiration times .

• Due to the increasing number of comments , It can refresh regularly , Active update strategy can also be adopted , Let the daemon update comments .

• If you can't handle the comment request , Can be discarded directly , It can be processed when the user requests again .

3.2.2  Hot event high performance design

Try to predict hot events , When the reading traffic of the same microblog increases rapidly , The following measures can be taken

For writing comments

• Increase the comment queue length

• Increase the number of comment servers

For reading reviews

• Add multiple cache servers , And set different expiration time

• If you can't handle it, just discard it

3.2.3  Hot event high availability design

When hot event prediction fails ,  The following methods are required to keep the comment function available

• Current limiting
  ： Control the number of comments .
  client
  Set the clock , Only after the countdown is completed can you post comments , And explain that only limited comments are allowed within the specified time . It can also be in
  The service gateway
  Directly reject the comment request in . When the number of microblog comments received is greater than
  Application service queue
  when , Discard comments directly , And prompt the user that they cannot comment .

• Fuse
  ： You can temporarily turn off some user comments , If users make too many comments in a short time , Just temporarily remind the user that they can't comment again for a period of time .

• Downgrade
  ： Observation hotspot , When the system is overloaded , You can manually turn off the comment function temporarily .

4.  Detailed design

4.1  Core functions

4.1.1  Comment on

After all levels of load balancing , The write comment request arrives at the write comment server , Service usage Reactor Pattern , After processing, a successful client is returned .

• As long as the queue is not satisfied , After writing a comment request , You can return success to the client

• If the queue is full , Discard the write comment request , Return failed to client

4.1.2  Read comments

Most comments are read from the cache , Only when the cache does not hit, it can be read from the review service and the database

4.2  Key design

nothing

4.3  design code

nothing

5.  Quality design

Record the connection time , Evaluate performance based on connection time , Load balancing .

6.  Evolution planning

nothing