基於Redis的訊息中心快取搭建

在以往的經歷中出現了在大批使用者湧入訊息中心時，造成資料庫負載急劇公升高的問題，經過排查，發現原因主要有以下幾點：

訊息中心相關表中，部分體量較大的資料表沒有建立索引，查詢操作中資料庫連線不能及時釋放，導致api伺服器不能及時響應，拖垮api伺服器；

目前的訪問量級對訊息中心沒有做資料庫的讀寫分離，導致在缺失索引的情況下，影響主庫效能，拖累其他業務；

結合資料庫日誌，補全訊息中心索引；

對訊息中心資料庫進行讀寫分離操作，降低主庫壓力；

在完成上述改造後，仍然有部分較為嚴重的問題，比如：

在傳送真對全量使用者的佈告板訊息時，在僅依靠資料庫的前提下，採用為每個使用者插入相同的訊息來處理，從而導致資料庫中無效資料的增多。(需求方不允許單獨拆分出公告訊息，需將公告訊息合併至系統訊息中)

對於一些活動推廣訊息，增加使用者組概念，即：對於推廣訊息，不用的使用者查詢到的推廣訊息的內容不同，依賴資料庫進行使用者分組的查詢，即使在建立索引的情況下，仍會導致查詢開銷的急劇增長；

對於推廣訊息，支援多**等富文字格式，依賴資料庫查詢，在做推廣活動時，可能會導致資料庫負載明顯公升高；

類似於**的訊息中心，主要體現在如下幾點：

推廣訊息分使用者組進行檢視；

推廣訊息詳情支援多**；

基於上述需求單獨依賴資料庫的話，查詢或者更新的開銷均較大，因此對訊息中心進行快取改造，由於目前公司的業務需求，快取系統基於redis，為了增強快取中內容的可讀性，快取中存放類的資訊是採用json格式，其使用的第三方json為阿里的fastjson;

每個使用者均訂閱4個訊息概要序列，使用的redis資料型別為zset（有序集合），採用zset的原因為：（1）zset可以進行排重操作，避免對同乙個使用者出現相同的id；（2）zset中的score值可以用於排序操作，避免使用者單個序列中的亂序問題；

以上訊息的詳情儲存在乙個map中，其中map的key為」prefix + id」，value為該訊息的詳細資訊的json串;

查詢訊息的操作流程如下圖：

新增訊息操作：新增訊息時候，需要同時更新兩個快取：概要資訊和詳細資訊，按照以上提到的結構進行儲存即可

與常規資訊不通，佈告板訊息由運營人員進行相應的配置，主要為訊息的展示時間和訊息可見的使用者組；並且在使用者查詢系統訊息時，需要檢測佈告板是否有更新，並同步到系統訊息列表中，因此在本節中，快取中需要維護乙個針對應用的佈告板訊息的有序列表，並為每個使用者維護乙個系統訊息的訂閱列表；其主要思想如下：

快取中維護乙個佈告板訊息配置的zset：bulletin_notification_congfig，其中value為bulletin_id_usergroupid，score為display_time

快取中維護乙個佈告板訊息相信資訊的map，其中key為bulletin_id_usergroupid，value為佈告板詳細資訊的json格式；

快取中為每個使用者維護乙個系統訊息的訂閱列表，也是zset格式，其中value為system_id，score為訊息產生的timestamp；

系統訊息的詳細內容與常規訊息的內容map一起維護，其key值為」system_id」，value為系統訊息的詳細內容的json；

快取中維護乙個鍵值對bulletin:update:time，其值為佈告板訊息更新的timestamp；

快取中為每個使用者維護乙個鍵值對bulletin:access:time:，其值為使用者上次訪問佈告板的timestamp；

查詢訊息的操作流程如下：

繼續進行中。。。這兩天補全。。。。

8. 更新訊息的操作流程如下：