分散式高效能 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理解也會更加深入。