分布式視頻處理系統(tǒng)中的worker、razer、sdk等模塊以無狀態(tài)方式設(shè)計，即worker應(yīng)用停止服務(wù)或節(jié)點宕機均不會影響整個系統(tǒng)對于視頻的處理。比如有worker-N應(yīng)用正在處理轉(zhuǎn)碼，到了99%的時候，卻很不幸的應(yīng)用崩潰，顯然該轉(zhuǎn)碼任務(wù)失敗，那么我們該怎么來保證該轉(zhuǎn)碼任務(wù)能正常結(jié)束，讓用戶不吐槽？我們的節(jié)點管理中心即Node Manager應(yīng)此而生，它全程監(jiān)控轉(zhuǎn)碼任務(wù)的狀態(tài)，如碰到系統(tǒng)因素引起的失敗，進行任務(wù)回收，其他worker應(yīng)用重新進行轉(zhuǎn)碼。

　　節(jié)點管理中心最基本核心的功能為各個節(jié)點服務(wù)器的狀態(tài)管理，此外還包括用戶管理（包括鑒權(quán)）、任務(wù)的跟蹤統(tǒng)計、節(jié)點狀態(tài)變更通知、資源監(jiān)控、全局配置信息獲取、及自身的HA等功能，如下圖所示。

　　

　　在設(shè)計之初，各個任務(wù)節(jié)點能獨立運行不依賴與管理中心，即管理中心是單點運行狀態(tài)。但是隨著功能的不斷完善及設(shè)計的不斷優(yōu)化，我們發(fā)現(xiàn)單點狀態(tài)已經(jīng)連最起碼的功能完整性都保證不了了，比如統(tǒng)計數(shù)據(jù)混亂、dashbord平臺無法使用、監(jiān)控報警失效，節(jié)點失效通知不及時等等，因此我們對Node Manager提出了高可用性的需求，也就是本文的初衷。

　　眾所周知，在分布式高可用性系統(tǒng)模型方面無非就是中心化和去中心化兩種設(shè)計方式。中心化的設(shè)計例如mysql的MSS單主雙從、MongDB Master、HDFS NameNode、MapReduce JobTracker等，有1個或幾個節(jié)點充當整個系統(tǒng)的核心元數(shù)據(jù)及節(jié)點管理工作，其他節(jié)點都和中心節(jié)點交互。這種方式的好處顯而易見，數(shù)據(jù)和管理高度統(tǒng)一集中在一個地方，容易聚合，就像領(lǐng)導(dǎo)者一樣，其他人都服從就好，簡單可行。但是缺點是模塊高度集中，容易形成性能瓶頸，并且如果出現(xiàn)異常，就像群龍無首一樣。無中心化的設(shè)計，例如cassandra、zookeeper，系統(tǒng)中不存在一個領(lǐng)導(dǎo)者，節(jié)點彼此通信并且彼此合作完成任務(wù)。好處在于如果出現(xiàn)異常，不會影響整體系統(tǒng)，僅僅局部不可用。缺點是比較協(xié)議復(fù)雜，而且需要各個節(jié)點間同步信息。

　　節(jié)點管理中心由于不涉及到用戶（2C）的相關(guān)操作操作，訪問量及并發(fā)量都較為有限，所以我們總結(jié)出了JDBC Store active/standby的中心化高可用實現(xiàn)方案，通過JDBC的方式與database交互，使用database的表級排它鎖來實現(xiàn)多節(jié)點爭搶主機節(jié)點，另外還包括節(jié)點狀態(tài)轉(zhuǎn)變（active/standby切換）和客戶端的failover機制。以下分別通過elect leader、status change和client failover分別進行闡述。

　　elect leader詞匯據(jù)我所知是從zookeeper里來的，保證集群中Master的可用性和唯一性。我們的高可用性方案是active/standby，但是因為我的膚淺實在想不出更好的名詞來表達這個爭搶主機這個過程，本文中涉及于此，都會以elect leader來進行描述。

　　兩個節(jié)點管理應(yīng)用同時啟動，我們需要確定一個唯一的應(yīng)用來服務(wù)于其他業(yè)務(wù)節(jié)點，在這之前我們需要創(chuàng)建csserver_ha表用于保存主機節(jié)點的信息，elect leader的主要流程如下：

　　

　　√Lock csserver_ha。

　　√查詢csserver_ha中ha_status = ‘a(chǎn)ctive’的記錄數(shù)。

