Redis中幾個“看似”高大上的概念，經常有人提到，某些好事者喜歡死扣概念，實戰沒多少，嘴巴里冒出來的全是高大上的名詞，個人一向鄙視概念黨，呵呵！
其實這幾個概念：快取穿透/快取擊穿/快取雪崩，有一個共通的相似之處，就是高并發下，某些原因導致快取層失去了保護，導致后端的持久化層（資料庫）承擔較大壓力的情形，
需要注意的是，這些問題發生的前提，需要有足夠大的并發性，如果本身并發性不高，那些即便出現了這些個問題，也不會造成非常大的影響，
甚至極端地講，只要代碼的健壯性足夠，即便是快取層全部宕機，也不會導致整個應用程式的崩潰，只不過是所有的請求都指向后端的持久化資料庫層罷了，
試問，排出一些低級的問題包括方案，君見過多少請求壓垮資料庫的場景，或者資料快取流行之前應用程式就應付不了高并發？
使用快取，更多的進一步改善性能或者并發，而不是因為資料庫被壓垮了才使用快取，
快取穿透
快取穿透本質上是查詢一個快取和資料庫中都不存在的key值，Redis的快取層無法命中，導致請求再次指向執行資料庫層的情況，
由于是查詢到值不存在（當然也不存在與Redis快取中），導致請求總是“穿透”Redis發往資料庫層，因此快取層失去了“保護”關系資料庫層的意義，
解決方案：
布隆過濾器是一個比較好的選擇，參考：https://www.cnblogs.com/wy123/p/11571215.html
快取擊穿
強調對于某些熱點key，快取穿透本質上是高并發地請求一個快取中不存在，但是資料庫中存在的key值，導致并發請求指向資料庫，導致資料庫端承擔大量的請求壓力的情況，本質上跟快取穿透一樣，
主要側重的是并發&&“熱點”Key不存在與快取中，導致請求指向資料庫層，
解決方案：
這種場景可以從代碼邏輯層面優化，從快取中查詢不到資料，再次將請求轉向資料庫中的時候，鎖定該key，獲取到該key之后，將該key寫入快取，偽代碼如下
value =https://www.cnblogs.com/wy123/p/ get_value_from_redis(key1)if not value: if exclusiveness_lock(key1):#成功排他性鎖定目標，請求指向資料庫 value =https://www.cnblogs.com/wy123/p/ get_value_from_mysql(key1) if value: write_key_to_redis(key1,value) else:#無法獲取排他性鎖，間隔0.1s之后再次查詢快取 time.sleep(0.1) # 再次從快取中查詢 get_value_from_redis(key1)
快取雪崩
某些原因，比如:
1,Redis實體（主從，集群，哨兵等等）故障，
2,Redis中的key由于過期時間已到，自動過期，
3,由于Redis記憶體策略導致（maxmemory，maxmemory-policy配置）某些key失效（過期，被清理出快取等），
如果此時出現高并發的請求出現，這些請求會全部指向資料庫層，快取層失去了對資料庫層的保護，導致資料庫承擔絕大壓力的情況，
解決方案：
1，Redis層的高可用，保證快取層可以有效地保護資料庫層
2，從Redis配置（記憶體管理策略maxmemory，maxmemory-policy）以及結合業務，避免某些潛在的熱點key值過期
3，應用程式端限流，或者通過佇列的方式等削峰的方式來保護后端資料庫
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/29499.html
標籤：NoSQL
下一篇：學習之Redis（一）