第7章内容发布系统——7.5 内容分发设计

7.5 内容分发设计

内容被正式发布后并没有万事大吉，我们还有很重要的一个问题要讨论，那就是如何才能让别人看到这条已发布的内容。

7.5.1 内容分发渠道

根据刷社交软件的经验，我们知道一个用户的作品可以通过多种渠道呈现给其他用户。比如推荐Feed流可以把我们可能感兴趣的内容推送给我们，Timeline Feed（或称为关注人动态）可以让我们刷到所关注的人最近发布的内容，我们还可以主动按照自己的兴趣去搜索与某关键词相关的作品，去某热门话题下查看相关的用户讨论，去我们喜爱的创作者主页查看最新作品这些能看到内容的场景就是内容分发渠道。

按照微服务的划分，这些内容分发渠道有各自的业务开发团队、技术栈和应用服务。比如推荐Feed流渠道会由专门的算法团队维护，他们使用大数据处理、推荐算法等技术构建内容推荐服务。

7.5.2 何时通知分发渠道

• 为了让内容在创作者的作品列表中曝光，需要将内容放到作品列表中；
• 为了让内容被推荐，需要根据内容特征，将内容放入对应的推荐召回池中；
• 为了让内容被创作者的关注者看到，可能需要将内容投递到关注者的收件箱中；
• 为了让内容在创作者的主页上展示，可能需要把内容放入创作者的发布作品列表中；
• 为了让内容被搜索到，需要为内容的关键词建立索引；
• ……

总之，当一条内容发布完成时，我们需要通知各种内容分发渠道。

内容被删除、下架，以及被审核拒绝，需要通知内容分发渠道。这很好理解，既然一条内容已经被认为应该消失，那么自然不应该再在各种分发渠道展示了。

内容的可见性被修改时，也需要通知内容分发渠道。比如创作者将某内容的可见性从所有人可见改为私密，从其他用户的视角来看，等于此内容已被删除，推荐服务、搜索服务等各种渠道都不应该再展示此内容了。

7.5.3 将内容投递到分发渠道

上文说到，不同的内容分发渠道往往由不同的团队维护，对外提供应用服务，比如推荐服务、动态服务、搜索服务、话题服务（提供各种话题下的全部作品列表，类比微博超话 ）、作品列表服务（提供创作者发布的全部作品列表）等。为了将一条已发布的内容顺利地投递到各种分发渠道，内容发布系统的维护团队需要和渠道维护团队进行技术沟通与交互开发，这会产生较大的开发工作量和维护工作量。况且，随着产品的迭代升级，内容分发渠道会越来越多样化，每当产生新的内容分发渠道时，内容发布系统都要去配合开发吗？

我们是否可以不用关心各种内容分发渠道的逻辑细节，以及不用关心新的内容分发渠道？答案是肯定的，我们可以采用软件设计模式中经常被提及的“解耦”思路：为了让内容与内容分发渠道充分解耦，内容发布系统可以借助消息队列与内容分发渠道通信。

无论是内容的发布、删除、下架还是可见性变更，都属于内容元信息变更。也就是说，各种内容分发渠道在意的是内容元信息变更，所以内容分发渠道向消息队列发送的消息内容应该是内容元信息，而不是内容主体（如文本、图片、视频）。如果内容分发渠道需要内容主体，则按需调用内容发布系统的接口来获取即可。

如图7-5所示，我们为“内容的发布”“内容的删除”“内容的下架”“内容的可见性变更”等一切涉及内容元信息变更的事件都创建一个消息队列主题event_content_meta_change，内容发布系统为其消息生产者，各种内容分发渠道为其消息消费者。每当有用户发布内容并上线时，各种内容分发渠道都会实时拿到新内容，执行各自的分发逻辑；每当有内容被用户主动删除时，各种内容分发渠道都会实时得到通知，然后从各自的内容池中删除这条内容。

这里再简单了解一下各种内容分发渠道在收到新内容时会做什么事情：

• 推荐服务在收到新内容时，会读取内容主体并对内容进行适当的特征提取，将内容放到合适的召回池中；
• 搜索服务在收到新内容时，会读取内容主体并对内容进行自然语言处理，提取关键词，建立文档倒排索引，比如类Elasticsearch索引；
• 动态服务在收到新内容时，可能会将内容的item_id投递到粉丝的收件箱中；
• 话题服务、作品列表服务在收到新内容时，会把item_id分别加入hashtag（话题标签）和创作者的作品列表中。