消息系统设计

最近需要做到关于消息的功能，参考着博客写下自己的一点感悟（读后感），参考博客链接。

消息分为两大类：私信和公告/提醒。（原博客分为三种，私信，公告，提醒。我觉得公告和提醒有很多类似的地方，先大类上分为一类）

私信：就是用户发送给用户的信息。比如：在简书中的评论聊天。可以表示为：谁给谁发送了什么内容。这种情况下，需要有一个userId维护这个发送者，一个toUserId来维护这个接受信息的对象，一个content来维护内容。

公告/提醒：系统给你发的信息，类似于下图：

公告/提醒 公告/提醒

这种归纳起来简单分为：谁对什么东西干了什么。这样归纳起来应该是需要userId来维护这个谁，需要一个type来维护什么东西，action来维护干了什么。对于简单的场景来说，这种记录只是给自己看的，即userId就是要发送对象的id，我的简书动态只发送给我自己看。之前的博客之所以把公告和提醒分开是因为，公告是给任何人看的，用上面的三个简单字段可以简单实现。但提醒是需要关联到对象。谁对一个谁的什么东西干了什么。比如：XX给的我的文章点了赞。这里需要额外的一个toUserId来维护这篇文章是属于我的。

但一般现在的场景都比较复杂，可能谁关注我了，看过我，我的动态就会推送给谁看，这里涉及到获取信息的方法。

获取消息的方法有两种：一种是推送，PUSH。简单来说，就是我发了一条信息给你，你是被动的接收的。我是主动推送的。当然还有很多区别，比如可不可以重复消费，见专门写通信mq的博客。这种适合用在私信上。

一种是拉取，PULL。参考观察者和订阅者博客。简单来说，是推送的反面。

信息表

仅仅考虑存储信息的话，信息表已经可以简单的实现信息的存储，不管是私信还是公告提醒。

接下来讨论如何发送信息。重点是原先的博客提到了订阅的表。订阅的表用于拉取信息,见更新。