分散式高效能 Redis 叢集線上常見問題
量變引起質變,這個情況在分散式redis叢集下發生的極其明顯,當用redis叢集規模很小、存取資料很小時,基本上不會遇到任何問題,但是當我們叢集規模為數T,並且存在很多業務讀寫叢集各種各樣問題都會發生。
線上遇到過一個業務突然tp99飆升,並且效能持續變差,效能看著一點一點變差,而我們只能去分析定位查詢,最終定位到是叢集在拉取資料,mGet高達30萬資料,不是一次mGet30萬組資料而是分多次批量讀取,每次取1000直到30萬資料讀完,這麼大的批量讀取由於redis本身是單執行緒架構會導致其他請求堵塞導致效能上升,通過優化架構減少讀取資料從而提升效能。
線上遇到過叢集分片一直在寫,從而導致叢集一直很忙,影響線上效能,經過不斷分析定位,發現問題是什麼呢?是有一個key一直在寫,實際業務上是一個過濾資料,儲存在redis,每個使用者去過濾他自己資料,實際中因為有些使用者不會登陸,這是就不能進行過濾,否則因為沒有登陸使用者很多,會導致過濾資料不停寫,並且不斷增大從而導致分片效能受影響,從而導致效能出問題。
前一次大促時候線上大促時遇到redis連線數過多,過多會導致什麼問題呢?連線過多會導致後續連線可能取不到資料,從而導致線上業務遭受嚴重影響,怎麼減少連線呢?就要從連線來源分析,將連線數降低,從而避免連線風暴導致叢集不可用。
首先分析連線數來自於三個方面,一個是離線任務倒入redis,這種方式通過代理方式連線redis叢集,好處是可以控制代理叢集到redis叢集連線數,從而控制連線數量,問題是代理叢集數量過少會影響使用這種方式連線redis叢集業務。每一種方式優點往往就是這種方式缺點,這時就需要我們根據實際情況進行取捨。
另一種連線叢集方式採用公司自己研發客戶端,採用連線池方式與redis叢集連線,直接連線redis叢集,好處是批量讀取、單個讀取效能都高,缺點是連線數高,導致叢集連線數過多,原來storm storm主要用於準時事計算這種可以進行優化,線上業務也採用這種連線方式,不好進行方式修改,因為修改會對於線上業務有很大影響。關於連線池相關可以見這篇 ofollow,noindex">談談連線池、執行緒池技術原理 。
對於上邊連線問題還有一種客戶端採用單連線架構,單連線能顯著降低連線,但是會對批量操作有一定影響對於mGet,這時就權衡將storm升級為這種方式,顯著減少連線數,解決了連線數過多問題。
對於連線數因為以前業務邏輯簡單,推薦引擎召回資料很少,那時將多個業務存在一個叢集是合理的,但當下單個業務邏輯極其複雜,召回資料極其多,這時就需要拆分叢集,從而降低叢集負載以及連線數。同時這種架構也可避免線上業務相互影響。
從上邊可以看出來,當你的業務達到數萬/分鐘,並且一個使用者請求需要多次召回資料、複雜計算才能返回,這時就不能拿redis當作透明中介軟體來用,而應該對其架構不斷深入理解,根據實際場景來運用。
需要對分片、叢集架構、叢集擴容、所容、刪除機制、以及連線管理,負載以及資料儲存大小,合理使用資料結構等各個方面深入理解,不然使用很容易突然發生問題,從而影響業務穩定性,作為一個程式架構設計人員,我們應該加強了解,本身對於分散式redis叢集這種架構有深入瞭解後,對於其他比如bigtable、hbase理解也會更加深入。