类似微博的消息推送的两种实现方式

我们在微博上订阅并关注某些人的微博，这些关注的人发布一条微博的时候，我们打开微博浏览会看到一条条消息按照时间的逆序在我们的首页展示出来，我们可以不停地往下阅览这些消息。那么从消息发布到阅览，这背后的技术是怎么实现的呢？下面我们来一看究竟。

方案一：在消息发布的时候插入同一个全局的消息主表中。当用户查看时间时，首先查找所有关注的对象，列出这些人的所有消息，最后以时间为序来排序合并。大概的关系型数据模型如下：

1. follows 表

2. message 表

3. user 表

方案二：对每个用户维护一个缓存，类似每个用户都有个邮箱来保存消息。当用户推送新的消息时，查询其关注者，将每条消息插入到每个关注者的缓存中。因为已经预先将结果取出，之后访问的时候性能非常快。

当业务刚开始的时候可以采用第一种方案，因为这时候可能存在很多僵尸用户，没必要每次都先把消息同步到用户消息表中。但是随着业务量的增大，这时候需要同步的消息会越来越多，如果每次用户来读取数据时都需要同步消息，那么会造成读的压力很大。

这时候可以采用第二种方案，提前把这些消息同步到用户的消息表中，这样用户来读取消息的时候就无需同步。但是如果某个用户的关注者很多，例如某某明星，那么会每次发布一条消息的时候，会造成写的压力。

这时候可以考虑将第一种方案和第二种方案结合起来，普通用户采用第二种方案，提前将消息同步好。而某些明星级别的用户就等用户读取消息时再同步。

而最近在项目中，我们要实现一个站内的消息中心，分为单播消息（该条消息针对某个用户）、广播消息（针对所有用户）、组播（某些特征用户）。我们的设计方案是单播消息每次发布消息都插入到用户消息表中，而广播消息我们有一个广播消息表，发布广播消息的时候则先插入到广播消息表中，这时候还没有同步到用户消息表中。而是等到用户登录的时候，再同步这些消息。我们再用户属性表中记录上次在广播消息表同步的消息id。这种方案跟上面讨论的方案一是一样的，因为我们的业务量和消息量处于开始阶段。