摘要:比如消息小明喜歡了文章則文章指明所屬類型是文章小明當然,還支持存儲公告和信息。如小明關注了產(chǎn)品的評論,數(shù)據(jù)表現(xiàn)為產(chǎn)品的小明的這樣,產(chǎn)品下產(chǎn)生的每一條評論,都會產(chǎn)生通知給小明了。
模型設計 Notify原文鏈接:BlueSun | 消息系統(tǒng)設計與實現(xiàn)「上篇」
id : {type: "integer", primaryKey: true}, // 主鍵 content : {type: "text"}, // 消息的內(nèi)容 type : {type: "integer", required: true, enum: [1, 2, 3]}, // 消息的類型,1: 公告 Announce,2: 提醒 Remind,3:信息 Message target : {type: "integer"}, // 目標的ID targetType : {type: "string"}, // 目標的類型 action : {type: "string"}, // 提醒信息的動作類型 sender : {type: "integer"}, // 發(fā)送者的ID createdAt : {type: "datetime", required: true}
Save Remind
消息表,我們需要target、targetType字段,來記錄該條提醒所關聯(lián)的對象。而action字段,則記錄該條提醒所關聯(lián)的動作。
比如消息:「小明喜歡了文章」
則:
target = 123, // 文章ID targetType = "post", // 指明target所屬類型是文章 sender = 123456 // 小明ID
Save Announce and Message
當然,Notify還支持存儲公告和信息。它們會用到content字段,而不會用到target、targetType、action字段。
id : {type: "integer", primaryKey: true}, // 主鍵 isRead : {type: "boolean", required: true}, user : {type: "integer", required: true}, // 用戶消息所屬者 notify : {type: "integer", required: true} // 關聯(lián)的Notify createdAt : {type: "datetime", required: true}
我們用UserNotify來存儲用戶的消息隊列,它關聯(lián)一則提醒(Notify)的具體內(nèi)容。
UserNotify的創(chuàng)建,主要通過兩個途徑:
遍歷訂閱(Subscription)表拉取公告(Announce)和提醒(Remind)的時候創(chuàng)建
新建信息(Message)之后,立刻創(chuàng)建。
Subscriptiontarget : {type: "integer", required: true}, // 目標的ID targetType : {type: "string", required: true}, // 目標的類型 action : {type: "string"}, // 訂閱動作,如: comment/like/post/update etc. user : {type: "integer"}, createdAt : {type: "datetime", required: true}
訂閱,是從Notify表拉取消息到UserNotify的前提,用戶首先訂閱了某一個目標的某一個動作,在此之后產(chǎn)生這個目標的這個動作的消息,才會被通知到該用戶。
如:「小明關注了產(chǎn)品A的評論」,數(shù)據(jù)表現(xiàn)為:
target: 123, // 產(chǎn)品A的ID targetType: "product", action: "comment", user: 123 // 小明的ID
這樣,產(chǎn)品A下產(chǎn)生的每一條評論,都會產(chǎn)生通知給小明了。
SubscriptionConfigaction: {type: "json", required: true}, // 用戶的設置 user: {type: "integer"}
不同用戶可能會有不一樣的訂閱習慣,在這個表中,用戶可以統(tǒng)一針對某種動作進行是否訂閱的設置。而默認是使用系統(tǒng)提供的默認配置:
defaultSubscriptionConfig: { "comment" : true, // 評論 "like" : true, // 喜歡 }
配置文件 NotifyConfig在這套模型中,targetType、action是可以根據(jù)需求來擴展的,例如我們還可以增加多幾個動作的提醒:hate被踩、update被更新....諸如此類。
// 提醒關聯(lián)的目標類型 targetType: { PRODUCT : "product", // 產(chǎn)品 POST : "post" // 文章 }, // 提醒關聯(lián)的動作 action: { COMMENT : "comment", // 評論 LIKE : "like", // 喜歡 }, // 訂閱原因?qū)嗛喪录?reasonAction: { "create_product" : ["comment", "like"] "like_product" : ["comment"], "like_post" : ["comment"], }, // 默認訂閱配置 defaultSubscriptionConfig: { "comment" : true, // 評論 "like" : true, // 喜歡 }服務層 NotifyService NotifyService擁有以下方法:
createAnnounce(content, sender)
createRemind(target, targetType, action, sender, content)
createMessage(content, sender, receiver)
pullAnnounce(user)
pullRemind(user)
subscribe(user, target, targetType, reason)
cancelSubscription(user, target ,targetType)
getSubscriptionConfig(userID)
updateSubscriptionConfig(userID)
getUserNotify(userID)
read(user, notifyIDs)
各方法的處理邏輯如下:createAnnounce(content, sender)
往Notify表中插入一條公告記錄
createRemind(target, targetType, action, sender, content)
往Notify表中插入一條提醒記錄
createMessage(content, sender, receiver)
往Notify表中插入一條信息記錄
往UserNotify表中插入一條記錄,并關聯(lián)新建的Notify
pullAnnounce(user)
從UserNotify中獲取最近的一條公告信息的創(chuàng)建時間: lastTime
用lastTime作為過濾條件,查詢Notify的公告信息
新建UserNotify并關聯(lián)查詢出來的公告信息
pullRemind(user)
查詢用戶的訂閱表,得到用戶的一系列訂閱記錄
通過每一條的訂閱記錄的target、targetType、action、createdAt去查詢Notify表,獲取訂閱的Notify記錄。(注意訂閱時間必須早于提醒創(chuàng)建時間)
查詢用戶的配置文件SubscriptionConfig,如果沒有則使用默認的配置DefaultSubscriptionConfig
使用訂閱配置,過濾查詢出來的Notify
使用過濾好的Notify作為關聯(lián)新建UserNotify
subscribe(user, target, targetType, reason)
通過reason,查詢NotifyConfig,獲取對應的動作組:actions
遍歷動作組,每一個動作新建一則Subscription記錄
cancelSubscription(user, target ,targetType)
刪除user、target、targetType對應的一則或多則記錄
getSubscriptionConfig(userID)
查詢SubscriptionConfig表,獲取用戶的訂閱配置
updateSubscriptionConfig(userID)
更新用戶的SubscriptionConfig記錄
getUserNotify(userID)
獲取用戶的消息列表
read(user, notifyIDs)
更新指定的notify,把isRead屬性設置為true
時序圖 提醒的訂閱、創(chuàng)建、拉取我們可以在產(chǎn)品創(chuàng)建之后,調(diào)用NotifyService.subscribe方法,
然后在產(chǎn)品被評論之后調(diào)用NotifyService.createRemind方法,
再就是用戶登錄系統(tǒng)或者其他的某一個時刻調(diào)用NotifyService.pullRemind方法,
最后在用戶查詢消息隊列的時候調(diào)用NotifyService.getUserNotify方法。
在管理員發(fā)送了一則公告的時候,調(diào)用NotifyService.createAnnounce方法,
然后在用戶登錄系統(tǒng)或者其他的某一個時刻調(diào)用NotifyService.pullAnnounce方法,
最后在用戶查詢消息隊列的時候調(diào)用NotifyService.getUserNotify方法。
信息的創(chuàng)建,只需要直接調(diào)用NotifyService.createMessage方法就可以了,
在下一次用戶查詢消息隊列的時候,就會查詢這條信息。
如果本文對您有用
請不要吝嗇你們的Follow與Start
這會大大支持我們繼續(xù)創(chuàng)作
「Github」
MZMonster :@MZMonster
JC_Huang :@JerryC8080
文章版權歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/78924.html
摘要:原文鏈接消息系統(tǒng)設計與實現(xiàn)上篇由于文章篇幅較長,而作者精力有限,不希望這么早就精盡人亡,故分成上下篇來寫消息系統(tǒng)的設計與實現(xiàn)。更新于關聯(lián)文章消息系統(tǒng)設計與實現(xiàn)下篇如果本文對您有用請不要吝嗇你們的與這會大大支持我們繼續(xù)創(chuàng)作 原文鏈接:Bluesun | 消息系統(tǒng)設計與實現(xiàn)「上篇」 由于文章篇幅較長,而作者精力有限,不希望這么早就精盡人亡,故分成上下篇來寫消息系統(tǒng)的設計與實現(xiàn)。上篇主要講...
摘要:原文從零到一,擼一個在線斗地主下篇作者上篇回顧我們說了斗地主游戲的渲染展示部分,最后也講了下中交互的情況,下篇的重點就是游戲邏輯。 原文:從零到一,擼一個在線斗地主(下篇) | AlloyTeam作者:TAT.vorshen 上篇回顧:我們說了斗地主游戲的渲染展示部分,最后也講了下canvas中交互的情況,下篇的重點就是游戲邏輯。 邏輯主要分成兩塊:流程邏輯和撲克牌對比邏輯。 gith...
摘要:前言架構是一款軟件從到的演變過程。并非是上來就可以承載什么億級訪問的牛架構什么的。這是軟性架構,考慮擴展性。實際程序員與架構師不分家。設計架構設計覆蓋一款應用運行的各個方面。架構并不是一個多么神秘的職業(yè)。雖然敵不過大廠的架構。 showImg(https://segmentfault.com/img/bVbf3Tg?w=1080&h=708); 前言 架構是一款軟件從0到100的演變過...
摘要:前言架構是一款軟件從到的演變過程。并非是上來就可以承載什么億級訪問的牛架構什么的。這是軟性架構,考慮擴展性。實際程序員與架構師不分家。設計架構設計覆蓋一款應用運行的各個方面。架構并不是一個多么神秘的職業(yè)。雖然敵不過大廠的架構。 showImg(https://segmentfault.com/img/bVbf3Tg?w=1080&h=708); 前言 架構是一款軟件從0到100的演變過...
摘要:前言架構是一款軟件從到的演變過程。并非是上來就可以承載什么億級訪問的牛架構什么的。這是軟性架構,考慮擴展性。實際程序員與架構師不分家。設計架構設計覆蓋一款應用運行的各個方面。架構并不是一個多么神秘的職業(yè)。雖然敵不過大廠的架構。 showImg(https://segmentfault.com/img/bVbf3Tg?w=1080&h=708); 前言 架構是一款軟件從0到100的演變過...
閱讀 3462·2021-09-08 09:36
閱讀 2550·2019-08-30 15:54
閱讀 2352·2019-08-30 15:54
閱讀 1768·2019-08-30 15:44
閱讀 2390·2019-08-26 14:04
閱讀 2443·2019-08-26 14:01
閱讀 2877·2019-08-26 13:58
閱讀 1328·2019-08-26 13:47