How can the "friend dynamic" information stream of 100,000-level active users be efficiently implemented?

How to design a MySQL and Redis databases with 100,000-level active user social networks and users' homepage information flows (that is, friend dynamics? Is there any requirement on the PHP end? Note: Only one server or two servers are allowed. Large clusters are not considered. In addition, I want to know about tens of millions of Sina Weibo users. How to design a MySQL and Redis database with 100,000-level active user social networks and users' homepage information flows (I .e. friend dynamics? Is there any requirement on the PHP end?
Note: Only one server or two servers are allowed. Large clusters are not considered.

In addition, I want to know how Sina Weibo's dynamic data table of friends with tens of millions of active users is implemented?

Reply content:

How to design a MySQL and Redis databases with 100,000-level active user social networks and users' homepage information flows (that is, friend dynamics? Is there any requirement on the PHP end?
Note: Only one server or two servers are allowed. Large clusters are not considered.

In addition, I want to know how Sina Weibo's dynamic data table of friends with tens of millions of active users is implemented?

Real-time information flows, such as Weibo, need a complete cache system. The information flows of each person are directly pushed. Of course, some user policies can also be pulled. In this way, timeliness can be ensured.
If the number is 100,000, two servers are sufficient.

Redis + mysql, cold and hot data are stored separately, and high-frequency data reading is stored in the memory. It is not a problem to prevent tens of millions of users. There are also high-end fusion IO solutions, and the read/write performance of SSD has been greatly improved. Weibo should adopt poll instead of push strategy.