設計 關係類業務

2021-09-26 00:11:41 字數 604 閱讀 3954

後端設計中,常常有一種場景,就是關係類的儲存。比如訂閱或者關注等。就以關注為例。

通常來說,記錄關注關係,需要落地到db,那麼表結構大概是怎樣的?

很容易想到的乙個表結構:

id:自增id;

userid:被關注使用者id;

followerid:關注使用者id

核心資訊其實就這幾個。這個表可以解決簡單的場景。

但是當資料量越來越大,可能需要搞快取。那麼快取怎麼存?第一反應應該是乙個set。並且,對於關係類的查詢,應該需要兩個快取。乙個查某乙個使用者關注的人(關注列表),另乙個查某乙個使用者被哪些人關注(粉絲列表)。這倆快取都是可以從上述db裡面回源到。

(這裡也反映了關係型資料庫和物件模型的區別)

有了快取又可以支援一定的請求量了。

但是終究有一天db還是扛不住。可能需要分表。這時就有問題了,如果我按照userid分表,那麼只能查詢某乙個使用者被哪些人關注了(粉絲列表)。如果我要查關注列表只能遍歷所有的分表。所以,只能再搞乙個db,原來的按照userid分表,查粉絲列表。新的db按照followerid分表,用來查詢關注列表。

這個設計應該是可以滿足絕大多數場景了。

所以對於關係類的儲存,設計上可能需要兩份快取和db。

技術與業務的關係

乙個公司裡面,真正值錢的東西,不是技術,而是業務知識,技術是實現業務的一種手段,是為業務服務的,主從關係,不可搞錯 從技術角度,追求的不再是純粹的技巧,而是方法這個層次,努力尋求正確的做事方法。即關心 怎樣才能蓋出好房子 而不是 如何把石頭從貨車裡搬運到工地上 用流行的話說,就是 只要方法正確,結果...

業務快取設計

對於優化 速度,快取有 cdn,js及靜態資源檔案快取。資料庫快取,資料對映層快取 mybatis 以及業務層快取。快取能提高訪問速度,但也會造成 邏輯複雜度的增加。通常快取對於非實時性的可以選擇失效時間,對於實時性要求較高的則最好採用事件式更新。使用快取時,一致性很重要,這樣就涉及到不能用類似eh...

業務層設計

專案架構設計,主要考慮的就是後期維護和可擴充套件性 目前主流的設計 連線資料庫 通過乙個類對映表 通過dao,對對映類操作實現表的增刪改查,通過業務層,對多個dao操作,實現業務 業務層 現實中,乙個業務肯定會使用多個表的,所以在dao層設計就不合適,比如 的乙個訂單,不 僅僅訂單變化了就行,還要使...