iT邦幫忙

DAY 28
0

分散式資料處理,以Stream Computing為例系列 第 28

Day 28: 錯誤處理機制

昨天講到,Storm用Ackor將所有收到的ID XOR之後,來偵測一筆record是否已完全被處理。今天來講一下,如果遇到問題的話會怎麼處理。

其中一個常見的問題是:運算節點死掉了。所以Ackor收不到某些data id。這種狀況是用一個 timeout機制來解決,如果一段時間內沒收到該資料的第二個id回傳,就直接宣判該筆record處理失敗,要求資料來源(e.g. Kafka)啟動重傳機制。也因為這樣,Storm不能保證exactly-once semantics (ref. day 17)。可能有些資料處理到一半後才重傳,那前半段就會被處理兩次。如同 day 24 所說,這是pure stream computing的特性,會限制 stream computing 的應用範圍

那Ackor死掉要怎麼辦?前面沒講到的是,資料來源也會設timeout,如果Ackor掛了而無法向資料來源發出message的ack,message(record)也會被重送。當然這也是會有不能保證exactly-once semantics的狀況。

那如果資料來源死掉呢?那就真的死掉了。所以像Kafka會需要用replication維持強大的availability,且需要發展stateless的consumer,以便於在錯誤後重啟亦能輕鬆回覆運作。


上一篇
Day 27: 如何追蹤每一個record的處理進度
下一篇
Day 29: 從Stream到Micro batch
系列文
分散式資料處理,以Stream Computing為例30

尚未有邦友留言

立即登入留言