這篇文章主要介紹storm中acker機(jī)制的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的長沙網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

首先來看一下什么叫做記錄級(jí)容錯(cuò)？storm允許用戶在spout中發(fā)射一個(gè)新的源tuple時(shí)為其指定一個(gè)message id, 這個(gè)message id可以是任意的object對(duì)象。多個(gè)源tuple可以共用一個(gè)message id，表示這多個(gè)源 tuple對(duì)用戶來說是同一個(gè)消息單元。storm中記錄級(jí)容錯(cuò)的意思是說，storm會(huì)告知用戶每一個(gè)消息單元是否在指定時(shí)間內(nèi)被完全處理了。那什么叫做完全處理呢，就是該message id綁定的源tuple及由該源tuple后續(xù)生成的tuple經(jīng)過了topology中每一個(gè)應(yīng)該到達(dá)的bolt的處理。舉個(gè)例子。在圖4-1中，在spout由message 1綁定的tuple1和tuple2經(jīng)過了bolt1和bolt2的處理生成兩個(gè)新的tuple，并最終都流向了bolt3。當(dāng)這個(gè)過程完成處理完時(shí)，稱message 1被完全處理了。

在storm的topology中有一個(gè)系統(tǒng)級(jí)組件，叫做acker。這個(gè)acker的任務(wù)就是追蹤從spout中流出來的每一個(gè)message id綁定的若干tuple的處理路徑，如果在用戶設(shè)置的最大超時(shí)時(shí)間內(nèi)這些tuple沒有被完全處理，那么acker就會(huì)告知spout該消息處理失敗了，相反則會(huì)告知spout該消息處理成功了。在剛才的描述中，我們提到了”記錄tuple的處理路徑”，如果曾經(jīng)嘗試過這么做的同學(xué)可以仔細(xì)地思考一下這件事的復(fù)雜程度。但是storm中卻是使用了一種非常巧妙的方法做到了。在說明這個(gè)方法之前，我們來復(fù)習(xí)一個(gè)數(shù)學(xué)定理。

A xor A = 0.

A xor B…xor B xor A = 0，其中每一個(gè)操作數(shù)出現(xiàn)且僅出現(xiàn)兩次。

storm中使用的巧妙方法就是基于這個(gè)定理。具體過程是這樣的：在spout中系統(tǒng)會(huì)為用戶指定的message id生成一個(gè)對(duì)應(yīng)的64位整數(shù)，作為一個(gè)root id。root id會(huì)傳遞給acker及后續(xù)的bolt作為該消息單元的唯一標(biāo)識(shí)。同時(shí)無論是spout還是bolt每次新生成一個(gè)tuple的時(shí)候，都會(huì)賦予該tuple一個(gè)64位的整數(shù)的id。Spout發(fā)射完某個(gè)message id對(duì)應(yīng)的源tuple之后，會(huì)告知acker自己發(fā)射的root id及生成的那些源tuple的id。而bolt呢，每次接受到一個(gè)輸入tuple處理完之后，也會(huì)告知acker自己處理的輸入tuple的id及新生成的那些tuple的id。Acker只需要對(duì)這些id做一個(gè)簡單的異或運(yùn)算，就能判斷出該root id對(duì)應(yīng)的消息單元是否處理完成了。下面通過一個(gè)圖示來說明這個(gè)過程。

spout中綁定message 1生成了兩個(gè)源tuple，id分別是0010和1011.

bolt1處理tuple 0010時(shí)生成了一個(gè)新的tuple，id為0110.

 bolt2處理tuple 1011時(shí)生成了一個(gè)新的tuple，id為0111.

bolt3中接收到tuple 0110和tuple 0111，沒有生成新的tuple.

可能有些細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)，容錯(cuò)過程存在一個(gè)可能出錯(cuò)的地方，那就是，如果生成的tuple id并不是完全各異的，acker可能會(huì)在消息單元完全處理完成之前就錯(cuò)誤的計(jì)算為0。這個(gè)錯(cuò)誤在理論上的確是存在的，但是在實(shí)際中其概率是極低極低的，完全可以忽略。

以上是“storm中acker機(jī)制的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！