共計(jì) 1816 個(gè)字符，預(yù)計(jì)需要花費(fèi) 5 分鐘才能閱讀完成。
本篇內(nèi)容介紹了“storm Transactional spouts 有哪些特性”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
Trident 是以小批量（batch）的形式在處理 tuple，并且每一批都會(huì)分配一個(gè)唯一的 transaction id。不同 spout 的特性不同，一個(gè) transactionalspout 會(huì)有如下這些特性：
1、有著同樣 txid 的 batch 一定是一樣的。當(dāng)重播一個(gè) txid 對(duì)應(yīng)的 batch 時(shí)，一定會(huì)重播和之前對(duì)應(yīng) txid 的 batch 中同樣的 tuples。
2、各個(gè) batch 之間是沒(méi)有交集的。每個(gè) tuple 只能屬于一個(gè) batch
3、每一個(gè) tuple 都屬于一個(gè) batch，無(wú)一例外
這是一類非常容易理解的 spout，tuple 流被劃分為固定的 batch 并且永不改變。（trident-kafka 有一個(gè) transactional spout 的實(shí)現(xiàn)。）
你也許會(huì)問(wèn)：為什么我們不總是使用 transactional spout？這很容易理解。一個(gè)原因是并不是所有的地方都需要容錯(cuò)的。舉例來(lái)說(shuō)，TransactionalTridentKafkaSpout 工作的方式是一個(gè) batch 包含的 tuple 來(lái)自某個(gè) kafka topic 中的所有 partition。一旦這個(gè) batch 被發(fā)出，在任何時(shí)候如果這個(gè) batch 被重新發(fā)出時(shí)，它必須包含原來(lái)所有的 tuple 以滿足 transactional spout 的語(yǔ)義。現(xiàn)在我們假定一個(gè) batch 被 TransactionalTridentKafkaSpout 所發(fā)出，這個(gè) batch 沒(méi)有被成功處理，并且同時(shí) kafka 的一個(gè)節(jié)點(diǎn)也 down 掉了。你就無(wú)法像之前一樣重播一個(gè)完全一樣的 batch（因?yàn)?kakfa 的節(jié)點(diǎn) down 掉，該 topic 的一部分 partition 可能會(huì)無(wú)法使用），整個(gè)處理會(huì)被中斷。
這也就是 opaque transactional spouts（不透明事務(wù) spout）存在的原因 – 他們對(duì)于丟失源節(jié)點(diǎn)這種情況是容錯(cuò)的，仍然能夠幫你達(dá)到有且只有一次處理的語(yǔ)義。后面會(huì)對(duì)這種 spout 有所介紹。
在討論 opaque transactional spout 之前，我們先來(lái)看看怎樣為 transactional spout 設(shè)計(jì)一個(gè)具有 exactly-once 語(yǔ)義的 State 實(shí)現(xiàn)。這個(gè) State 的類型是 transactionalstate 并且它利用了任何一個(gè) txid 總是對(duì)應(yīng)同樣的 tuple 序列這個(gè)語(yǔ)義。
假如說(shuō)你有一個(gè)用來(lái)計(jì)算單詞出現(xiàn)次數(shù)的 topology，你想要將單詞的出現(xiàn)次數(shù)以 key/value 對(duì)的形式存儲(chǔ)到數(shù)據(jù)庫(kù)中。key 就是單詞，value 就是這個(gè)這個(gè)單詞出現(xiàn)的次數(shù)。你已經(jīng)看到只是存儲(chǔ)一個(gè)數(shù)量是不足以知道你是否已經(jīng)處理過(guò)一個(gè) batch 的。你可以通過(guò)將 value 和 txid 一起存儲(chǔ)到數(shù)據(jù)庫(kù)中。這樣的話，當(dāng)更新這個(gè) count 之前，你可以先去比較數(shù)據(jù)庫(kù)中存儲(chǔ)的 txid 和現(xiàn)在要存儲(chǔ)的 txid。如果一樣，就跳過(guò)什么都不做，因?yàn)檫@個(gè) value 之前已經(jīng)被處理過(guò)了。如果不一樣，就執(zhí)行存儲(chǔ)。這個(gè)邏輯可以工作的前提就是 txid 永不改變，并且 Trident 保證狀態(tài)的更新是在 batch 之間嚴(yán)格順序進(jìn)行的。
考慮下面這個(gè)例子的運(yùn)行邏輯，假定你在處理一個(gè) txid 為 3 的包含下面 tuple 的 batch：
[man][man][dog]
假定數(shù)據(jù)庫(kù)中當(dāng)前保存了下面這樣的 key/value 對(duì)：
man = [count=3, txid=1]
dog = [count=4, txid=3]
apple = [count=10, txid=2]
單詞“man”對(duì)應(yīng)的 txid 是 1. 因?yàn)楫?dāng)前的 txid 是 3，你可以確定你還沒(méi)有為這個(gè) batch 中的 tuple 更新過(guò)這個(gè)單詞的數(shù)量。所以你可以放心的給 count 加 2 并更新 txid 為 3. 與此同時(shí)，單詞“dog”的 txid 和當(dāng)前的 txid 是相同的，因此你可以跳過(guò)這次更新。此時(shí)數(shù)據(jù)庫(kù)中的數(shù)據(jù)如下：
man = [count=5, txid=3]
dog = [count=4, txid=3]
apple = [count=10, txid=2]
“storm Transactional spouts 有哪些特性”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
