牛B的网站怎么设计Feed流

大型互联网公司招聘的时候总是要求具备：高并发，高负载，大数据处理的能力。我们做了N多的系统项目，互联网产品，究竟哪些项目或者产品能够真正体现出高并发，高负载的处理能力呢？

个人认为是Feed流，一般都是SNS站点的私信，站短，消息等；

能够很好的架构一个多用户产品的Feed流对于个人的提升是很有帮助的；

正常的范式，我们设计一个Feed流的数据库会包括：内容，时间，用户信息等，在用户提交每条feed信息会插入到数据库中。在然后在“订阅”用户的信息流中通过 select * from feed的方式查询出来。

对于一个正常的网站来说，写的场景远远小于读的场景，所以基于这种业务特点，需要对feed系统进行特殊设计。

微博系统：

一条微博内容比较简单：内容，时间戳，ID，用户，发布之后引发写操作，数据库持久化数据。

但是之前说过，一个SNS产品的读的场景更加普遍，而出现在用户时间线上的信息通畅包含：

{

[推文di，发布者，发布内容，时间戳，图片]，

[推文di，发布者，发布内容，时间戳，图片]，

......

}，

如果按照正常的范式来说，我们会进行连表查询，

select from feed

join

select from user，

甚至写了不可扩展的“存储过程”，这样的查询会给数据库带来极大的负载，sql查询非常耗时。

基于上面的问题我们可以简单的修改，提前计算用户的时间线，之后缓存结果，用户查起来会很快，通过异步的方式写用户推文信息，这个过程会比较慢，是一个基于事件的进程处理，进程不断进行，缓存不断更新。

于是衍生出来的一个基于事件的CQRS的负载架构：

更大的架构：

1. 后面将事件存储于一个更大的数据仓库中，在那里进行预计算和分析；
2. 建立完整的文本索引，进行实时查询；
3. 通过事件进行缓存更新，能够保持缓存读取最新内容；
4. 通过事件驱动串联起整个系统数据的联动；