8.1 快取雪崩現象及真實案例
快取雪崩一般是由某個快取節點失效,導致其他節點的快取命中率下降, 快取中缺失的資料
去資料庫查詢.短時間內,造成資料庫伺服器崩潰.
重啟 db,短期又被壓跨,但快取資料也多一些.
db 反覆多次啟動多次,快取重建完畢,db 才穩定執行.
或者,是由於快取週期性的失效,比如每 6 小時失效一次,那麼每 6 小時,將有乙個請求」峰值」,
嚴重者甚至會令 db 崩潰.
把快取設定為隨機3到9小時的生命週期,這樣不同時失效,把工作分擔到各個時間點
上去.或者深夜跑指令碼使快取失效
8.2 快取的無底洞現象 multiget-hole
該問題由 facebook 的工作人員提出的, facebook 在 2010 年左右,memcached 節點就已經達
3000 個.快取數千 g 內容.
他們發現了乙個問題---memcached 連線頻率,效率下降了,於是加 memcached 節點,
新增了後,發現因為連線頻率導致的問題,仍然存在,並沒有好轉,稱之為」無底洞現象」.
原文見:
more-capacit.html
8.2.1 multiget-hole 問題分析
以使用者為例: user-133-age, user-133-name,user-133-height .....n 個 key,
當伺服器增多,133 號使用者的資訊,也被散落在更多的節點,
所以,同樣是訪問個人主頁,得到相同的個人資訊, 節點越多,要連線的節點也越多.
對於 memcached 的連線數,並沒有隨著節點的增多,而降低. 於是問題出現.
8.2.2 multiget-hole 解決方案:
把某一組 key,按其共同字首,來分布.
比如 user-133-age, user-133-name,user-133-height 這 3 個 key,
在用分布式演算法求其節點時,應該以 『user-133』來計算,而不是以 user-133-age/name/height 來
計算.這樣,3 個關於個人資訊的 key,都落在同 1 個節點上,訪問個人主頁時,只需要連線 1 個節點.
問題解決.
官方回應:
事實上:
nosql 和傳統的 rdbms,並不是水火不容,兩者在某些設計上,是可以相互參考的.
對於 memcached, redis 這種 kv 儲存, key 的設計,可以參考 mysql 中表/列的設計.
比如: user 表下,有 age 列,name 列,身高列,
對應的 key,可以用 user:133:age = 23, user:133:name = 『lisi』, user:133:height = 168;
8.3 永久資料被踢現象
網上有人反饋為"memcached 資料丟失",明明設為永久有效,卻莫名其妙的丟失了.
其實,這要從 2 個方面來找原因:
即前面介紹的 惰性刪除,與 lru 最近最少使用記錄刪除.
分析(圖 8.3-):
1:如果 slab 裡的很多 chunk,已經過期,但過期後沒有被 get 過, 系統不知他們已經過期.
2:永久資料很久沒 get 了,不活躍,如果新增 item,則永久資料被踢了.
3: 當然,如果那些非永久資料被 get,也會被標識為 expire,從而不會再踢掉永久資料
解決方案: 永久資料和非永久資料分開放
memcached 快取應用問題
快取穿透與快取雪崩 快取系統不得不考慮的另乙個問題是快取穿透與失效時的雪崩效應。快取穿透是指查詢乙個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。有很多種方法可以有效地解決快取穿...
memcached使用安裝 問題
使用 1 telnet 127.0.0.1 11211 連線memcached win10開啟telnet需要開始選單 設定 搜尋.windows功能 有個啟用或關閉windows功能 內部有個telnet功能開啟即可 2 使用get或者 gets 獲取key stats 執行狀態安裝 1 memc...
鍊錶帶環或不帶環的幾個經典問題
1.給定乙個鍊錶，返回鍊錶開始入環的第乙個節點。如果鍊錶無環，則返回 null。2.求不帶環相交鍊錶起始節點 public class solution return h1 3.求帶環單鏈表的環的長度快慢指標從第一次相遇開始進行累加直到第二次相遇跳出迴圈 public static intlengt...