需求
類似微信公眾號通知中心，但這里主要講的是對系統所有人發送系統通知，簡單需求描述如下
1、有新通知時，通知圖標右上角小紅點提醒
2、通知列表頁，通知狀態分為已讀和未讀，未讀的標題前面要有小紅點提示。
數據表設計
很簡單，沒有中間表，是因為未讀的通知id都放在了未讀通知字段中，以英文逗號分割。
推模式與拉模式
一般獲取消息的模式分為兩種，既推（push）模式和拉（pull）模式。
對於數據庫表設計來說，我覺得也可以分為推、拉兩種模式。
推模式：當管理員發送系統通知之后，遍歷用戶表寫通知，相當於對每個用戶都在通知表中保存了一份通知消息，在小規模系統上，是可行的，但是用戶基數很大的話，會占用大量的存儲空間，並且這些空間存儲的內容幾乎一樣。
拉模式：當管理員發送系統通知之后，保存這條消息到通知表中，發布通知的流程就結束了。用戶在登陸之后，附帶上最近一次登錄的時間戳，去請求服務端是否有新的系統通知，如果有，那么獲取新通知，寫入未讀通知字段中，只要存在未讀通知，通知圖標右上角的小紅點就提醒。
所以，對於系統通知這類需求，拉模式是再適合不過的了。
核心邏輯
對於請求流程來說，可以在用戶登錄進行，也可以在用戶點擊通知列表頁的時候進行，同時加入一個系統通知發布時間全局變量判斷。
我們以用戶點擊通知列表頁的時候進行為例：
1、用戶登錄時，上一次登陸時間、未讀通知字段是一同返回的，然后保存在localStorage中，與系統通知發布時間全局變量對比，判斷是否需要圖標的紅點提示。
if (last_login_time < last_notification_time || unread_ notification != '')
{
//提醒未讀
}2、用戶附帶上最近一次登錄的時間戳，去請求服務端是否有新的系統通知，追加寫入未讀通知字段中，以英文逗號分割，例如1,2,3，表示id為1,2,3的系統通知，該用戶未讀。服務端同時返回未讀通知id，前端localStorage中追加寫入。
3、請求通知列表頁，前端根據所保存的未讀通知id，判斷是否要標記顯示為未讀。
4、用戶點擊閱讀通知，從未讀通知id中去除當前通知id，請求服務端同步數據。
至此，我們實現了一個精簡的系統通知模塊。