Weibo comments on high performance and high availability architecture

One 、 Comment on Weibo

【 Performance prediction 】

There are usually more comments than tweets , If we assume that every person sends microblogs once a day on average , Then comment on Weibo by 3 Double it , That is, every person sends 3 comments , The estimated daily sending volume of the comment Weibo is 2.5 Billion *3=7.5 Billion ;

Comment on the microblog and estimate the time period of the same microblog , expect 60% Focus on the morning 8：00-9：00, At noon, 12：00-13：00, evening 20：00-22：00 this 4 In an hour , So this 4 An average of hours TPS The calculation is as follows ：

7.5 Billion *60%/（4*3600）= 30k/s

【 Business characteristic analysis 】

A comment is a write operation , Can't use cache , You can use load balancing ; The importance and timeliness of commenting on Weibo can be weaker than that of tweeting , Write buffering can be used

【 Architecture analysis 】

Over 100 million users , Multi level load balancing is required , Cover DNS->F5->Nginx-> gateway

【 Architecture design 】

1. Load balancing algorithm selection

When sending comments, you can send requests to any server ,“ polling ” or “ Random ” The algorithm can satisfy

2. Write buffer selection

Here we use “ The capacity is infinite ” Message queue of kafka As a write buffer , Temporarily buffer requests that cannot be digested in time , The service server writes after receiving the request kafka Return to success

3. Estimate the number of business servers

Commenting on Weibo involves writing data to the message queue 、 Receive queue data 、 Content review 、 Write persistent storage , Per server 500tps To estimate , complete 30k/s Expected needs 75 platform , Add the reservation , Can press 80 Come and prepare . Even if it's slightly more than calculating power , It can also be cached in the message queue , Spend slowly

Two 、 Read microblog comments

【 Performance prediction 】

Generally speaking, you must have read the microblog through the evaluation , So you can read more comments than microblogs . Because a comment on a microblog usually reads 1-3 page , So it is also assumed that the comments are read on Weibo 3 Times the number of requests , Then it is estimated as ：

250 Billion （ Estimated amount of reading Weibo ） * 3 = 750 Billion

The time period for reading comments coincides with that for reading microblogs , expect QPS：

750 * 60%/（4*3600）= 3000K/s

【 Business characteristic analysis 】

Comments cannot be modified after they are posted , So it is very suitable to use cache architecture , There are also a lot of requests , Also use a load balancing architecture

【 Architecture analysis 】

1. Over 100 million users , To use multi-level load balancing , Cover DNS->F5->Nginx-> gateway

2. The requested quantity reaches 750 Billion , To use a multi-level cache architecture , In especial CDN

【 Architecture design 】

1. Load balancing algorithm selection

Any server can handle requests , So use polling or random algorithm

2. Estimate the number of business servers

See the estimation of Weibo , expect CDN To block 90% Of traffic , The rest 10% Enter the business server , be QPS by ：3000K/s * 10% = 300K/s; Reading business is relatively simple , Just read the cache directly , According to each station 1000QPS To estimate , Expected needs ：

300 platform , according to 20% reserve , In the end 360 platform

3、 ... and 、 The overall structure of microblog comments

Multilevel load balancing architecture

Overall architecture design

There is a business difference between posting comments and writing comments and posting microblogs and writing microblogs , It is suggested to split comments and microblogs into different businesses ;

There are also business differences between commenting and writing comments , It is also recommended to split into different businesses , At the same time, it can isolate the fault domain , To prevent situations that cannot be sent or written ;

Four 、  Weibo comments on hot events high availability computing architecture

【 Comment on 】

The commenting architecture has message queues as write buffers , It can be used as a buffer when a large number of comments are generated in case of hot events , Control the processing rate by controlling the number of consuming threads , To meet the high availability design ;

【 See the comments 】

After the hot event , Most of the requests fall under the comment on the microblog of the hot event , You can consider “ Multi copy cache ”