分散式Redis的使用
參考自這篇文章,作者寫的很棒。
作者:孤獨煙
來自:http://rjzheng.cnblogs.com/
1.為什麼使用Redis
專案中使用Redis,主要從兩個角度考慮:效能和併發。Redis還可以做分散式等其他功能,但是如果只是為了做分散式鎖還可以考慮其他中介軟體(zookpeer等)。
(一)效能
碰到需要執行耗時特別久,且結果不頻繁變動的SQL,就特別適合將執行結果放入快取。這樣,後面的請求就去快取中讀取,使得請求能夠迅速響應。
(二)併發
在大併發的情況下,所有的請求直接訪問資料庫,資料庫會出現連線異常。這個時候,就需要使用redis做一個緩衝操作,讓請求先訪問到redis,而不是直接訪問資料庫。
2.使用Redis有什麼缺點
(一)快取和資料庫雙寫一致性問題
(二)快取雪崩
(三)快取擊穿
(四)快取的併發競爭問題
3.單執行緒的Redis為什麼這麼快
(一)純記憶體操作
(二)單執行緒操作,避免了頻繁的上下文切換
(三)採用非阻塞I/O多路複用機制
如下圖,簡單來說,I/O多路複用就是。我們的redis-client在操作的時候,會產生具有不同事件型別的socket。在服務端,有一段I/0多路複用程式,將其置入佇列之中。然後,檔案事件分派器,依次去佇列中取,轉發到不同的事件處理器中
4.Redis的資料型別及使用場景
(一)String
最常規的set/get操作,value可以是String也可以是數字。一般做一些複雜的計數功能的快取。
(二)hash
這裡value存放的是結構化的物件,比較方便的就是操作其中的某個欄位。在做單點登入的時候,就是用這種資料結構儲存使用者資訊,以cookieId作為key,設定30分鐘為快取過期時間,能很好的模擬出類似session的效果。
(三)list
使用List的資料結構,可以做簡單的訊息佇列的功能。另外還有一個就是,可以利用lrange命令,做基於redis的分頁功能,效能極佳,使用者體驗好。
(四)set
因為set堆放的是一堆不重複值的集合。所以可以做全域性去重的功能
另外,就是利用交集、並集、差集等操作,可以計算共同喜好,全部的喜好,自己獨有的喜好等功能。
(五)sorted set
sorted set多了一個權重引數score,集合中的元素能夠按score進行排列。可以做排行榜應用,取TOP N操作。sorted set可以用來做延時任務。最後一個應用就是可以做範圍查詢。
5.Redis的過期策略及記憶體淘汰機制
分析:比如你redis只能存5G資料,可是你寫了10G,那會刪5G的資料。怎麼刪的?還有,你的資料已經設定了過期時間,但是時間到了,記憶體佔用率還是比較高,原因是什麼?
回答:
redis採用的是定期刪除+惰性刪除策略。
為什麼不用定時刪除策略?
定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然記憶體及時釋放,但是十分消耗CPU資源。在大併發請求下,CPU要將時間應用在處理請求,而不是刪除key,因此沒有采用這一策略.
定期刪除+惰性刪除是如何工作的呢?
定期刪除,redis預設每個100ms檢查,是否有過期的key,有過期key則刪除。需要說明的是,redis不是每個100ms將所有的key檢查一次,而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查,redis豈不是卡死)。因此,如果只採用定期刪除策略,會導致很多key到時間沒有刪除。
於是,惰性刪除派上用場。也就是說在你獲取某個key的時候,redis會檢查一下,這個key如果設定了過期時間那麼是否過期了?如果過期了此時就會刪除。
採用定期刪除+惰性刪除就沒其他問題了麼?
不是的,如果定期刪除沒刪除key。然後你也沒即時去請求key,也就是說惰性刪除也沒生效。這樣,redis的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。
在redis.conf中有一行配置
# maxmemory-policy volatile-lru
該配置就是配記憶體淘汰策略的
1)noeviction:當記憶體不足以容納新寫入資料時,新寫入操作會報錯。應該沒人用。
2)allkeys-lru:當記憶體不足以容納新寫入資料時,在鍵空間中,移除最近最少使用的key。推薦使用,目前專案在用這種。
3)allkeys-random:當記憶體不足以容納新寫入資料時,在鍵空間中,隨機移除某個key。應該也沒人用,你不刪最少使用Key,去隨機刪。
4)volatile-lru:當記憶體不足以容納新寫入資料時,在設定了過期時間的鍵空間中,移除最近最少使用的key。這種情況一般是把redis既當快取,又做持久化儲存的時候才用。不推薦
5)volatile-random:當記憶體不足以容納新寫入資料時,在設定了過期時間的鍵空間中,隨機移除某個key。不推薦
6)volatile-ttl:當記憶體不足以容納新寫入資料時,在設定了過期時間的鍵空間中,有更早過期時間的key優先移除。不推薦
ps:如果沒有設定 expire 的key, 不滿足先決條件(prerequisites); 那麼 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。
6.Redis和資料庫雙寫一致性問題
分析:一致性問題是分散式常見問題,還可以再分為最終一致性和強一致性。資料庫和快取雙寫,就必然會存在不一致的問題。答這個問題,先明白一個前提。就是如果對資料有強一致性要求,不能放快取。我們所做的一切,只能保證最終一致性。另外,我們所做的方案其實從根本上來說,只能說降低不一致發生的概率,無法完全避免。因此,有強一致性要求的資料,不能放快取。
回答:首先,採取正確更新策略,先更新資料庫,再刪快取。其次,因為可能存在刪除快取失敗的問題,提供一個補償措施即可,例如利用訊息佇列。
7.如何應對快取擊穿和快取雪崩問題
快取穿透,即黑客故意去請求快取中不存在的資料,導致所有的請求都懟到資料庫上,從而資料庫連線異常。
解決方案:
(一)利用互斥鎖,快取失效的時候,先去獲得鎖,得到鎖了,再去請求資料庫。沒得到鎖,則休眠一段時間重試
(二)採用非同步更新策略,無論key是否取到值,都直接返回。value值中維護一個快取失效時間,快取如果過期,非同步起一個執行緒去讀資料庫,更新快取。需要做快取預熱(專案啟動前,先載入快取)操作。
(三)提供一個能迅速判斷請求是否有效的攔截機制,比如,利用布隆過濾器,內部維護一系列合法有效的key。迅速判斷出,請求所攜帶的Key是否合法有效。如果不合法,則直接返回。
快取雪崩,即快取同一時間大面積的失效,這個時候又來了一波請求,結果請求都懟到資料庫上,從而導致資料庫連線異常。
解決方案:
(一)給快取的失效時間,加上一個隨機值,避免集體失效。
(二)使用互斥鎖,但是該方案吞吐量明顯下降了。
(三)雙快取。我們有兩個快取,快取A和快取B。快取A的失效時間為20分鐘,快取B不設失效時間。自己做快取預熱操作。然後細分以下幾個小點
I 從快取A讀資料庫,有則直接返回
II A沒有資料,直接從B讀資料,直接返回,並且非同步啟動一個更新執行緒。
III 更新執行緒同時更新快取A和快取B。