分布式系統(tǒng)雖然強大但不是沒有缺點，對直播源碼開發(fā)來說，分布式系統(tǒng)出現(xiàn)故障后該如何處理關系到平臺的響應速度，我們在之前的文章中分享了關于分布式系統(tǒng)較常見的故障，我們具體來看一下都可能出現(xiàn)哪些問題。

?

一、節(jié)點崩潰

這是很常見的問題，直播源碼開發(fā)響應請求靠的是各個節(jié)點，而我們都知道分布式系統(tǒng)強就強在各個節(jié)點之間不會互相干擾且可以接手其他節(jié)點的工作，節(jié)點崩潰強調的就是失敗節(jié)點不需要再參與回分布式系統(tǒng)內(nèi)部了，這種情況比較好處理，失敗節(jié)點退出后，其他節(jié)點感知到后可以繼續(xù)提供服務，不同考慮它重新回歸帶來的復雜問題。

但是節(jié)點崩潰給直播源碼開發(fā)帶來的是資源浪費的問題，一般平臺要采用崩潰恢復模式來重復利用資源。

?

二、遺漏失敗

對比來說，遺漏失敗比崩潰失敗更為不可預測，這種模式強調的是消息有沒有被遠程節(jié)點所執(zhí)行。

可能會出現(xiàn)，消息發(fā)送后沒有送達遠程節(jié)點；遠程節(jié)點跳過消息的處理貨根本無法執(zhí)行；后者處理結果無法發(fā)送給其他節(jié)點等。簡單點來說，直播源碼開發(fā)用于響應用戶而傳遞出去的信息石沉大海了。

當出現(xiàn)這個問題時，直播源碼開發(fā)可以通過重發(fā)等可靠連接手段來緩解這個問題，如果仍然無法發(fā)出消息，就要考慮讓其他節(jié)點接手了。

?

三、拜占庭失敗

又被稱為任意失敗，屬于最不可控的失敗方式之一，任意失敗指的是參與的節(jié)點對請求產(chǎn)生了不一致的影響，這個故障往往是因為直播源碼開發(fā)程序bug導致的，可以通過嚴格軟件開發(fā)流程管理來盡可能的避免，所以在直播源碼開發(fā)運行時，一部分系統(tǒng)并不信任直接從遠程節(jié)點獲得的數(shù)據(jù)，而是采用交叉檢測的方式來得到正確結果。

另一種任意失敗的一些節(jié)點故意發(fā)送錯誤消息，目的是想破壞系統(tǒng)的正常運行，可以采用區(qū)塊鏈技術的數(shù)字貨幣系統(tǒng)則是使用正面的BFT模式，來保證系統(tǒng)內(nèi)大部分節(jié)點正常。

聲明：以上內(nèi)容為云豹科技作者本人原創(chuàng)，未經(jīng)作者本人同意，禁止轉載，否則將追究相關法律責任