作為全球新冠疫情數據的實時統計的權威，約翰斯—霍普金斯大學的實時數據一直是大家實時關註的，也是各大媒體的主要數據來源。在今天早上的相當一段長的時間，霍普金斯大學的全球疫情分佈大屏中顯示，全球確診人數已經突破200萬。 有圖有真相 隨後相關媒體也進行了轉發，不過這個數據明顯波動太大，隨後該網站也修改了 ...
作為全球新冠疫情數據的實時統計的權威，約翰斯—霍普金斯大學的實時數據一直是大家實時關註的，也是各大媒體的主要數據來源。在今天早上的相當一段長的時間，霍普金斯大學的全球疫情分佈大屏中顯示，全球確診人數已經突破200萬。
有圖有真相
隨後相關媒體也進行了轉發，不過這個數據明顯波動太大，隨後該網站也修改了數據
約翰斯·霍普金斯大學系統科學與工程中心就製作了“全球新冠病毒擴散地圖”，用於實時可視化和跟蹤報告的病例。於1月22日首次公開。
為了提高數據的實時性，數據的來源通過手動和自動獲取的方式。手動的方式出錯的概率還是很大的，如果我們可以通過實時流獲取數據的方式，就可以避免數據錯誤的問題，這其實是數據從一方到達另一方的數據是否準確的問題，也就是端到端的一致性。
這種消息傳遞的定義叫做消息傳遞語義：
我們要瞭解的是message delivery semantic 也就是消息傳遞語義。
這是一個通用的概念，也就是消息傳遞過程中消息傳遞的保證性。
分為三種：
最多一次（at most once）: 消息可能丟失也可能被處理，但最多只會被處理一次。
可能丟失 不會重覆
至少一次（at least once）: 消息不會丟失，但可能被處理多次。
可能重覆 不會丟失
精確傳遞一次（exactly once）: 消息被處理且只會被處理一次。
不丟失 不重覆 就一次
那麼我們希望能做到精確傳遞一次（exactly once），雖然可能會付出一些性能的代價。
我們從幾個常見的流計算框架中，看一看都是如何解決端到端的一致性的問題。
1、Kafka
Kafka是最初由Linkedin公司開發，是一個分散式、支持分區的（partition）、多副本的（replica），基於zookeeper協調的分散式消息系統，它的最大的特性就是可以實時的處理大量數據以滿足各種需求場景：比如基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎，web/nginx日誌、訪問日誌，消息服務等等，用scala語言編寫，Linkedin於2010年貢獻給了Apache基金會併成為頂級開源項目。
而kafka其實有兩次消息傳遞，一次生產者發送消息給kafka，一次消費者去kafka消費消息。
兩次傳遞都會影響最終結果，
兩次都是精確一次，最終結果才是精確一次。
兩次中有一次會丟失消息，或者有一次會重覆，那麼最終的結果就是可能丟失或者重覆的。
一、Produce端消息傳遞
這是producer端的代碼：
Properties properties = new Properties();
properties.put("bootstrap.servers", "kafka01:9092,kafka02:9092");
properties.put("acks", "all");
properties.put("retries", 0);
properties.put("batch.size", 16384);
properties.put("linger.ms", 1);
properties.put("buffer.memory", 33554432);
properties.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
properties.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties);
for (int i = 1; i <= 600; i++) {
kafkaProducer.send(new ProducerRecord<String, String>("z_test_20190430", "testkafka0613"+i));
System.out.println("testkafka"+i);
}
kafkaProducer.close();
其中指定了一個參數acks 可以有三個值選擇：
0：producer完全不管broker的處理結果 回調也就沒有用了 並不能保證消息成功發送 但是這種吞吐量最高
all或者-1：leader broker會等消息寫入 並且ISR都寫入後 才會響應，這種只要ISR有副本存活就肯定不會丟失，但吞吐量最低。
1：預設的值 leader broker自己寫入後就響應，不會等待ISR其他的副本寫入，只要leader broker存活就不會丟失，即保證了不丟失，也保證了吞吐量。
所以設置為0時，實現了at most once，而且從這邊看只要保證集群穩定的情況下，不設置為0，消息不會丟失。
但是還有一種情況就是消息成功寫入，而這個時候由於網路問題producer沒有收到寫入成功的響應，producer就會開啟重試的操作，直到網路恢復，消息就發送了多次。這就是at least once了。
kafka producer 的參數acks 的預設值為1，所以預設的producer級別是at least once。並不能exactly once。
二、Consumer端消息傳遞
consumer是靠offset保證消息傳遞的。
consumer消費的代碼如下：
Properties props = new Properties();
props.put("bootstrap.servers", "kafka01:9092，kafka02:9092");
props.put("group.id", "test");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("auto.offset.reset","earliest");
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("foo", "bar"));
try{
while (true) {
ConsumerRecords<String, String> records = consumer.poll(1000);
for (ConsumerRecord<String, String> record : records) {
System.out.printf("offset = %d, key = %s, value = %s%n", record.offset(), record.key(), record.value());
}
}
}finally{
consumer.close();
}
其中有一個參數是 enable.auto.commit
若設置為true consumer在消費之前提交位移 就實現了at most once
若是消費後提交 就實現了 at least once 預設的配置就是這個。
kafka consumer的參數enable.auto.commit的預設值為true ，所以預設的consumer級別是at least once。也並不能exactly once。
圖 consumer-groups
三、精確一次
通過瞭解producer端與consumer端的設置，我們發現kafka在兩端的預設配置都是at least once，肯能重覆，通過配置的話呢也不能做到exactly once，好像kafka的消息一定會丟失或者重覆的，是不是沒有辦法做到exactly once了呢？
確實在kafka 0.11.0.0版本之前producer端確實是不可能的，但是在kafka 0.11.0.0版本之後，kafka正式推出了idempotent producer。
也就是冪等的producer還有對事務的支持。
冪等的producer
kafka 0.11.0.0版本引入了idempotent producer機制，在這個機制中同一消息可能被producer發送多次，但是在broker端只會寫入一次，他為每一條消息編號去重，而且對kafka開銷影響不大。
如何設置開啟呢？ 需要設置producer端的新參數 enable.idempotent 為true。
而多分區的情況，我們需要保證原子性的寫入多個分區，即寫入到多個分區的消息要麼全部成功，要麼全部回滾。
這時候就需要使用事務，在producer端設置 transcational.id為一個指定字元串。
這樣冪等producer只能保證單分區上無重覆消息；事務可以保證多分區寫入消息的完整性。
圖 事務
這樣producer端實現了exactly once，那麼consumer端呢？
consumer端由於可能無法消費事務中所有消息，並且消息可能被刪除，所以事務並不能解決consumer端exactly once的問題，我們可能還是需要自己處理這方面的邏輯。比如自己管理offset的提交，不要自動提交，也是可以實現exactly once的。
還有一個選擇就是使用kafka自己的流處理引擎，也就是Kafka Streams，
設置processing.guarantee=exactly_once，就可以輕鬆實現exactly once了。
2、Flink
Apache Flink是由Apache軟體基金會開發的開源流處理框架，其核心是用Java和Scala編寫的分散式流數據流引擎。Flink以數據並行和流水線方式執行任意流數據程式，Flink的流水線運行時系統可以執行批處理和流處理程式。此外，Flink的運行時本身也支持迭代演算法的執行。
我們從flink消費並寫入kafka的例子是如何通過兩部提交來保證exactly-once語義的
為了保證exactly-once，所有寫入kafka的操作必須是事物的。在兩次checkpiont之間要批量提交數據，這樣在任務失敗後就可以將沒有提交的數據回滾。
兩部提交協議的第一步是預提交。flink的jobmanager會在數據流中插入一個檢查點的標記（這個標記可以用來區別這次checkpoint的數據和下次checkpoint的數據）。
這個標記會在整個dag中傳遞。每個dag中的運算元遇到這個標記就會觸發這個運算元狀態的快照。
讀取kafka的運算元，在遇到檢查點標記時會存儲kafka的offset。之後，會把這個檢查點標記傳到下一個運算元。
接下來就到了flink的記憶體操作運算元。這些內部運算元就不用考慮兩部提交協議了，因為他們的狀態會隨著flink整體的狀態來更新或者回滾。
到了和外部系統打交道的時候，就需要兩步提交協議來保證數據不丟失不重覆了。在預提交這個步驟下，所有向kafka提交的數據都是預提交。
當所有運算元的快照完成，也就是這次的checkpoint完成時，flink的jobmanager會向所有運算元發通知說這次checkpoint完成，flink負責向kafka寫入數據的運算元也會正式提交之前寫操作的數據。在任務運行中的任何階段失敗，都會從上一次的狀態恢復，所有沒有正式提交的數據也會回滾。
總結一下flink的兩步提交：
當所有運算元都完成他們的快照時，進行正式提交操作
當任意子任務在預提交階段失敗時，其他任務立即停止，並回滾到上一次成功快照的狀態。
在預提交狀態成功後，外部系統需要完美支持正式提交之前的操作。如果有提交失敗發生，整個flink應用會進入失敗狀態並重啟，重啟後將會繼續從上次狀態來嘗試進行提交操作。
這樣flink就通過狀態和兩次提交協議來保證了端到端的exactly-once語義。
更多大數據，實時計算相關博文與科技資訊，歡迎搜索或者掃描下方關註 “實時流式計算”
