仿微博消息中心的系统设计与实现

最近在实现一个相似于微博、网易云的消息中心模块。主要实现的功能是，将系统中的点赞、评论、@等消息作汇合。今天跟你们分享下，咱们的设计和实现思路。

首先说明，咱们目前是微服务的架构。因此本篇文章中对于消息中心的设计也是创建在微服务的基础上，消息中心与其余模块是互相独立的。

分析需求后，咱们能会发现消息中心的角色以下图（以点赞消息为例）：

针对需求，咱们有以下两种存储方案。

方案一：

消息表：message。字段以下： user_id【消息归属用户】，sender_id【发送消息的用户】，src_type【消息对应的内容来源】，src_id【帖子id】，action【动做】，content_json【内容】，create_time【消息建立时间】

字段说明：

src_type 与 src_id 主要用来标识该笔消息的来源，点击进入详情的时候须要用到。

action 字段主要用于存储操做的类型，用于区分该消息是点赞仍是评论仍是其余类型。

content_json 字段用来存储该笔消息展现时须要的全部内容，其中须要包括帖子内容，帖子图片，帖子建立者等等信息。

方案二：

消息表：message。字段以下：

user_id【消息归属用户】，sender_id【发送信息的用户】，src_type【消息对应的来源】，src_id【帖子id】，action【动做】，action_id【动做id】，create_time【消息建立时间】

action_id 字段主要用来查找动做的内容。当动做是点赞或评论时，不须要存该字段。当动做是评论时，经过该字段能够到消息内容表中取值。

消息内容表：message_content，字段以下：

src_type【内容来源：帖子，评论等】，src_id【内容id】，content【内容】，status【内容状态】

有人可能会奇怪，为什么须要 message_content 表？其实一开始咱们就有提到过，咱们是微服务的架构。消息中心与其余模块是相互独立的，因此消息中心不会去各模块取值，也不该该去各模块取值，它是一个相对独立的模块。因此就须要有一个内容库去存储咱们系统中的内容。方案一中的 content_json 字段，之因此须要存这么多的内容，也是同理。

接下来咱们看一下两个方案的对比状况。

方案一：

优点：1.拓展性高，不管何种消息均可以扔进 message 表里 2.与其余项目的耦合度低 劣势：1.更新动做复杂 2.冗余数据较多

方案二： 优点：1.更新动做简单 2.与其余项目的耦合度低 劣势：1.拓展性较低，对存入 message_content 表中的内容，有格式要求

综合实际的业务需求，建议你们使用方案二。由于在实际场景中，咱们删除帖子或删除评论等操做，都须要影响到消息中的内容状态。方案二在更新内容上具备绝对优点。假如使用方案一，更新消息内容会是一件至关头疼的事情。

若是你们有疑问或有更好的建议，欢迎讨论~