Feed流这块相较于电商偏冷门一些，可能有些同学对其概念不太理解，我先来解释一下。
其实，咱们每天刷的小红书首页、抖音推荐页、新浪微博等，这些都是Feed流，说白了就是“按规则排序的内容信息流”。
如下图所示：
Feed流一共分为三大类，基于兴趣推荐内容、基于用户关注获取内容，以及将两者相结合起来。
把你所关注博主的内容、系统推荐的内容，按时间先后、兴趣匹配、热度高低等因素，整合成一条能持续往下滑的内容列表，你刷的每一页都是Feed流动态生成的结果。
Feed流具备三个核心特点：
1、动态更新，你关注的博主新增了笔记或视频，就可能会出现到Feed流信息中，不是一成不变的固定页面。
2、个性化推荐，会根据平台算法给你挑内容推荐，如果你对“汽车”方向感兴趣，就不会一直给你推荐“宠物”相关的内容。
3、沉浸式阅览，你不用点进不同页面查找内容，上下滑动就能持续阅览，犹如“刷瀑布” 般顺畅。
接下来我们就来讲讲基于用户关注获取内容的Feed流，以及其相关的读扩散和写扩散方案。
读扩散机制
我们还是以小红书APP为例进行讲解。
当我在小红书APP中点击“关注”页时，系统会从我关注的所有博主的发件箱中获取笔记，并选择其中的一些热度较高、质量优质、时间较近的笔记进行展示。
这就是读扩散机制，所谓“扩散”，就是需要读取我关注的所有博主的笔记。
如下图所示：
这里有个发件箱和收件箱的概念，我来解释一下。
发件箱（Outbox）
用户发布内容时，消息首先被写入的存储区域，记录用户所有历史发布内容，类似于电子邮箱中的“已发送”文件夹，每条消息仅存储一份。
收件箱（Inbox）
用户接收关注对象发布内容的存储区域，按时间顺序聚合所有关注人的消息，类似于电子邮箱中的“收件箱”文件夹，每条消息可能被存储多份（群发）。
细心的同学会想到，按照上述“读扩散”机制获取笔记，如果我关注了特别多（几百上千）的博主，那当我点击“关注”页的时候才现从各个博主的收件箱中读取笔记，并基于规则因子进行排序，这样会耗时非常久，严重影响用户体验。
于是就衍生出了一种新的机制来进行互补——写扩散机制。
写扩散机制
所谓写扩散机制，就是当小红书博主发布笔记时，除了写入自己的发件箱外，同时将笔记写入到所有粉丝（包括我）的收件箱中。
这样当我点击“关注”页时，直接从自己的收件箱中选择其中的一些热度较高、质量优质、时间较近的笔记进行展示即可。通过这种方式，就无需从我所关注博主的发件箱中获取笔记了，可以大幅缩短耗时，这是一种用空间换时间的思想。
如下图所示：
这种机制看似很美好，但真的可以一招鲜解决所有Feed流问题，让读扩散机制完全没有用武之地吗？
当然不能，因为小红书APP上还有另外两种生物，一种生物叫做大V，也就是粉丝量特别多的那种博主。
以演员赵露思为例，如果她发布一条笔记，2000多万粉丝采用写扩散机制，那不把数据库服务器硬盘的IOPS打满才怪。
读扩散 + 写扩散机制
结合这种读扩散 + 写扩散结合的机制才是主流的Feed流解决方案，我们来详细介绍一下。如上文所述，小红书APP上的用户分为三大类：活跃用户、僵尸用户和大V，这三类人是可以通过用户粉丝数和用户行为识别出来的。
1、如果大V进行笔记发布，需要通过读扩散机制来代替写扩散机制，来避免其写入热点导致数据库服务器硬盘的IOPS打满问题。
2、对于僵尸用户，同样需要通过读扩散机制来代替写扩散机制，来避免写扩散机制所带来的性能消耗和存储资源浪费问题。
3、而对于活跃用户，我们可以采用写扩散为主、读扩散为辅的方式，前者可以缩短笔记展示耗时，提升用户体验，后者则可以规避大V发布笔记的情况。
因此，对于写扩散机制来说，其只适用于非大V博主进行笔记发布时，往活跃粉丝的收件箱进行写入的场景。
结语
对于Feed流的读扩散和写扩散机制来说，根本没有好坏之分，只有场景适用或不适用，我们来做个总结。
1、读扩散机制的优点是消息写入效率高，且消息仅在发件箱存储一份，无需冗余存储。
缺点则是Feed流读取性能差，需要从多个发件箱读取消息，并按照规则因子进行排序，高并发下容易成为瓶颈。
2、写扩散机制的优点则是读扩散机制的缺点，那就是Feed流去读性能好，直接从自己的收件箱读取数据，并按照规则因子进行排序即可，无需进行多源聚合。
缺点则是消息写入效率低且复杂度高，且消息需要在所有粉丝的发件箱冗余存储一份，浪费硬件存储资源。
另外就是，我们可以在项目采用读扩散机制快速验证业务，降低存储与开发成本，发展至中长期再逐步迭代至读扩散 + 写扩散机制结合终态方案。
