仿微博消息中心的系統設計與實現

最近在實現一個相似於微博、網易雲的消息中心模塊。主要實現的功能是，將系統中的點贊、評論、@等消息作匯合。今天跟你們分享下，咱們的設計和實現思路。

首先說明，咱們目前是微服務的架構。因此本篇文章中對於消息中心的設計也是創建在微服務的基礎上，消息中心與其餘模塊是互相獨立的。

分析需求後，咱們能會發現消息中心的角色以下圖（以點贊消息爲例）：

針對需求，咱們有以下兩種存儲方案。

方案一：

消息表：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 表中的內容，有格式要求

綜合實際的業務需求，建議你們使用方案二。由於在實際場景中，咱們刪除帖子或刪除評論等操做，都須要影響到消息中的內容狀態。方案二在更新內容上具備絕對優點。假如使用方案一，更新消息內容會是一件至關頭疼的事情。

若是你們有疑問或有更好的建議，歡迎討論~