~！1：卡夫卡在2011捐贈(zèng)給阿帕奇基金會(huì)，拉夫的論文是在尋找一個(gè)潛在的共識算法，由斯坦福大學(xué)在2013出版，卡夫卡出生在RAFT之前。當(dāng)1/3節(jié)點(diǎn)不可用時(shí)，服務(wù)不可用。Kafka中維護(hù)的ISR（in

~！1：卡夫卡在2011捐贈(zèng)給阿帕奇基金會(huì)，拉夫的論文是在尋找一個(gè)潛在的共識算法，由斯坦福大學(xué)在2013出版，卡夫卡出生在RAFT之前。當(dāng)1/3節(jié)點(diǎn)不可用時(shí)，服務(wù)不可用。Kafka中維護(hù)的ISR（in-sync replica，同步副本）可以提供服務(wù)，即使副本不可用，只剩下領(lǐng)頭羊

3:更大的數(shù)據(jù)吞吐量。Raft適用于強(qiáng)一致性

flume和Kafka有一些相同的功能，但總的來說，它們有很大的不同；它們的場景不同，但可以一起使用。

簡而言之，flume是一個(gè)分布式日志收集系統(tǒng)，它從各種服務(wù)器收集日志并將其傳輸?shù)街付ǖ奈恢?，如HDFS。

Kafka是一個(gè)分布式消息中間件，有自己的存儲(chǔ)，提供推拉數(shù)據(jù)訪問功能。

整個(gè)過程如下：

登錄服務(wù)器<--flume-->kafka-->hdfs-->離線計(jì)算

登錄服務(wù)器<--flume-->kafka-->storm

希望我的回答能對您有所幫助

kafka的一致性為什么不替換成raft？

感謝您邀請我回答此問題。作為卡夫卡多年的使用者，我對使用卡夫卡的感覺還是很好的。

卡夫卡的每個(gè)數(shù)據(jù)流應(yīng)該對應(yīng)一個(gè)主題，每個(gè)主題可以有多個(gè)部分?，F(xiàn)在每個(gè)零件只能由一個(gè)消費(fèi)者消費(fèi)。更多的分區(qū)意味著更多的吞吐量。需要更多的文件句柄。如果使用者較少，則更多的分區(qū)將浪費(fèi)系統(tǒng)資源。從另一個(gè)角度看，越來越多的延遲將增加，這將對實(shí)時(shí)數(shù)據(jù)讀寫產(chǎn)生不利影響。

因此，適當(dāng)?shù)姆謪^(qū)數(shù)量將對Kafka的性能產(chǎn)生重要影響。