tag: 消息

如今的内容型产品，不管提供的是什么类型的内容，在其主功能之外，不可避免的会有另一个十分重要的功能——消息中心。 而无论是信息流、论坛、信箱，还是私聊、群聊、通知，推拉模型是内容型（包括：社交型）产品架构的核心。做出正确选择的关键在于对产品形态和系统组件清晰的认识。 今天我们将重心放在消息中心上，聊一聊如何设计一个消息中心。 需求分析 消息中心通常会有两个功能（如下图所示）： 用户通知（点赞、评论、关注、@等） 官方通知 接下来我们将会对这两类通知进行一个简单的抽象。 首先，可以确定的是，对于用户通知，每个用户都不一样（我的点赞列表和你的点赞列表肯定是不一样的），因此对于每个人我们都需要维护一个「收件箱」。 当 A 点赞了 B 的内容，后端系统在收到了这一个点赞消息后，会将点赞信息写入 B 的 「收件箱」，并标明这是 A 在 xxx 时点赞的 xxx 内容。这是一个系统将消息 推送 给 B 的过程。 而对于官方通知，每个人（几乎）都是一样的（用户有可能设置了屏蔽，系统也可能指定了发送人群），并且官方通知是由系统自然下发的，因此对于系统来说需要维护一个系统**「发件箱」**。 发件箱维护了官方想给用户的通知，每次打开消息中心时，用户都会主动来系统**「拉取」官方最新的消息，并和用户自己的「收件箱」里的官方通知进行比较，以确认是否已读该条通知。这是一个用户主动从系统「拉取」**通知的过程。 推拉模型 其实到这里就已经点出了这两个场景背后的一套模型——推拉模型。而之所以在这两种场景选择不同的运行机制，其实背后牵扯到的是读写扩散的问题。 推模型 先看推模型，对于任何一个内容创作者来说，最开心的事情莫过于打开软件会有一堆点赞/评论的小红点。对于大 V 来说，打开 App 查看点赞消息的频率根本比不过别人给你点赞的频率，这是一个很典型的读少写多的场景。每当有一个用户点赞该大 V 时，都会将索引信息（一般为内容 ID、类型、发表时间等索引数据）写到用户的收件箱中。 优点：读很轻。仅需要读取消息列表即可。 缺点：写很重。一旦用户的内容质量很高，可能会收到大量的点赞/评论，会有大量的写入操作。 拉模型 再看拉模型，以官方通知为例，一般官方通知是由运营人员发布的，一个月可能也不会有几条，但是每次用户进入 App 时都会看看是否有新的官方通知进来，这是一个很典型的读多写少的场景。 优点：写很轻，节省空间。系统只需维护一个属于自己的消息列表即可。 缺点：读很重，计算量大。假设可以发送官方通知的生产者较多（例如淘宝里的一系列官方业务），则每次都需要从这些消息生产者里拉取最新的内容。 流程设计 用户通知 对于用户通知，流程设计如下： 对于该流程，有几点需要注意的： 异步发送 当用户出发了点赞/关注/评论行为时，被点赞/评论/关注的用户，其实不需要立即感知，因此也不需要立即将互动信息写入该用户的收件箱中，因此可以考虑以消息队列的方式通知出去，缓解系统压力。 缓存前置 写入消息时，如果直接写入用户收件箱，可能会导致用户在请求消息列表时，将请求全部打到 DB，造成系统故障，因此通常会在更新用户收件箱时双写用户缓存。 官方通知 相较于用户通知，官方通知由于引入官方运营这一角色，操作上会稍微复杂一些（如上图所示），因此整个系统的设计也会稍微复杂一些。...