快取背景
對於大面積的qps請求 ，傳統的資料庫的讀寫分離已經無法滿足。當資料庫的最大連線數 都達到峰值，這時候如果只是一味的加資料的db機器 也許可以緩解一下db壓力。但是資料庫機器一般都比較貴，從經濟成本上來說，不可取。那麼對於像秒殺這種場景，一段時間的查詢量非常大，活動一結束查詢量就會降下來，該如何是好？這時候自然想到快取系統，提高資料庫的響應時間，同時很多請求不必要再查詢資料庫。
1.快取設計
取自網際網路**
當請求傳送給伺服器的時候，快取找不到，就查詢資料庫裡，同時回寫到快取。當第二次查詢時就可以不用查詢資料庫，直接到快取中取數值了。
2.好了快取設計好了，似乎可以提高資料的併發量了 ，不用加機器了，節約了不少錢，但是這種設計是否是非常完美呢？試想一下，如果資料庫的值變了，快取如何跟著一起更新最新的值呢。
2.快取策略
2.1一般2種方案
更新資料資料時，順便更新一下快取 這樣資料就一直是最新的資料，實際開發中，也許更新資料是有大資料團隊進行更新，用etl等技術來做，redis，人家一臉懵逼啊。這時作為api開發的我們一臉無奈，只能靠自己了。對這就是我要說的第二種方案，redis過期剔除，這樣當快取沒有資料，必然就要去資料庫去查，然後回寫到redis。主動去更新redis的值，開發自己去控制熱點鍵值的生命週期。當然啦，這時資料一致性和維護成本的一中這種方案。
3.測試，上線一切如此很好，可是活動上線的第二天，運維發郵件說，資料庫的負載太高，問我們怎麼回事，這時就一臉懵逼了。資料庫讀寫分離了，同時還用了redis做了快取。怎麼資料庫的負載還會高呢?不行 有圖有真相，我讓運維給出負載高的截圖。ps 其實這時還是拒接接受這個訊息的。 但是人家給出一張圖來，我就折服了 高負載都是在某點出現。後來我想了 想 終於知道原因了。***還能這麼玩 ，給一張圖你們自行體會。
3.快取入坑
快取大量沒命中。。。。。。。。看了一下日誌，好幾個ip的使用者居然24小時在請求查詢操作。據我經驗判斷，這些使用者應該就是爬蟲的。上午緊急寫了乙個限流攔截，同時檢查了一下**，不看不知道 看了嚇一跳，同事寫儲存時有漏洞。對於查詢資料庫也沒有的資料的情況，沒做處理。假設使用者請求很多無用的key，同樣會查詢資料庫。檢視日誌，發現就有乙個ip使用者這麼幹的 不停的換key，流量攻擊我們的系統。我思考了一會兒，這些資料庫查詢不到的資料，value值就給null，諮詢了一下產品，對資料實時性要求不是很高。對就這麼幹。剛寫完**，測試說你這5分鐘過期，要是同一時間請求，到下乙個時間點又同時請求，剛好時間點時過期時間怎麼辦？恩 有道理。我趕緊和同事說這個事情，最終決定 在無效key設定過期時間時用隨機數。這樣就可以空間換時間了。到下午緊急上線。活動持續三天 ，一切很完美。各項指標正常
這裡的指標指 我們的api監控系統 主要是1業務響應時間2.介面總呼叫數3快取命中數4資料庫查詢次數
後續 熱點key的重建優化
快取更新策略
一般來說，快取有以下三種模式 cache aside更新模式 這種策略下，在併發寫的時候可能會出現髒資料的問題。read write through 更新模式 在read write through 更新模式中，應用程式只需要維護快取，資料庫的維護工作由快取 了。read through 模式就是在...
快取更新策略初探
這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把快取cache中的資料也修改了呢？主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致髒資料，舉個例子 那麼 cache aside 模式就沒有髒資料問題了嗎？不是的，在極端情況下也可能會產生髒資料，比如 不過這種概率比上面一種概率...
Mysql 之 快取更新策略
業務角度，對於讀操作很少的，造成效能浪費 執行緒安全角度，容易產生資料髒讀 執行緒a更新了資料庫，執行緒b更新了資料庫，b更新了快取，a更新了快取 錯誤情況 請求a進行寫操作，刪除快取 請求b查詢發現快取不存在，讀取資料庫，寫入快取 請求a將資料寫入資料庫 解決方法 採用延時雙刪除法 在a寫入資料庫...