如今的内容型产品，不管提供的是什么类型的内容，在其主功能之外，不可避免的会有另一个十分重要的功能——消息中心。
而无论是信息流、论坛、信箱，还是私聊、群聊、通知，推拉模型是内容型（包括：社交型）产品架构的核心。做出正确选择的关键在于对产品形态和系统组件清晰的认识。
今天我们将重心放在消息中心上，聊一聊如何设计一个消息中心。
需求分析 消息中心通常会有两个功能（如下图所示）：
用户通知（点赞、评论、关注、@等） 官方通知 接下来我们将会对这两类通知进行一个简单的抽象。
首先，可以确定的是，对于用户通知，每个用户都不一样（我的点赞列表和你的点赞列表肯定是不一样的），因此对于每个人我们都需要维护一个「收件箱」。
当 A 点赞了 B 的内容，后端系统在收到了这一个点赞消息后，会将点赞信息写入 B 的 「收件箱」，并标明这是 A 在 xxx 时点赞的 xxx 内容。这是一个系统将消息 推送 给 B 的过程。
而对于官方通知，每个人（几乎）都是一样的（用户有可能设置了屏蔽，系统也可能指定了发送人群），并且官方通知是由系统自然下发的，因此对于系统来说需要维护一个系统**「发件箱」**。
发件箱维护了官方想给用户的通知，每次打开消息中心时，用户都会主动来系统**「拉取」官方最新的消息，并和用户自己的「收件箱」里的官方通知进行比较，以确认是否已读该条通知。这是一个用户主动从系统「拉取」**通知的过程。
推拉模型 其实到这里就已经点出了这两个场景背后的一套模型——推拉模型。而之所以在这两种场景选择不同的运行机制，其实背后牵扯到的是读写扩散的问题。
推模型 先看推模型，对于任何一个内容创作者来说，最开心的事情莫过于打开软件会有一堆点赞/评论的小红点。对于大 V 来说，打开 App 查看点赞消息的频率根本比不过别人给你点赞的频率，这是一个很典型的读少写多的场景。每当有一个用户点赞该大 V 时，都会将索引信息（一般为内容 ID、类型、发表时间等索引数据）写到用户的收件箱中。
优点：读很轻。仅需要读取消息列表即可。 缺点：写很重。一旦用户的内容质量很高，可能会收到大量的点赞/评论，会有大量的写入操作。 拉模型 再看拉模型，以官方通知为例，一般官方通知是由运营人员发布的，一个月可能也不会有几条，但是每次用户进入 App 时都会看看是否有新的官方通知进来，这是一个很典型的读多写少的场景。
优点：写很轻，节省空间。系统只需维护一个属于自己的消息列表即可。 缺点：读很重，计算量大。假设可以发送官方通知的生产者较多（例如淘宝里的一系列官方业务），则每次都需要从这些消息生产者里拉取最新的内容。 流程设计 用户通知 对于用户通知，流程设计如下：
对于该流程，有几点需要注意的：
异步发送 当用户出发了点赞/关注/评论行为时，被点赞/评论/关注的用户，其实不需要立即感知，因此也不需要立即将互动信息写入该用户的收件箱中，因此可以考虑以消息队列的方式通知出去，缓解系统压力。
缓存前置 写入消息时，如果直接写入用户收件箱，可能会导致用户在请求消息列表时，将请求全部打到 DB，造成系统故障，因此通常会在更新用户收件箱时双写用户缓存。
官方通知 相较于用户通知，官方通知由于引入官方运营这一角色，操作上会稍微复杂一些（如上图所示），因此整个系统的设计也会稍微复杂一些。...
积分作为一种营销手段，被广泛运用于线上/线下的产品中，以此来增加用户对于产品的粘性。比如天猫积分可以用来兑换商品，京豆可以在下单折扣等，如下图所示。
如今，随着获客成本的增加，如何减少用户的流失，变成了各个产品的核心命题之一。也正因如此，很多业务引入了各式各样的积分系统。为了更好的面对业务带来的变化，对整个积分兑换流程做一个合理的抽象是正确且有必要的。只是，整个积分的兑换是一个非常庞大且复杂的流程，因此，本着一切从简的理念，我们这期先聊一聊如何设计一个积分领取系统。
从具体到抽象 无论是天猫积分/京豆，都会有一个规则说明，笼统的来说，无外乎两个主要的功能点：如何获取积分以及如何消费积分。
获取京东的方式通常有：
每天签到一次，领5个京豆 买100元以上的东西，领20个京豆 发1条20字以上的评论，领10个京豆 …… 从上面的规则中，我们可以看出，基本符合一个格式：xx行为，执行yy次，可以得到zz个ww。
于是我们可以将上述案例抽象成以下三步：
行为感知 任务推进 权益领取 架构设计 本着高内聚与低耦合的理念，我们可以抽象成几个核心模块
行为感知模块 该模块负责对用户的行为进行感知，如果用户的登录行为、点赞行为、下单行为等。通常情况，该模块是异步进行的。
原因也很简单，行为感知作为依附于主链路存在的功能，其存在不应该影响到主链路的运行。
例如“用户每日登录获取一个积分”这样的案例，我们不应该在登录接口同步进行行为感知。通常采取的做法是，开一个子线程调用一下行为感知接口即可。
但是，行为的种类千奇百怪，如何对行为进行一个合理的抽象便是我们要考虑的问题了。一个简易的流程图如下所示：
在上述流程里，行为感知模块可以感知多种数据源（消息），解析不同业务的消息数据后，为了转换成系统内部需要的行为对象，通常还需要有一步数据填充的过程，这一步需要我们和其他的服务进行联动的，在数据填充完成后，外部的行为才真正变成我们整个积分领取系统内部所需要行为对象，这一步可以可以再发出一个行为变更消息出去，以便和其他业务解耦（当然也可以提供一个接口）。
任务推进模块 我们将如何领取积分归到该模块中。
所谓任务推进，便是我们上述案例中提到的例如：下单20元的物品、点赞10条内容、登录1次这样的行为。在该模块中，我们需要维护一张用户行为记录表和一个任务规则表。
行为记录表负责维护用户每天的任务进度状态，例如点赞了多少条内容等信息。
任务规则表负责录入玩法规则，比如点赞10条内容可得一个积分这样的信息。该部分通常会由一个运营后台来承接。
一个简易的流程图如下
在上述流程中，任务的匹配与任务进度的更新是比较核心的部分。如何做好技术选型是比较重要的一点，我们将会在下一章详细介绍。
权益领取模块 出于高内聚低耦合的思想，我们可以将权益系统的职责设置的简单一些，只需要负责增加积分、减少积分，查询积分明细这几个工作。至于从什么渠道加积分、加多少积分，则将职责上移到任务推进模块中进行。
举个例子解释一下。比如，用户通过下订单赚取积分。订单系统通过异步发送消息或者同步调用接口的方式，告知行为感知模块订单交易成功，补全必要的信息后，发送给任务推进模块；任务推进模块根据拿到的订单信息，查询订单对应的积分兑换规则（兑换比例、有效期等），计算得到订单可兑换的积分数量，然后调用权益领取模块的接口给用户增加积分。
这一部分的流程比较简单，就不画图了。但是如何保证积分加的正确，如何保证不重复加或者不漏加则是该模块的难点。
小结一下 简单对上述三个模块进行一个小结。有了上述共识后，我们可以抽象出如下的功能图。
详细设计（数据表设计） 数据库和接口的设计非常重要，一旦设计好并投入使用之后，这两部分都不能轻易改动。
改动数据库表结构，需要涉及数据的迁移和适配。改动接口，需要推动接口的使用者作相应的代码修改。这两种情况，即便是微小的改动，执行起来都会非常麻烦。因此，我们在设计接口和数据库的时候，一定要多花点心思和时间，切不可过于随意。
相反，业务逻辑代码侧重内部实现，不涉及被外部依赖的接口，也不包含持久化的数据，所以对改动的容忍性更大。
在对上述流程进行了一个抽象之后，我们发现有两个非常重要的表：任务规则表和任务进度明细表。
数据字典设计 任务规则表 这张表的设计比较简单，只需要指明相应的活动规则即可，表结构如下。
字段 说明 id 活动ID name 任务名称 description 任务描述 type 任务类型 userAction 用户行为 num 任务次数 rewardCount 任务完成后的奖励数值 rewardType 任务完成后的奖励类型 period 单次任务的周期，本次需求仅支持天级别（DAY）的周期 threshold 每个任务周期内能完成的次数上限 🌰场景举例...