天天看點

架構師之路-redis叢集解析

引子

架構師之路-redis叢集解析

 上篇​​《架構師之路-https底層原理》​​裡我提到了上面的整體視圖,文章也介紹了想要真正能在工作中及時正确解決問題的基本功:原理了解透徹。今天以redis叢集解析為例介紹一個及時敏銳的發現問題的基本功:深入分析。

我認為達到深入分析有三個步驟:

第一步,深入了解

第二步,學以緻用

第三步,千人千問

第一步redis叢集各種原理介紹的人也很多;第二步很多人實際項目中大概也對redis叢集不陌生;是以本文主要講第三步:千人千問。

提出問題

"redis叢集使用時有什麼注意事項?"這是之前有段時間我面試喜歡問的一個問題。我的一個觀點是作為redis叢集的使用方而不是開發者首先要做的是用好。通過這個問題确定候選人用好了,再去挖掘他是通過了解了怎麼用好的。是以我通常不會一開始就問一些中間件的原理,而是先從使用者的角度提出問題。

下面列舉了6條代表性的回答:

1>防止集中失效

2>單線程執行,注意不要卡住

3>注意用戶端和服務端的版本比對

4>分片要保持流量均勻

5>注意逾時時間配置

6>當記憶體緩存用,推薦删除代替更新

每條問題前面加上個為什麼,就引出了6條新的問題。

解決問題

Q1:為什麼要防止緩存集中失效?

A:緩存穿透、緩存集中失效和緩存雪崩并稱為緩存世界的三大問題。先來總結了解一下這三個概念。這三個概念都是建立在緩存的一大作用就是對後端存儲,比如mysql的保護。緩存沒有保護住mysql,一個或一些到mysql了,那就是穿透;一個時間點緩存資料沒有了,打到mysql了就是集中失效;緩存完全喪失了保護mysql的能力,請求全打到mysql了,就是雪崩。

是以防止緩存集中失效是對後端存儲的保護。

Q2:為什麼單線程執行,注意不要卡住?

A:卡住換個專業點的詞就是阻塞嘛。什麼叫阻塞呢,一輛小轎車A在單行道跑,遇到前面一輛車B停了,那A就被阻塞了。如果A和B都在高速單行道上跑,A開了160邁、B開了140邁。就算高速的允許最高速度是120邁(咱就當路過的是沒有攝像頭的路段,這倆車肆無忌憚),那A是不是還是被B給阻塞了呢?是以卡住造成的最直接影響就是快的快不起來,因為單線程不能繞行嘛。

有人說不是可以多開幾個redis嘛。是滴,但是用戶端分請求使用的是crc16,根本不會先探測哪個服務端比較空閑呀。是以後面來的總會被阻塞。

注意不要卡住還有個大家更常聽到的名字:“避免大key問題”。其實我剛聽到這個名字的時候是覺得很奇怪的。因為避免大key實際上是要避免key所對應的value不要太大。我之前一直覺得這個名字取的不對。那應該叫“避免大value問題”。後來想想這确實是正宗的中國話。比如張三的媳婦,人家都怎樣叫呢?一般都是張三媳婦、張三家的。因為他家主要是張三出來抛頭露面。那redis取值也一樣,一般是先知道key,從key取value。用這個key取出來的資料大,就是大key問題啦。

Q3:如果不注意用戶端和服務端版本比對會引發什麼問題?

A:先來思考用戶端做了什麼事情。我了解它就做了兩件事:第一是使用RESP(Redis自定義的序列化協定)傳輸用戶端指令并傳回結果。第二是為了做第一件事,因為Redis叢集是直連服務端模式,是以計算指令要落在哪個節點、哪個哈希槽上也是用戶端來做的,我就稱為選節點吧。

其實要回答用戶端和服務端不比對會引發什麼問題,正規的方法應該是檢視用戶端版本更新都做過什麼更新。

一般更新會做的是用戶端依賴的jar包變了。這個可能會引起程式啟動錯誤,但是這個往往啟動成功了就不會再有問題,和服務端版本沒有直接關系。

十年前還在用memcache的時候,發生過一次更新用戶端版本,因為算法發生了變化,是以導緻緩存全部不命中的問題。Redis最近的算法一直是crc16。如果不存在分布式算法不相容問題的話,下一個要考慮的是大疊代是Redis3.0版本,支援了叢集,叢集模式是必須要比對的。

Q4:為什麼分片要保持流量均勻?

A:要提分片先來回憶一下redis叢集的發展史,從單機版到主從版,後來有了大家可能很耳熟的哨兵模式。哨兵模式就是給主從增加一個監控,發現主節點挂了自動把從節點更新為主節點,有了故障自動遷移的功能。但是直到哨兵時代都隻有一個主節點,也就是處理寫請求的節點,不能稱之為真正的叢集。這也是很無奈的事情,一旦多個節點寫一份資料,就涉及到資料一緻性的問題。

