如何最佳化快取中百萬級併發的KEY，其實就是如何應對快取中的熱key問題，也是面試中大家經常被問到的一道面試題。大家在網上可以搜尋“redis熱key問題”便可以看到很多關於這方面的解答。
我們正常使用redis，最簡單的方案就是先從redis查詢某個key，key不在的時候就去資料庫查詢，資料庫查詢到資料後，返回的同時將資料載入到redis中，下次同樣的訪問請求直接從redis獲取就可以了，請求流程圖如下：
這樣的方式在量不大的時候都沒有問題，但是如果量大了就有問題了，潛在的問題有：
快取穿透：redis不存在，資料庫也沒有，每次請求都走資料庫了，資料庫承載所有請求壓力，嚴重導致資料庫宕機。
快取雪崩：同一個時間段內，大量快取過期，導致所有請求同時懟到db上，db無法承載，導致宕機。
redis熱key問題：大量請求都只請求一個特定的key，導致單臺redis流量承載超過頻寬上限和I/O負載極限，最終導致redis無法響應，redis無法響應會直接導致所有請求失敗或者請求到資料庫伺服器，最終資料庫宕機。
這個其實還是比較簡單的，大家都能想到一些方案，比如有的業務天生就帶有高併發屬性，那麼你在做方案設計的時候就要考慮熱點key的問題，比如商品的秒殺業務。
研發資源比較充足的公司通常都會做一套健全的機制去發現熱key，發現之後再根據熱key的等級做相應的處理方案。大家也可以自己想想，如果讓你來設計這個熱key發現機制你會用什麼方案？
aop統計、nginx閘道器統計、實時計算統計-->告警-->處理方案
瞭解到了問題產生的原因和背景之後，相信大家或多或少都有一些自己的解決方案，我主推：
JVM快取：直接將redis的熱key載入的jvm記憶體中，多臺叢集伺服器下，每臺伺服器都會有這個記憶體快取，只要伺服器能承載住所有請求，這個熱key就沒問題。這種方案最簡單！最直接！最有效！
當然這會有一些問題，比如快取的一致性無法保證，需要看具體的業務場景考慮是否適合使用，或者自己開發一套滿足快取資料一致性的機制。
如果jvm快取都不能滿足你的業務量請求，那麼這是不存在的！
現成的方案：《有贊透明多級快取解決方案（TMC）》
如何最佳化快取中百萬級併發的KEY，其實就是如何應對快取中的熱key問題，也是面試中大家經常被問到的一道面試題。大家在網上可以搜尋“redis熱key問題”便可以看到很多關於這方面的解答。
問題背景我們正常使用redis，最簡單的方案就是先從redis查詢某個key，key不在的時候就去資料庫查詢，資料庫查詢到資料後，返回的同時將資料載入到redis中，下次同樣的訪問請求直接從redis獲取就可以了，請求流程圖如下：
這樣的方式在量不大的時候都沒有問題，但是如果量大了就有問題了，潛在的問題有：
快取穿透：redis不存在，資料庫也沒有，每次請求都走資料庫了，資料庫承載所有請求壓力，嚴重導致資料庫宕機。
快取雪崩：同一個時間段內，大量快取過期，導致所有請求同時懟到db上，db無法承載，導致宕機。
redis熱key問題：大量請求都只請求一個特定的key，導致單臺redis流量承載超過頻寬上限和I/O負載極限，最終導致redis無法響應，redis無法響應會直接導致所有請求失敗或者請求到資料庫伺服器，最終資料庫宕機。
如何發現熱點key這個其實還是比較簡單的，大家都能想到一些方案，比如有的業務天生就帶有高併發屬性，那麼你在做方案設計的時候就要考慮熱點key的問題，比如商品的秒殺業務。
研發資源比較充足的公司通常都會做一套健全的機制去發現熱key，發現之後再根據熱key的等級做相應的處理方案。大家也可以自己想想，如果讓你來設計這個熱key發現機制你會用什麼方案？
aop統計、nginx閘道器統計、實時計算統計-->告警-->處理方案
解決方案瞭解到了問題產生的原因和背景之後，相信大家或多或少都有一些自己的解決方案，我主推：
JVM快取：直接將redis的熱key載入的jvm記憶體中，多臺叢集伺服器下，每臺伺服器都會有這個記憶體快取，只要伺服器能承載住所有請求，這個熱key就沒問題。這種方案最簡單！最直接！最有效！
當然這會有一些問題，比如快取的一致性無法保證，需要看具體的業務場景考慮是否適合使用，或者自己開發一套滿足快取資料一致性的機制。
如果jvm快取都不能滿足你的業務量請求，那麼這是不存在的！
現成的方案：《有贊透明多級快取解決方案（TMC）》
連結：https://segmentfault.com/a/1190000017142556#articleHeader4