一種基于kubernetes托管的redis集故障自愈方法與流程
1.本發明涉及計算機存儲技術領域，尤其涉及一種基于kubernetes托管的redis集故障自愈方法。
背景技術：
2.對于redis(remote dictionary server，即遠程字典服務)數據庫的自愈，以往關注的大多是高可用性，一般場景是：redis主庫發生故障的時候，基于預先設定的主從切換方案，或者redis cluster(redis數據庫集)內部的容錯機制進行故障修復，但這些都僅僅只是應對實例掛掉的高可用方案，不屬于自愈方案(實例掛掉的情況下，雖然做了主從切換，保證了業務訪問的連續性，但實際并未真正解決容量風險或者副本缺少的風險)。另外，redis集的自愈，不僅僅只是主從切換，還存在容量、網絡等故障或者風險下的自愈，目前業界對這些缺乏系統性的配套自愈解決方案。
技術實現要素：
3.為此，本發明提供了一種基于kubernetes托管的redis集故障自愈方法，能夠很好的解決上述問題。redis集故障自愈后，確保了和異常發生前的redis集各組件實例數一致，保障了用戶訪問耗時無異常，且整體集容量不退化，副本數不減少。
4.為實現本發明之目的，采用以下技術方案予以實現：
5.一種基于kubernetes托管的redis集故障自愈方法，包括以下步驟：
6.請求耗時檢測：異常檢測器模擬用戶側的記錄請求訪問redis集，并判定請求耗時是否正常；
7.故障自愈：當請求耗時異常時，進行故障自愈操作。
8.所述的redis集故障自愈方法，其中：
9.異常檢測器按照預定頻次和范圍對redis集發送讀寫請求，模擬用戶側的訪問行為；
10.異常檢測器將獲得的探測數據，通過資源服務器持久化到etcd存儲系統中，然后由控制器進行數據分析。
11.所述的redis集故障自愈方法，其中：
12.如果是異常檢測器到路由服務器耗時高，但是異常檢測器到中間件代理服務器的耗時正常，則說明可能是路由服務器到中間件代理服務器的耗時變長，或者路由服務器因為負載原因導致響應不及時。
13.所述的redis集故障自愈方法，其中：
14.i)如果多個機房內的異常檢測器到路由服務器的耗時都異常偏高，則進一步判定對應路由服務器pod內進程cpu的利用率，如果一定周期內cpu的利用率超過預定值，則對路由服務器進行擴容操作。
15.所述的redis集故障自愈方法，其中還包括以下步驟：異常檢測器監測每個node
的負載。
16.所述的redis集故障自愈方法，其中還包括以下步驟：異常檢測器監測redis集的容量水位。
17.所述的redis集故障自愈方法，其中還包括以下步驟：異常檢測器檢測集出現耗時是否由用戶的慢查詢導致。
18.所述的redis集故障自愈方法，其中還包括以下步驟：異常檢測器進行實例異常的故障檢測。
19.一種基于kubernetes托管的redis集故障自愈系統，包括異常檢測器、資源服務器、etcd存儲系統、控制器和調度器，其中，所述系統用于執行如上所述的redis集故障自愈方法。
20.一種計算機可讀存儲器，，存儲有處理器可執行指令，當所述指令被處理器執行時，使處理器執行如上所述的方法。
附圖說明
21.圖1為基于kubernetes托管的redis集故障自愈系統結構示意圖；
22.圖2為rdis集示意圖。
具體實施方式
23.下面結合附圖1-2，對本發明的具體實施方式進行詳細說明。顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基于本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本發明保護的范圍。所述實施方式是示例性地，僅用于解釋本發明，而不能理解為對本發明的限制。顯然，本發明所描述的實施例僅僅是本發明的一部分實施例，而不是全部的實施例。基于本發明中的實施例，本領域技術人員在沒有做出創造性勞動的前提下所獲得的所有其他實施例，都屬于本發明保護的范圍。
24.在本說明書中描述的“一種實施方式”或“一些實施方式”等意味著在本發明的一個或多個實施方式中包括結合該實施例描述的特定特征、結構或特點。由此，在本說明書中術語“包括”、“包含”、“具有”及它們的變形都意味著“包括但不限于”，除非是以其他方式另外特別強調。
25.如圖1所示，本發明的基于kubernetes托管的redis集故障自愈系統包括異常檢測器(detector)、資源服務器(kube-apiserver)、etcd存儲系統、控制器(redis-k8s-controller)，調度器(kube-scheduler)。
26.其中，異常檢測器用于檢測網絡、機器負載、redis-server，router-server等的健康狀態等；資源服務器用于與etcd直接交互，提供kubernetes系統的接口等；etcd存儲系統用于存儲系統數據；控制器用于控制redis集。
27.如圖2所示，redis集主要包括：redis-metaserver(redis集元數據服務器)，router-server(redis集中的消息路由服務器)，redis-server(redis集中的數據存儲服務器),redis-sentinel(哨兵模塊)。其中，router-server架設在redis-server上面一層，起著消息路由轉發的作用，redis-server處理完結果后會返回給router-server，然后
router-server再將結果返回給用戶層。
28.本發明的基于kubernetes托管的redis集故障自愈方法包括：
29.1、detector模擬用戶側的記錄請求以訪問redis集，并判定請求耗時是否正常：
30.1.1detector以服務守護進程(daemonset)的方式運行在機房中的每個node節點(該node節點既可以是物理機也可以是虛擬機)當中，并且確保detector至少是在雙機房甚至多機房部署，確保detector探測的是多條不同鏈路，便于最后匯聚結果作出最終決策。
31.1.2每個機房內的detector，按照一定頻次和范圍(例如5秒/次，由全局10％的detector執行耗時探測請求)，去對redis集的router-server(redis集中的消息路由服務器)以及redis-server(redis集中的數據存儲服務器)發送讀寫請求，模擬用戶側的訪問行為。
32.1.3detector將得到的探測數據，通過資源服務器持久化到etcd存儲系統當中，然后由控制器(redis-k8s-controller)感知并進行數據分析和匯總，由此判斷是redis-server處理速度變慢了，還是router-server和redis-server之間傳輸耗時變長了。
33.a)如果detector到router-server耗時高，但是detector到redis-server的耗時正常，則說明可能會是router-server到redis-server的耗時變長，或者router-server因為負載原因導致響應不及時：
34.i)如果是多個機房內的detector到router-server的耗時都異常偏高，則進一步判定對應router-server pod內的進程cpu的利用率，如果一定周期內cpu的利用率持續大于80％，則說明負載過高，需要對router-server進行擴容操作，此時redis-k8s-controller會自動觸發擴容行為，按照一定步長維度，擴容router-server pod模塊(例如按照多機房，如雙機房各擴容10％的比例逐次擴容，然后每擴容一次，比對一下進程cpu利用率，并且判斷detector到router-server的耗時)，只有當router-server的平均cpu利用率降低到50％以下，且耗時恢復正常，才停止擴容行為(自愈完成)。
35.ii)如果detector到router-server耗時偏高只存在于單個機房，可采取本地分流的方式進行嘗試性故障自愈操作，即判斷是否存在與所述異常單個機房距離接近的機房，例如同處于一個建筑物，或者同處于一個內部網段，或者同處于一個城市等，如果存在，則將訪問異常機房的部分流量引導到與其距離較近的機房，如果異常機房耗時恢復正常，則完成自愈，如果耗時仍然偏高，則繼續以下的步驟：
36.除了判斷單機房的router-server pod內進程cpu利用率以外：
37.(1)detector還會發起ping的icmp報文到這批router-server所在的機器(即detector發起ping的icmp報文到在同一個redis集中detector到router-server耗時高的所在機房內的所有router-server)，如果一半以上的機器ping耗時時間超過正常值，則判定為耗時異常波動；
38.(2)并且同時會在后臺執行路由追蹤(traceroute)命令，用于輔助判斷到達各路由器(router-server)的時間，如果一半以上機器的到達時間超過正常值，則判定為耗時異常波動；
39.(3)在后臺調用響應時間監測組件(tcprstat)，監聽router-server端口，判斷router-server返回給detector的報文返回時間，如果一半以上的機器返回時間超過正常值，則判定為耗時異常波動。
40.若cpu利用率異常，則仍然采集1.3-a-i步驟中的擴容方式解決；若cpu利用率正常，但滿足1.3-a-ii中的任意一個條件：即出現在一定周期內耗時異常波動的情況，則說明是網絡側導致，此時redis-k8s-controller會嘗試屏蔽該單機房的router-server，確保上游流量在此期間，不再轉發到該異常單機房的router-server，而是都會路由(轉發切換)到正常機房的router-server。屏蔽以及轉發切換完成后，redis-k8s-controller會在資源池當中，嘗試選取一批和之前異常router-server不同的路由器下的機器(當然，該機器是其他機房的機器)，然后進行網絡鏈路耗時探測，如果正常，則會在此批不同的機器下部署新的router-server，然后銷毀之前被屏蔽的router-server，流量由會由這批新的router-server所承載(自愈完成)，被銷毀后的資源由資源池回收。
41.2、detector還會監測每個node的負載，如某個節點node的負載平均值(load avg)出現上漲趨勢(例如，以最近15分鐘內的load avg的采樣數據擬合成一個線性函數，通過判斷其斜率變化以確定是否是上漲趨勢)，并且對應機器(即node對應的物理機或者虛擬機)上的各redis-server pod以及router-server pod的上下文切換頻次變高，并且性能指標(cpi指標)也處于上升波動趨勢(上述指標的采集都由detector完成)，則說明此node上混部的實例已經較多，存在資源互相競爭的風險，此時redis-k8s-controller會對此node上的進程利用率大于20％的redis-server pod/router-server pod進行排序：
42.1)排名越靠前的pod越會優先被redis-k8s-controller發起驅逐遷移。
43.2)優先遷移router-server pod：考慮到router-server本身無狀態，redis-k8s-controller會在資源池中挑選較為空閑的資源池，由kube-scheduler將router-server pod遷移至此。
44.3)次優遷移redis-server pod：redis-server會有master以及slave角，這里會優先遷移redis-slave(從redis服務器)pod，最后才是考慮遷移redis-master(主redis服務器)pod：
45.a)遷移redis-slave的步驟：redis-k8s-controller向對應redis集中的router-server發起控制命令，對應router-server中會下線該redis-slave，以至于讀請求不會再路由到該redis-slave。接著redis-k8s-controller會選取其他合適的資源(例如：cpu負載不高(比如30％cpu利用率以下)且物理內存使用率《30％)，最終由kube-scheduler將實例遷移至此。
46.b)遷移redis-master步驟：redis-k8s-controller會對哨兵模塊(redis-sentinel)下發故障轉移(failover)命令，最終由redis-sentinel執行主從切換操作，此時待遷移的redis-master已經降級為redis-slave角，然后參考上述a)的操作完成遷移動作。
47.4)直到遷移完一定數量的pod后，原有node的load avg負載以及剩余pod cpi指標及上下文切換恢復正常水平，則說明自愈完成。
48.3、除了耗時檢測以及負載檢測以外，detector還會監測redis集的容量水位。初始狀態下每個redis pod默認request為5gb(軟限制),limit為10gb(硬限制)，當detector通過kubernetes的核心指標監控器(metrics server)感知到redis pod的內存超過request值的時候，則說明當前redis集存儲容量存在風險，則會做如下判斷和操作：
49.1)detector會判定redis集各實例的內存是否都超過了pod的request值：
50.a)如果只是個別pod的request的容量超限，說明redis集存在數據傾斜，即：這部分容量超限的分片存在大key(即該key對應的value很大)，detector把這部分異常信息通過kube-apiserver記錄到etcd后，redis-k8s-controller會主動觸發后臺任務，對這部分pod中的redis-slave進行大key分析：
51.i)如果redis集配置了key過期策略(如lru-volatile)，則redis會嘗試將遍歷到的(配置了ttl)已到生存周期的大key進行主動刪除操作，至此刪除完對應數據后，容量降低到request值之下(自愈結束)。
52.ii)如果redis集沒有配置key過期策略(no-eviction)，則redis-k8s-controller不做任何操作，而是以短信/郵件方式附帶大key分析報告，一并通知到redis運維人員進行人工接入處理。
53.b)如果對應各個pod的容量都超限，則說明需要擴容，此時的操作會是redis-k8s-controller在可用資源池中擴容新的redis pod，然后給redis-metaserver-hot(元數據主服務器)發起遷移命令，最終由redis-metaserver-hot底層完成集擴容后，將擴容結果通過kube-apiserver持久化到etcd當中，然后redis-k8s-controller感知到擴容完成，并再次檢查redis集中各個分片的容量是否低于request值，如果是則自愈結束，如果否則繼續執行擴容操作，直到redis集中各個分片的容量都低于request值。
54.4、針對detector檢查到集出現耗時變長，但實際是由部分用戶的慢查詢導致的情況(例如：detector到router-server耗時不高，而到redis-server耗時高，則說明大概率是用戶側慢查詢導致出現這種情況)，則redis-k8s-controller會判定持續周期，如果只是較為短暫的波動，則不會做任何操作，如果持續大于一定時長，則執行以下操作：
55.1)對于局部讀熱點而言，redis-k8s-controller會擴容對應分片下的redis-slave pod來嘗試分攤對應讀流量(嘗試自愈)。
56.例如一個redis集有3個分片，但是用戶讀請求大部分都路由到其中某個分片上，這種場景就叫做局部讀熱點。
57.分攤讀流量的方式包括：擴redis-slave pod(縱向擴容)，同時router-server的拓撲配置聯動變更。“自愈”的判定主要判斷耗時大小即可，耗時恢復至常態則可以理解為自愈結束。
58.2)如果上述方案仍然解決不了或者應對的是局部寫熱點場景，則將此部分信息以短信/郵件方式推送到redis運維人員進行介入處理。
59.可選的，本發明還提供了實例異常的故障自愈方法，如下：
60.1、對于redis-server pod或者router-server pod異常掛掉，或者node宕機，亦或是detector到pod之間的訪問不可達，將會采取如下操作：
61.1)對于單個router-server pod異常，則redis-k8s-controller聯動kube-scheduler直接在可用資源池中部署一個新的pod，并下線舊的pod(自愈結束)。
62.2)對于單個redis-master pod異常，則會先由redis-sentinel完成對應的主從切換，然后再由redis-k8s-controller聯動kube-scheduler完成kube-slave pod部署，并下線舊的pod(自愈結束)。
63.3)對于單個redis-slave異常，redis-k8s-controller會對其進行屏蔽，然后啟動(spawn)出新的redis-slave pod后，再下線舊的pod(自愈結束)。
64.2、對于metaserver的異常掛掉或者其它原因導致訪問不通，這里的處理機制為：
65.1)針對metaserver-pod-hot：如果metaserver半數以上可用，則會在剩余metaserver-pod-standby(備選或從metaserver-pod)中，選舉一個權重較高的作為新的metaserver-pod-hot，并且由redis-k8s-controller聯動kube-scheduler部署一個新的metaserver-pod-hot，并下線舊的pod(自愈結束)。
66.2)針對metaserver-pod-standby：不影響正常metaserver集運轉，只需要由redis-k8s-controller聯動kube-scheduler部署一個新的metaserver-pod-hot，并下線舊的pod(自愈結束)。
67.根據本公開一個實施方式，提供了一種計算機可讀存儲介質。本領域普通技術人員可以理解，上述實施例的各種方法中的全部或部分步驟可以通過指令來完成，或通過指令控制相關的硬件來完成，該指令可以存儲于一計算機可讀存儲介質中，并由處理器進行加載和執行。為此，本技術實施例提供一種存儲介質，其中存儲有多條指令，該指令能夠被處理器進行加載，以執行本技術實施例所提供的任意一種基于kubernetes托管的redis集故障自愈方法的步驟。
68.其中，該存儲介質可以包括：只讀存儲器(rom，read only memory)、隨機存取記憶體(ram，random access memory)、磁盤或光盤等，更具體來說，可包括靜態隨機存取存儲器(static random-access memory，sram)和動態隨機存取存儲器(dynamic random access memory，dram)等具體類別。
69.由于該存儲介質中所存儲的指令，可以執行本技術實施例所提供的任意基于kubernetes托管的redis集故障自愈方法的步驟，因此，可以實現本技術實施例所能實現的有益效果，詳見前面的實施例，在此不再贅述。以上各個操作的具體實施可參見前面的實施例，在此也不再贅述。
70.通過本發明，實現了多種常見場景下redis集的故障自愈(例如：耗時變慢、容量不足、實例掛掉等)；同時在保障用戶訪問redis集的可用性以及連續性同時，最大可能保障了集的容量不退化，耗時平穩。
71.以上，僅是本發明的較佳實施例而已，并非對本發明作任何形式上的限制，雖然本發明已以較佳實施例揭示如上，然而并非用以限定本發明，任何本領域技術人員，在不脫離本發明技術方案范圍內，當可利用上述揭示的技術內容做出些許更動或修飾為等同變化的等效實施例，但凡是未脫離本發明技術方案內容，依據本發明的技術實質對以上實施例所作的任何簡介修改、等同變化與修飾，均仍屬于本發明技術方案的范圍內。
