在设计微博、朋友圈、这类社交产品的信息流Feed流时我们面临一个核心的技术挑战如何高效地将用户发布的内容分发给海量的粉丝这就引出了三种经典的设计模式拉模式Pull、推模式Push以及工业界最常用的推拉结合模式。本文将带你由浅入深从原理到优缺点再到实际架构选型彻底搞懂这三种模式。拉模式拉模式顾名思义是一种“按需索取”的机制。它的核心思想是内容发布时不主动分发而是由粉丝在查看时主动去拉取。工作原理写操作当用户A发布一条动态时系统只负责将这条动态写入A自己的“发件箱”Timeline表中。无论A有多少粉丝写操作只发生1次。读操作当粉丝B刷新Feed流时系统会执行以下操作获取B关注的所有用户列表例如A, C, D... 共M个人。分别去拉取这M个人的“发件箱”中的最新动态。在内存中对这M路数据进行合并、排序按时间或算法、过滤如屏蔽词、拉黑用户。将最终结果返回给B。优点写性能极高发布动态的延迟极低因为只写一次数据库。即使是有千万粉丝的大V发帖也不会对写入系统造成压力。存储节省数据只存储一份不会因为粉丝数量的增加而复制N份极大地节省了存储空间。灵活性高读取时的过滤和排序是在内存中实时计算的因此可以非常灵活地实现个性化推荐、屏蔽某人、只看好友等复杂功能。缺点读性能差这是拉模式最大的瓶颈。如果一个用户关注了2000人刷新一次Feed流可能需要查询2000次数据库或缓存。这种“扇出”操作会消耗大量的CPU、内存和网络IO导致读取延迟非常高。实时性稍差由于读取时需要聚合大量数据处理时间较长用户看到最新内容的延迟会比推模式稍高。推模式推模式也叫“写扩散”是一种“主动推送”的机制。它的核心思想是内容一旦发布就立即推送给所有关注者。工作原理写操作当用户A发布一条动态时系统会立即查找A的所有粉丝列表例如B, C, D... 共N个人。然后将这条动态的ID或简要信息分别写入到B、C、D...每一个人的“收件箱”Feed表中。写操作发生了N次N粉丝数。读操作当粉丝B刷新Feed流时系统只需要直接读取B自己的“收件箱”即可。因为所有他关注的人的动态都已经预先推送到他的收件箱里了。优点读性能极高读取操作变成了简单的单表查询速度极快延迟极低。这对于高并发读取的场景如微博热搜至关重要。实时性好内容一旦发布粉丝的收件箱里立刻就会出现用户体验非常好。缺点写放大严重这是推模式最大的痛点。如果一个拥有1000万粉丝的明星发一条微博系统需要执行1000万次写入操作这会对数据库造成巨大的写入压力甚至导致消息队列阻塞影响其他普通用户的发帖体验。存储浪费每条动态都在系统中被复制了N份N粉丝数对于热门用户这会占用海量的存储空间。推拉结合模式既然拉模式读性能差推模式写性能差那么有没有一种两全其美的方案答案是肯定的那就是推拉结合模式。这种模式的核心思想是根据用户的粉丝数量和活跃度动态选择推或拉的策略。工作原理普通用户粉丝数少采用推模式。因为粉丝数量不多写扩散的成本很低可以保证粉丝读取的高性能和实时性。大V用户粉丝数多采用拉模式。避免写扩散带来的巨大压力。粉丝在读取时再从大V的“发件箱”中拉取。进一步优化按活跃度大V的活跃粉丝可以采用推模式。虽然大V本身用拉模式但对于那些刷新频率极高的活跃粉丝可以提前将大V的动态推送到他们的收件箱保证体验。大V的非活跃粉丝采用拉模式。这些粉丝刷新频率低对实时性要求不高可以在他们刷新时再临时拉取。