緩存
rocksdb 本地緩存 ，無網絡訪問，磁盤容量大，可以做緩存兜底，服務失敗兜底以及大數據量緩存使用
redis 分佈式緩存 ，具有極高的讀寫性能，具有分佈式鎖等同步方式使用。
需要緩存的數據
發送者信息
接受者信息
消息
消息模板 to 客戶端
比如說 私信 ， 發送私信的時候 ，發送者的個人信息 ，接受者的個人信息 在半小時之內可以緩存。必然會有多次用戶信息訪問，比如接受者是否在線 。 發送方暱稱等 。（點贊，關注，回覆都是一樣的）
歷史消息 這塊 ，用戶通常會下拉查詢歷史消息 。這塊我們雖然分表的方式降低了查詢成本 。爲什麼不把查詢數據緩存到緩存中， 後面指定時間內，直接在緩存中查詢呢
未讀消息，在會話列表接口被調用的時候，是否可以將部分會話的未讀消息直接加載到緩存 ，設置半小時過期時間呢。
本質還是在於熱點數據的緩存。減少3方訪問以及壓力 ，但是第一次訪問在所難免
本地緩存使用 - 即便依賴服務不可用 ，我們也要儘量兜底提供服務。
本地緩存 可以做緩存，以及服務調用失敗兜底使用 ，比如j2 pod 掛掉了或者redis 服務 短時間不可用， 可以將rocksdb 個人信息數據取出做兜底，第一次查詢 ，雙寫 redis 以及rocksdb ， rocksdb 的 過期時長 爲redis 過期時長的一倍（1小時） ，3方服務正常，redis 緩存過期時 ，取 3方緩存，同步redis ，rocksdb。
本地緩存有個問題，所有節點都是無狀態的。本地緩存肯定會失效。那麼怎麼解決這個問題呢， 每次redis 或者數據庫成功讀取時，異步同步本地rocksdb。
會有大量硬盤佔用。
千人千面 ，千人一面
業務場景千人千面，拿不到緩存數據的時候 ，rocksdb 也沒有辦法去解決 ，這時候 ，果斷記錄日誌 ，根據當前業務場景，判斷是否可以通過降級服務去提供服務給調用方使用 。比如 我需要用戶nickname ，頭像 ，這時候j2 提供不了服務，緩存中也沒有。 返回數據中我可以將發送方nickname 設置爲兜底數據暱稱 朋友 ，並告知前端。 如果前端也設計了降級措施 。
業務場景 千人一面 ，除了redis，就是rocksdb 。 上面說的很清楚了。