一：場景

20w的QPS的場景下，服務端架構應如何設計？

二：常規解決方案

可使用分佈式緩存來抗，比如redis集羣，6主6從，主提供讀寫，從作為備，不提供讀寫服務。1台平均抗3w併發，還可以抗住，如果QPS達到100w,通過增加redis集羣中的機器數量，可以擴展緩存的容量和併發讀寫能力。同時，緩存數據對於應用來講都是共享的，主從架構，實現高可用。

三：如何解決緩存熱點（熱key）問題

但是如果出現緩存熱點，比如10w流量來自同一個key，打到同一個redis實例，那麼就有可能出現CPU被打滿，這種增加redis集羣數量解決不了問題。

本地緩存可以解決熱key問題，主要原因是本地緩存可以避免redis單台緩存服務器的高負載。通過複製多份緩存副本，將請求分散到多個緩存服務器上，可以減輕緩存熱點導致的單台緩存服務器壓力。此外，本地內存緩存也具有更快的訪問速度，因為數據存儲在應用程序的內存中，無需跨網絡傳輸數據。

四：通用多級緩存方案

請求優先打到應用本地緩存，本地緩存不存在，再去r2m(redis)集羣拉取，同時緩存到本地

五：多級緩存同步方案

1 運營後台保存數據，寫入r2m緩存，同時通過redis的發佈訂閲功能發佈消息

2 本地應用集羣作為消息訂閲者，接受消息後，刪除本地緩存，C端流量請求打過來的時候，如果本地緩存不存在，則將r2m中緩存加載到本地緩存。

3 定時任務是防止極端情況下，r2m緩存失效，將數據重新加載到r2m緩存。

六：緩存同步組件選型

採用redis的發佈訂閲。

Redis的發佈訂閲模式是推模式。在Redis中，SUBSCRIBE命令用於訂閲一個或多個頻道，以便在有消息發佈到這些頻道時接收通知。PUBLISH命令用於向一個或多個頻道發佈消息。當有消息發佈到某個頻道時，所有訂閲該頻道的客户端都會收到該消息。在推模式下，每個頻道維護一個客户端列表，發送消息時遍歷該列表將消息推送給所有訂閲者。拉模式則相反，發送者將消息放到一個郵箱中，所有訂閲這個郵箱的客户端可以在任意時刻去收取。確保所有客户端都成功收取完整的郵件後，才刪除該郵件。

Redis的發佈訂閲是異步的。當有消息發佈到某個頻道時，Redis會異步地將消息推送給所有訂閲該頻道的客户端。這意味着，客户端不會阻塞等待消息，而是繼續執行其他任務，直到需要接收消息時才會去獲取。這種異步方式可以提高系統的併發性和效率。

七：使用本地緩存注意事項

1 本地緩存佔用java進程的jvm內存空間，故不能進行大數據量存儲，需要進行緩存大小評估。

2 業務能接受短暫數據的不一致，更適用於讀場景。

3 緩存更新策略，主動更新和被動更新，本地緩存一定要設置有效期

4 定時任務同步緩存機制，根據業務情況考慮極端情況數據丟失

5 rpc調用避免本地緩存污染，可通過深拷貝解決。

6 本地緩存隨着應用重啓而失效，注意加載分佈式緩存時機

7 redis的pub,sub模式更新緩存策略（刪除本地緩存key，避免在pub,sub模式下傳遞大value,pub,sub模式不會持久化消息數據，導致消費者對應redis的緩衝區超限，從而導致數據丟失）,本地緩存失效時，加鎖synchronized，由一個線程加載r2m緩存，避免併發更新。

備註：r2m底層由redis實現。

作者：京東科技 張石磊

來源：京東雲開發者社區