一：場景
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實作，
作者：京東科技 張石磊
來源：京東云開發者社區
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/557064.html
標籤：架構設計
上一篇：重溫設計模式 --- 原型模式
下一篇：返回列表