　　√若結(jié)果為0說明首次啟動，則往csserver_ha新增一條記錄包括該應(yīng)用所在的IP、port、心跳時間（當前時間），狀態(tài)為active，然后setActive(this)，也就是說把該節(jié)點應(yīng)用設(shè)置為主機。

　　√若結(jié)果大于0，說明之前已存在過active的節(jié)點應(yīng)用，此時獲取狀態(tài)為active的記錄，判斷當前和該記錄中的心跳時間（hb_time）的差值。

　　√若小于預(yù)設(shè)值的timeout時間，說明之前存在的active應(yīng)用尚未失效，則seStandby(this)，也就是設(shè)置該節(jié)點應(yīng)用為備機。

　　√若大于等于 timeout時間，說明之前存在的active應(yīng)用已經(jīng)失效，那么設(shè)置該節(jié)點應(yīng)用為主機，即setActive (this)。更新csserver_ha 中active記錄的ip、port、hb_time為當前應(yīng)用信息和當前時間。

　　√Unlock csserver_ha。

　　Status change表示節(jié)點應(yīng)用的內(nèi)部狀態(tài)轉(zhuǎn)變，分別為dead、active、standby，dead表示節(jié)點處于宕機或者應(yīng)用實例未啟動，active表示應(yīng)用實例為主機，standby表示應(yīng)用實例為備機。

　　√當主機轉(zhuǎn)變?yōu)閍ctive時，其他任務(wù)單元方能與之正確通信，并且自啟動心跳日志記錄任務(wù)和腦裂檢測任務(wù)。定時寫心跳日志到表csserver_hb中，表示該節(jié)點應(yīng)用尚淺存活。如果集群單元發(fā)生“腦裂”，那么可想而知會發(fā)生存在兩個主機節(jié)點的情況，其他任務(wù)單元提交的數(shù)據(jù)也被割裂，得不到完整性的保障。在我們的系統(tǒng)中，如果active節(jié)點和數(shù)據(jù)庫之間發(fā)生網(wǎng)絡(luò)中斷，standby檢測到active不可用（假死或者宕機），立即接管服務(wù)，轉(zhuǎn)變?yōu)閍ctive，顯然這個時候有2個active了，那怎么去保證呢？也就是前文所說的腦裂檢測任務(wù)，active節(jié)點不斷的去詢問standby節(jié)點“你是誰？”，standby節(jié)點如果回答“I am active”，那么active節(jié)點降級成standby節(jié)點。或者active節(jié)點和standby節(jié)點也發(fā)生網(wǎng)絡(luò)中斷了，這種情況下，雙active很有可能會出現(xiàn)，為了保證系統(tǒng)對于節(jié)點管理中心的唯一性，active節(jié)點降級轉(zhuǎn)變成standby節(jié)點。

　　√當主機轉(zhuǎn)變?yōu)閟tandby時，其他節(jié)點與之通信返回“服務(wù)不可用”的錯誤碼。standby節(jié)點啟動針對active節(jié)點的健康檢測，主要是不斷的讀取active記錄中的心跳時間hb_time，如果和當前時間的差值超出預(yù)先設(shè)置的timeout時間，則表示active節(jié)點不可用，至此standby節(jié)點切換成active狀態(tài)。Standby扮演著try get the active的角色。

　　√如果active和standby節(jié)點與數(shù)據(jù)庫的網(wǎng)絡(luò)均處于中斷狀態(tài)，那么意味著節(jié)點管理中心集群崩潰。

　　Client failover任務(wù)單元訪問節(jié)點管理中心時需遵循failover:{ip1:port1;ip2:port2}的協(xié)議，client端輪詢訪問ip1和ip2，不需要去區(qū)分active和standby，若返回“服務(wù)不可用”的狀態(tài)碼或者網(wǎng)絡(luò)連接超時就去重試訪問另外一個，如果ip1和ip2均不可用，則說明節(jié)點管理中心集群崩潰。

　　本文僅限于討論小眾范疇的通過MySql共享存儲方式實現(xiàn)高可用方案，其他的例如Keepalived、Zookeeper等實現(xiàn)及文中所涉及的高可用、腦裂、網(wǎng)絡(luò)分區(qū)等概念，讀者可自行Google。

總結(jié)

以上是生活随笔為你收集整理的网易视频云：分布式转码服务高可用浅析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。