後端設計中，常常有一種場景，就是關係類的儲存。比如訂閱或者關注等。就以關注為例。
通常來說，記錄關注關係，需要落地到db，那麼表結構大概是怎樣的？
很容易想到的乙個表結構：
id：自增id；
userid：被關注使用者id；
followerid：關注使用者id
核心資訊其實就這幾個。這個表可以解決簡單的場景。
但是當資料量越來越大，可能需要搞快取。那麼快取怎麼存？第一反應應該是乙個set。並且，對於關係類的查詢，應該需要兩個快取。乙個查某乙個使用者關注的人（關注列表），另乙個查某乙個使用者被哪些人關注（粉絲列表）。這倆快取都是可以從上述db裡面回源到。
（這裡也反映了關係型資料庫和物件模型的區別）
有了快取又可以支援一定的請求量了。
但是終究有一天db還是扛不住。可能需要分表。這時就有問題了，如果我按照userid分表，那麼只能查詢某乙個使用者被哪些人關注了（粉絲列表）。如果我要查關注列表只能遍歷所有的分表。所以，只能再搞乙個db，原來的按照userid分表，查粉絲列表。新的db按照followerid分表，用來查詢關注列表。
這個設計應該是可以滿足絕大多數場景了。
所以對於關係類的儲存，設計上可能需要兩份快取和db。
技術與業務的關係
乙個公司裡面，真正值錢的東西，不是技術，而是業務知識，技術是實現業務的一種手段，是為業務服務的，主從關係，不可搞錯 從技術角度，追求的不再是純粹的技巧，而是方法這個層次，努力尋求正確的做事方法。即關心 怎樣才能蓋出好房子 而不是 如何把石頭從貨車裡搬運到工地上 用流行的話說，就是 只要方法正確，結果...
業務快取設計
對於優化 速度，快取有 cdn，js及靜態資源檔案快取。資料庫快取，資料對映層快取 mybatis 以及業務層快取。快取能提高訪問速度，但也會造成 邏輯複雜度的增加。通常快取對於非實時性的可以選擇失效時間，對於實時性要求較高的則最好採用事件式更新。使用快取時，一致性很重要，這樣就涉及到不能用類似eh...
業務層設計
專案架構設計，主要考慮的就是後期維護和可擴充套件性 目前主流的設計 連線資料庫 通過乙個類對映表 通過dao，對對映類操作實現表的增刪改查，通過業務層，對多個dao操作，實現業務 業務層 現實中，乙個業務肯定會使用多個表的，所以在dao層設計就不合適，比如 的乙個訂單，不 僅僅訂單變化了就行，還要使...