最近在實現一個類似於微博、網易雲的消息中心模塊。主要實現的功能是，將系統中的點贊、評論、@等消息做匯合。今天跟大家分享下，我們的設計和實現思路。
首先說明，我們目前是微服務的架構。所以本篇文章中對於消息中心的設計也是建立在微服務的基礎上，消息中心與其他模塊是互相獨立的。
分析需求後，我們能會發現消息中心的角色如下圖（以點贊消息爲例）：
針對需求，我們有如下兩種存儲方案。
方案一：
消息表：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 表中的內容，有格式要求
綜合實際的業務需求，建議大家使用方案二。因爲在實際場景中，我們刪除帖子或刪除評論等操作，都需要影響到消息中的內容狀態。方案二在更新內容上具有絕對優勢。假如使用方案一，更新消息內容會是一件相當頭疼的事情。
如果大家有疑問或有更好的建議，歡迎討論~