面对千万级关系链与实时推送挑战，腾讯频道如何构建高性能Feeds流系统？本文深度解析三层架构设计策略，揭秘读写扩散混合方案与扩散量剪枝优化，破解超大社区场景下的空拉难题，为复杂社交产品架构提供实战经验。
腾讯频道是一种基于爱好、话题或者因为现实中的某个组织，比如大学，将一群人聚集在一起，以帖子为内容载体，并辅以实时消息、音视频、直播、开黑、日程、机器人等能力的社区。
既然是以帖子为内容载体，那帖子系统如何实现则是频道的架构设计中重要的一环。
频道作为一个用户社区，同时也是一个 Feeds 流产品，和同为社区或者 Feeds 流的产品相比，复杂度都是非常高的。
QQ 群&朋友圈：和 QQ 群还有朋友圈相比，虽然都是实时的同步模式，和强关系链，但是 QQ 群和朋友圈关系链的规模都是千级别，而频道则是千万级别的超大关系链。
贴吧&微博&小红书：贴吧、微博、小红书相比，虽然都是同为超大规模的关系链，但是这三款产品是关注的弱关系，内容的同步方式更多的还是异步的，小红书核心场景都是基于推荐和搜索，微博和贴吧则是关系和推荐都有，而频道则是基于超大关系链的带有实时推送的内容流。
同时频道相比于其他产品有更加复杂的功能和权限，综上所述频道在所有维度都有更高的复杂度，而这些对于 Feeds 流都有着直接的关联影响。
频道的内容功能非常多，常规的所有的能力如帖子、评论、回复等等都有，除此之外，还有非常繁杂的 Feeds 流。
-
子频道帖子列表：单频道内单个子频道的帖子列表，包括按照发表时间&互动时间两条内容流。
-
帖子广场：单频道内所有子频道的帖子聚合列表，同样包括最新发表，最新回复两条流。
-
个人动态：单用户加入的所有频道的所有子频道的帖子聚合列表，按发表时间排序。
-
发现页：基于推荐设计的全局内容流。
-
话题帖子列表：所有发表带有某个话题的内容流，支持两条排序流。
其他我发表的、我点赞的、我浏览的帖子列表则是字面意思，不一一展开介绍。
除此之外还有帖子的评论列表，评论的回复列表，个人的互动消息列表等等也不一一展开。
那这么多复杂的功能，我们应该如何设计呢？
我们不要被这么多的功能吓到，所有功能的底层逻辑都是相通的，只要我们遵从后台的设计理念分而治之，再多的功能都能轻松厘清。
以下是一个极简版的频道 Feeds 系统的结构图：
整体遵从3个原则：
大多数的功能只要遵循这3个原则，基本都能比较容易的拆解和实现。
频道作为一个 Feeds 流社区，Feeds 流必然是其最关键的设计，Feeds 流作为业界相对比较常见的产品，无论是国内还是国外都有比较多的同类产品，方案也都相对比较明确，那么频道和这些产品相比有什么不同吗？
以下业界产品普遍的最简单的映射单元：
这是一种基于关注关系的 Feeds 流，如微博和小红书的关注列表，内容生产者发表内容，一群内容消费者关注内容生产者消费内容，同时每个消费者还会关注若干个生产者。
以下是频道的最简单的映射单元：
从对比中很明显可以看出频道是一种多层级的映射关系，生产者发表内容在各个子频道内，而子频道又归属不同的频道，子频道还有复杂的权限限制，消费者通过加入或者浏览这些频道来消费内容。频道明显更加复杂，业界方案肯定是没有办法直接搬过来用的，那我们应该如何设计呢？
虽然上面说是最小的映射单元了，但是只是为了和业界其他产品在同一个维度上进行对比，实际上还有进一步简化的空间。
1）子频道帖子列表
先复杂到简单：先把复杂的映射关系进一步简化，我们就能得到如下模型。
这就是频道内某个子频道下帖子列表的模型，和业界其他的模型就基本一致了，我们就可以选择业界比较常见的读扩散或者写扩散简单的实现。实现方式如下：
这里我们选择写扩散（或者也可以不叫扩散），简单的实现了频道下 C1、C2、C3 三个子频道帖子列表，其中 C1 为私密子频道，仅部分用户可见。
2）帖子广场
再简单到复杂：实现了简单的模型后，再在简单模型的基础上慢慢复杂化，实现更加复杂的帖子列表。
我们已经实现了子频道帖子列表了，下一步单个频道下的帖子广场（前文有介绍帖子广场是什么）应该如何设计？依然是先设计模型：
模型进一步复杂后依然还是三层映射，这里我们选择同子频道帖子列表通过读扩散的方式聚合实现：