一個蜂巢隻能有一個蜂後,多出來一個,蜜蜂們就不會正常提供采蜜服務了,都打架去了。但是分成兩個蜂巢呢?秩序就會恢複。是以現在的叢集基本都是分片的原理。之前主從和哨兵的經驗不能廢棄,加上分片。redis叢集就是将一個完整服務資料分成幾份,每份都帶着從節點,故障時可自動轉移的一個整體。之前在《​​Redis叢集搭建采坑總結​​》裡講過,1個節點的叢集會有問題,最少需要3主3從也就是6個redis程序。3個主友善在1個挂掉之後重新選主。

梳理了這個之後,分片保持流量均勻這件事也很容易了。就是Q2的問題,均勻更不容易阻塞嘛。

Q5:為什麼要注意逾時時間配置?

A:提到redis的key的過期時間,首先想到的是redis的術語中,帶過期時間的key又叫volatile key,就是不穩定key。怎麼不穩定呢?就相當key這個對象有value和過期時間2個屬性。過期時間這個屬性1s改變一次(redis領域内時間都是以秒為機關),一直在變,當然不穩定。

如果把過期時間了解為key的一個屬性,那也很好了解:對其進行del、set指令時過期時間也會删除;rename會把過期時間傳給新的key;incr、lpush、hset等指令改變的是key的存儲容器,沒有改變key這個對象本身是以不會影響過期時間。

值得注意的是persist指令就是持久化儲存的意思,将不穩定變成穩定,過期時間也自動删除了。

Redis在服務端有過期政策,但是對用戶端是不感覺的。用戶端通路過期的就是一個表現,通路不到了。實際上服務端是有兩種政策配合使用,一個是惰性删除,就是通路的時候發現過期了,就直接删除了;另一個政策會定期去删除,這個是為了防止一個過期的key總是不被通路到,還占着資源不釋放。

Q6:為什麼當記憶體緩存用,推薦删除代替更新?

A:一般大家出于資料一緻性的考慮,會選擇删除代替更新。這都是基于更新一定要更新資料庫的固有思路。并發場景下,A的值1先被更新到資料庫再更新緩存時,又來了一個更新請求把A的值更新為2。如果這時候執行更新為1的伺服器性能不好或者網絡傳輸速度比更新為2的慢,導緻2在資料庫是最新值,而設定為1的後更新了緩存。緩存就和資料庫不一緻了。

但隻是記住删除代替更新不太夠。如果先删除緩存再更新資料庫,其他請求可能會把資料庫老的值再加載到緩存中。記得之前有人介紹緩存還有三大種模式:Cache-Aside、Read-Through/Write-Through、Write-Behind。

Cache-Aside就是先更新資料庫再删除緩存資料,可以避免上面提到的持續髒讀的問題,頂多就是更新資料庫的那一小段時間有更新延遲可見。我們給Cache-Aside起個中文名,叫經典模式。

Read-Through/Write-Through就是資料以緩存為準,資料庫的操作是緩存發起的。Read-Through是在讀資料時發現緩存過期了,那緩存自己去資料庫加載新的資料,讀資料還是讀取緩存值。Write-Through寫資料時調用方隻負責寫緩存,緩存自己去同步更新資料庫。Read-Through/Write-Through一般配合使用。

Write-Behind和Write-Through的差別是雖然都是是寫資料時調用方隻負責寫緩存,但是Write-Behind緩存自己去異步更新資料庫。

因為Read-Through/Write-Through、Write-Behind都是以緩存為準,緩存不可靠,是以還是推薦經典模式。

後記

一些朋友問我一邊上班一邊寫文章哪有那麼多時間呀。細心的朋友可能會發現我的文章一般是周末或者周一,再不就是節假日或者哪天失眠了發出來。因為内容都是非上班時間寫的,但是每次下筆腹稿都是提前打好的。個人意見哈,作為架構師,很多人都會形成随時随地為工作思考和總結的習慣。是以很多人看着下班很早,人家回家路上,曬太陽的時候……未必沒在想工作的事情。

架構師三件占時間的事:會議、評審和演講。對應有三大難:提出有水準的問題、做出有水準的總結和建議、做出有水準的回答。是以每天有很多的腹稿要打。腹稿按照一定的架構結構整理就是文章。

如果大家都架構師的三大難有興趣,我可以舉一些具體的示例和解決方法。大家投票吧,如果在看超過10個,我就寫這個。

上一篇: BeanUtils

繼續閱讀