dw做的個人網(wǎng)站,免費做計算機題的網(wǎng)站,創(chuàng)建自己的博客網(wǎng)站嗎,哈爾濱模板建站定制網(wǎng)站1. 名詞解釋緩存預熱#xff1a;在系統(tǒng)上線前后或流量激增前#xff08;如大促活動#xff09;#xff0c;主動地將提前預測出的熱點數(shù)據(jù)加載到緩存中#xff0c;而不是等待用戶請求來觸發(fā)緩存寫入。避免初期洪峰壓垮數(shù)據(jù)庫。緩存穿透#xff1a;用戶查詢一個根本不存在于…1. 名詞解釋緩存預熱在系統(tǒng)上線前后或流量激增前如大促活動主動地將提前預測出的熱點數(shù)據(jù)加載到緩存中而不是等待用戶請求來觸發(fā)緩存寫入。避免初期洪峰壓垮數(shù)據(jù)庫。緩存穿透用戶查詢一個根本不存在于數(shù)據(jù)庫中和緩存中的數(shù)據(jù)。由于緩存中不存在每次請求都會穿透到數(shù)據(jù)庫去查詢。如果有人惡意攻擊用大量不存在的 Key 進行請求就會給數(shù)據(jù)庫造成巨大壓力。解決1. 做好接口校驗對于明顯不合法的ID如負數(shù)、非數(shù)字字符直接攔截返回?；蚴褂貌悸∵^濾器。2. 緩存空對象。即使從數(shù)據(jù)庫沒查到也將空結果進行緩存。這樣短期內(nèi)再請求同一個不存在的 key會直接返回空而不會訪問數(shù)據(jù)庫。緩存雪崩在某一時刻大量的緩存數(shù)據(jù)同時過期。此時請求全部涌向數(shù)據(jù)庫導致數(shù)據(jù)庫瞬時壓力過大而崩潰。這有可能是因為一部分 key 被設置了相同的過期時間也有可能是 Redis 服務宕機。解決1. 設置隨機過期時間。2. 使用 Redis 哨兵或集群避免單點問題構建高可用 Redis 集群。緩存擊穿某個熱點 Key 在緩存中過期的瞬間同時有海量請求對這個 Key 進行訪問。這個 Key 的失效像一顆子彈在緩存上擊穿了一個洞所有請求都從這個洞穿透到數(shù)據(jù)庫導致數(shù)據(jù)庫瞬間壓力激增。解決1. 對于極少數(shù)超級熱點數(shù)據(jù)可以設置為永不過期。2. 使用分布式鎖。當請求發(fā)現(xiàn)緩存失效不能直接查數(shù)據(jù)庫必須先去獲取一個分布式鎖獲取到鎖的進程去查庫重建緩存。2. 緩存淘汰策略1. 先進先出淘汰緩存中存在時間最久的數(shù)據(jù)。2. 淘汰最長時間沒用過的。3. 淘汰最不常用的。4. 隨機淘汰一個。Redis 內(nèi)置的緩存淘汰策略基本沿用上面的場景策略只不過針對帶有過期時間的 key 做了區(qū)分我們可以選擇只淘汰有過期時間的 key。默認策略是不自動淘汰數(shù)據(jù)當內(nèi)存不足時新寫入操作會報錯。3. 旁路緩存模式在旁路緩存模式中應用程序的讀寫邏輯如下讀先讀緩存緩存命中則返回數(shù)據(jù)緩存未命中則從數(shù)據(jù)庫讀取寫入緩存然后返回數(shù)據(jù)。寫更新數(shù)據(jù)庫然后將緩存中對應的數(shù)據(jù)項刪除注意這里是刪除而不是更新。3.1為什么是刪除緩存1. 避免并發(fā)寫問題在更新緩存策略下如果兩個寫操作并發(fā)執(zhí)行由于網(wǎng)絡延遲等原因它們更新緩存的操作順序可能與更新數(shù)據(jù)庫的順序不一致從而導致緩存中是舊數(shù)據(jù)。比如 A 更新數(shù)據(jù)庫然后 B 更新數(shù)據(jù)庫然后 B 更新緩存最后 A 更新緩存。此時數(shù)據(jù)庫中的數(shù)據(jù)是 A 更新后 B 又更新后的數(shù)據(jù)而緩存中的數(shù)據(jù)只是 A 更新后的數(shù)據(jù)因為 B 的更新被覆蓋了。如果是刪除緩存則最終一定能保證緩存是被清空的。下一個讀請求會因為緩存未命中而從數(shù)據(jù)庫讀取最新的值并重新填充緩存這就保證了最終一致性。2. 降低寫操作負載如果采用更新緩存策略則每次寫操作都會更新緩存。更新緩存需要將完整的數(shù)據(jù)對象序列化并寫入緩存而刪除緩存只需要一個簡單的 DEL 命令。3. 避免寫入冷門數(shù)據(jù)需要更新的數(shù)據(jù)并不一定是熱點數(shù)據(jù)若該數(shù)據(jù)被更新后很長一段時間都不會再讀取那么該次緩存更新就是浪費的。而刪除緩存是惰性的只有在真正需要時即下次讀取時才將數(shù)據(jù)加載到緩存中這樣緩存中保留的都是熱點數(shù)據(jù)。但更新緩存策略在特定場景下也有它的優(yōu)勢。如果在某場景下已知該數(shù)據(jù)將被持續(xù)高并發(fā)地讀取希望盡可能避免任何一次請求穿透到數(shù)據(jù)庫。使用更新緩存可以確保寫之后緩存總是可用的。但此時需要通過分布式鎖等手段來解決并發(fā)寫問題這會增加系統(tǒng)復雜度。3.2 另外的一致性問題如果 A 查詢緩存未命中開始查數(shù)據(jù)庫。隨后 B 更新數(shù)據(jù)庫中的數(shù)據(jù)并刪緩存。A 查到的是 B 更新前的數(shù)據(jù)將舊數(shù)據(jù)寫入緩存造成數(shù)據(jù)不一致。其實這個問題嚴格來說也不能叫讀寫并發(fā)問題因為它涉及到寫緩存了。這個問題概括起來就是說一個線程想用從 DB 查出來的數(shù)據(jù)寫緩存在這個時間窗口內(nèi)另一個線程已經(jīng)把這個數(shù)據(jù)在 DB 改了。這里的關鍵問題其實是A 線程感知不到 B 線程是否修改過緩存因為刪除空值相當于沒刪。這個問題最直接的解決方法就是從我查 DB 到寫緩存的這個時間排斥一切寫操作。也就是使用分布式鎖這里可以使用讀寫鎖以 key 為粒度加鎖。如果不想加鎖還有下面兩種方案1. 延遲雙刪寫操作中第一次刪除緩存后等一小段時間再刪除一次。2. 為緩存設置較短的過期時間即使發(fā)生上述情況舊數(shù)據(jù)也會在一定時間后自動失效實現(xiàn)最終一致。過期時間設置較短確實數(shù)據(jù)一致性會變高但緩存命中率也會變低因此還是要根據(jù)實際業(yè)務做出權衡設置合理的過期時間。4. Redis 實現(xiàn)簡易分布式鎖只要涉及到多個線程或進程訪問同一公共資源都會涉及到使用鎖做同步控制。在分布式系統(tǒng)下需要使用分布式鎖。分布式鎖就是使用一個或一組服務器專門用于記錄加鎖狀態(tài)。思路就是用一個鍵值對來標識鎖的狀態(tài)。例如對于一個商品下單的接口通常是先校驗庫存若庫存為 0返回下單失敗若庫存大于 0將庫存減去下單數(shù)量再返回下單成功。很明顯這些操作必須打包成原子操作。此時收到請求的服務器必須先向鎖服務器申請鎖即在 Redis 上設置一個鍵值對SET key value NX PX(毫秒)|EX(秒) timeoutkey - 資源 IDvalue - 服務器 ID用于保證只有鎖的持有者才能釋放它。在代碼中刪除 key 之前加上對該 ID 的校驗只有它的確是當初加鎖的服務器才能刪除。NX - 當且僅當 key 不存在時才能設置成功這是實現(xiàn)分布式鎖的核心字段PX|EX - 為了防止客戶端崩潰后鎖永遠無法釋放必須為鎖設置一個過期時間。只有設置該鍵值對成功才能訪問共享數(shù)據(jù)訪問之后在通過服務器 ID 校驗后使用 DEL 指令刪除該 key。檢查鎖所有權 和 刪除鎖 之間的時間窗口內(nèi)鎖的所有權有極小概率發(fā)生變化如下圖。為了確保萬無一失還是要將這兩步打包成原子操作用 lua 腳本執(zhí)行。此時SET 只是一行命令天然保證原子性刪除時也能通過 lua 腳本保證原子性。實際上憑感覺設置過期時間是不靠譜的如果設置太短鎖有可能提前失效如果設置太長其他服務器不能及時獲取到鎖。我們必須能比較精確地控制這個過期時間也就是監(jiān)視服務器的任務執(zhí)行情況。因此我們可以先為鎖設置一個較短的超時時間隨后啟動一個后臺線程稱為看門狗Watch Dog定期去檢測服務器的任務執(zhí)行情況。若檢測到其未完成任務則重置超時時間續(xù)約。對于更極端的情況可能需要集群部署分布式鎖。如果當前 Redis 鎖服務器是主從結構從節(jié)點對主節(jié)點可能存在一定的數(shù)據(jù)延遲如果鎖信息還未同步給從節(jié)點主節(jié)點就宕機了鎖信息就會丟失。因此如果想保證鎖的更高可用性還是要使用多個主節(jié)點。加鎖時向每個主節(jié)點都要 SET key判定鎖是否加成功依然要遵守半數(shù)以上原則這樣就不會因為個別主節(jié)點的加鎖失敗而導致整體鎖服務不可用。釋放鎖的時候也要把所有主節(jié)點都進行解鎖判定解鎖是否成功也要遵守半數(shù)以上原則。上面的模式稱為 Redlock 算法其思想就是避免單點問題不能只寫一個主節(jié)點要寫多個加鎖成功的結論一定是 “少數(shù)服從多數(shù)” 的而不是只聽一個節(jié)點的。上面只是基于 Redis 實現(xiàn)分布式鎖的一些最基本的原理實際上我們也不會在業(yè)務中自己實現(xiàn)分布式鎖使用現(xiàn)成的工具如 Java 的 Redission 是更好的選擇。