扇出读VS扇出写

扇出读、扇出写的说法是基于社交网络的海量用户、海量数据的应用特征。这些大量的数据往往分布在各个分片服务器上。扇出读是一种比较常规的做法，就是当你需要去获得所有你关注用户的最新更新的时候，你就去到每一个你关注用户的数据区，把最新的一些数据取回来。因为需要去到不同的分片服务器去取，所以叫做扇出读。大家可以想象，这种扇出读的效率不会太高，基本上是最慢的那个服务器的响应时间决定了总体的响应时间。 当然，这种方式是比较简单的，不需要特殊处理。

下面我们来看看比较有趣的微博墙，或者微信朋友圈的实现有什么考量。

微信墙

在实现微博墙的时候，有两种方式可以考虑：扇出读 或者是扇出写。

扇出读、扇出写

扇出读、扇出写的说法是基于社交网络的海量用户、海量数据的应用特征。这些大量的数据往往分布在各个分片服务器上。扇出读是一种比较常规的做法，就是当你需要去获得所有你关注用户的最新更新的时候，你就去到每一个你关注用户的数据区，把最新的一些数据取回来。因为需要去到不同的分片服务器去取，所以叫做扇出读。大家可以想象，这种扇出读的效率不会太高，基本上是最慢的那个服务器的响应时间决定了总体的响应时间。 当然，这种方式是比较简单的，不需要特殊处理。

扇出读

扇出写，我称之为土豪玩法。具体来说就是当发布的时候，一条数据会写多次，直接写到每一个关注你的粉丝的墙上。这样做的好处是当你的粉丝读他自己的微博墙的时候，他只需要去一个地方就可以把所有最新的更新连续取回来。由于一个用户的数据可一般可以存储在同一台服务器上的同一个区域，通过这种方式可以实现快速的读取微博墙数据。 代价当然也是很明显： 你的写入需求会被放大几十几百倍，存储也是相应的扩大几十几百倍。这个绝对不是关系型数据库的玩法，但是在MongoD 模式设计，这个很正常。只要保证性能，什么事情都做得出来。

扇出写

对比

下面这个例子，首先是mandy在发消息的时候会写（push）到我的墙上（timeline）来。如果mandy有50个关注者，那么这个写就会有50次，每个关注者一次。

第二条语句就是我打开微博的时候，一条语句，一个地方就可以找到所有我朋友发的状态更新。注意：这里还使用了bucket，这是另外一个控制文档内数组元素个数的有效方法。比如说我们定义bucket 大小是1000的话，超过1000 就把新的数据插入到下一个文档并对bucket 序数递增。

mongoDB例子

---

很高兴认识你，我们都一样，有过迷茫却从未放弃；害怕孤独可从不寂寞。