原文地址：http://blog.csdn.net/honglei915/article/details/37565119

之前討論了consumer和producer是怎么工作的，現(xiàn)在來討論一下數(shù)據(jù)傳輸方面。數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：

最多一次:?消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸。

最少一次:?消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.

精確的一次（Exactly once）:??不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。

大多數(shù)消息系統(tǒng)聲稱可以做到“精確的一次”，但是仔細(xì)閱讀它們的的文檔可以看到里面存在誤導(dǎo)，比如沒有說明當(dāng)consumer或producer失敗時(shí)怎么樣，或者當(dāng)有多個(gè)consumer并行時(shí)怎么樣，或?qū)懭胗脖P的數(shù)據(jù)丟失時(shí)又會(huì)怎么樣。kafka的做法要更先進(jìn)一些。當(dāng)發(fā)布消息時(shí)，Kafka有一個(gè)“committed”的概念，一旦消息被提交了，只要消息被寫入的分區(qū)的所在的副本broker是活動(dòng)的，數(shù)據(jù)就不會(huì)丟失。關(guān)于副本的活動(dòng)的概念，下節(jié)文檔會(huì)討論。現(xiàn)在假設(shè)broker是不會(huì)down的。
如果producer發(fā)布消息時(shí)發(fā)生了網(wǎng)絡(luò)錯(cuò)誤，但又不確定實(shí)在提交之前發(fā)生的還是提交之后發(fā)生的，這種情況雖然不常見，但是必須考慮進(jìn)去，現(xiàn)在Kafka版本還沒有解決這個(gè)問題，將來的版本正在努力嘗試解決。
并不是所有的情況都需要“精確的一次”這樣高的級(jí)別，Kafka允許producer靈活的指定級(jí)別。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發(fā)送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。

現(xiàn)在從consumer的方面考慮這個(gè)問題，所有的副本都有相同的日志文件和相同的offset，consumer維護(hù)自己消費(fèi)的消息的offset，如果consumer不會(huì)崩潰當(dāng)然可以在內(nèi)存中保存這個(gè)值，當(dāng)然誰(shuí)也不能保證這點(diǎn)。如果consumer崩潰了，會(huì)有另外一個(gè)consumer接著消費(fèi)消息，它需要從一個(gè)合適的offset繼續(xù)處理。這種情況下可以有以下選擇：

• consumer可以先讀取消息，然后將offset寫入日志文件中，然后再處理消息。這存在一種可能就是在存儲(chǔ)offset后還沒處理消息就crash了，新的consumer繼續(xù)從這個(gè)offset處理，那么就會(huì)有些消息永遠(yuǎn)不會(huì)被處理，這就是上面說的“最多一次”。
• consumer可以先讀取消息，處理消息，最后記錄offset，當(dāng)然如果在記錄offset之前就crash了，新的consumer會(huì)重復(fù)的消費(fèi)一些消息，這就是上面說的“最少一次”。
• “精確一次”可以通過將提交分為兩個(gè)階段來解決：保存了offset后提交一次，消息處理成功之后再提交一次。但是還有個(gè)更簡(jiǎn)單的做法：將消息的offset和消息被處理后的結(jié)果保存在一起。比如用Hadoop ETL處理消息時(shí)，將處理后的結(jié)果和offset同時(shí)保存在HDFS中，這樣就能保證消息和offser同時(shí)被處理了。

總結(jié)

以上是生活随笔為你收集整理的漫游Kafka设计篇之消息传输的事务定义的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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