錯(cuò)誤處理是軟件開發(fā)中最困難且被忽略的部分之一，如果系統(tǒng)是分布式的，那么這將變得更加困難。

好的論文寫在“ 簡(jiǎn)單測(cè)試可以預(yù)防最關(guān)鍵的故障” 主題上。

每個(gè)開發(fā)人員都應(yīng)該閱讀本文。 我將嘗試總結(jié)本文的主要內(nèi)容，但建議閱讀該論文以獲取有關(guān)它的更多詳細(xì)信息。

分布式系統(tǒng)中斷很常見，最近的一些例子是

Youtube于2018年10月關(guān)閉約1小時(shí)以上

亞馬遜在2018年7月的黃金交易日下跌

Google，Map，Gmail，Youtube等服務(wù)在2018年經(jīng)歷了無數(shù)次下滑

Facebook還面臨著許多數(shù)據(jù)泄漏問題。

本文討論了在分布式系統(tǒng)（如Cassandra，Hbase，HDFS，Redis，Map Reduce）中發(fā)生的災(zāi)難性故障。

根據(jù)紙張，大多數(shù)錯(cuò)誤是由于2個(gè)原因引起的

–由于復(fù)雜的事件順序而發(fā)生故障

–災(zāi)難性錯(cuò)誤是由于處理不當(dāng)造成的

–我將在我在“ 設(shè)計(jì)壓力對(duì)工程團(tuán)隊(duì)”的帖子中寫到第三篇關(guān)于“忽略設(shè)計(jì)壓力”的文章

HBase中斷示例

1 –負(fù)載平衡器從從站A到從站的傳輸區(qū)域R

2 –從站B的開放區(qū)域R

3 –主從屬B擁有后，刪除當(dāng)前的Zookeeper區(qū)域R

4 –從屬B模具

5 –將區(qū)域R分配給從屬C和從屬C打開區(qū)域

6 – Master嘗試刪除Zookeeper上的Slave B znode，并且由于錯(cuò)誤的錯(cuò)誤處理代碼，slave b關(guān)閉并且整個(gè)集群關(guān)閉。

在上面的示例中，事件序列對(duì)于重現(xiàn)問題很重要。

當(dāng)不復(fù)制塊時(shí)，HDFS失敗。

在此示例中，事件序列也是如此，當(dāng)新數(shù)據(jù)節(jié)點(diǎn)啟動(dòng)時(shí)，它將暴露系統(tǒng)錯(cuò)誤。

紙上還有更多例子。

錯(cuò)誤的根本原因

92％的災(zāi)難性錯(cuò)誤是由于錯(cuò)誤處理而發(fā)生的。

這意味著扣除了錯(cuò)誤，但錯(cuò)誤處理代碼卻不好，這聽起來像您正在從事的許多項(xiàng)目！

1 –錯(cuò)誤被忽略
這是25％失敗的原因，我認(rèn)為在許多實(shí)時(shí)系統(tǒng)中，這個(gè)數(shù)字會(huì)很高。

eg of such error catch(RebootException e) { log.info("Reboot occurred....") }

是的，此無害的日志語句忽略了異常，是錯(cuò)誤處理的非常常見的反模式。

2 –追趕異常
這也很常見，例如具有通用的catch塊并破壞整個(gè)系統(tǒng)

catch(Throwable e) { cluster.abort() }

3 –評(píng)論中的TODO / FIXME
是的，生產(chǎn)中的實(shí)際分布式系統(tǒng)在代碼的關(guān)鍵部分也有很多TODO / FIXME。

錯(cuò)誤處理的其他示例

} catch (IOException e) {?// will never happen ?}} catch (NoTransitionException e) {?/* Why this can happen? Ask God not me. */ ?}try { tableLock.release(); } catch (IOException e) { ?LOG("Can't release lock”, e); }?

4 –優(yōu)先開發(fā)功能
我認(rèn)為所有軟件工程師都會(huì)同意。 這也稱為技術(shù)債務(wù)，我想不出比Knight Capital破產(chǎn)更好的例子了，這是由于配置和實(shí)驗(yàn)代碼所致。

結(jié)論

所有錯(cuò)誤都是很復(fù)雜的，但是重現(xiàn)更好的單元測(cè)試肯定會(huì)抓住這些錯(cuò)誤，這也表明，在許多系統(tǒng)中進(jìn)行的單元/集成測(cè)試并不是在測(cè)試諸如服務(wù)中斷并再次返回以及如何影響系統(tǒng)的場(chǎng)景。

根據(jù)上面的示例，看起來所有錯(cuò)誤都是由于Java檢查異常引起的，但是在其他系統(tǒng)（如C / C ++）中沒有檢查但未檢查所有內(nèi)容的情況卻沒有什么不同，開發(fā)人員有責(zé)任在各個(gè)地方進(jìn)行檢查。

附帶說明一下，沒有像Python這樣的類型系統(tǒng)的語言使編寫在運(yùn)行時(shí)中斷的代碼變得非常容易，并且如果您真的很不幸，那么錯(cuò)誤處理代碼將出現(xiàn)類型錯(cuò)誤，并且將在生產(chǎn)中進(jìn)行測(cè)試。

同樣，幾乎所有產(chǎn)品都將具有一些靜態(tài)代碼工具（findbugs）集成，但是這些工具并沒有更加重視這種錯(cuò)誤處理反模式。

鏈接到論文中提到的問題

HDFS

MapReduce

HBase的

雷迪斯

卡桑德拉

請(qǐng)分享您在生產(chǎn)系統(tǒng)中看到的更多反模式。

直到快樂的單元測(cè)試。

翻譯自: https://www.javacodegeeks.com/2018/10/simple-testing-prevent-critical-failures.html

總結(jié)

以上是生活随笔為你收集整理的简单的测试可以防止最严重的故障的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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