https://www.cnblogs.com/listenfwind/p/12465409.html

kafka只有l(wèi)eader處理讀寫請(qǐng)求，而es的副班可以處理讀請(qǐng)求，提高性能。

Kafka為什么不提供像 MySQL 那樣允許副本對(duì)外提供讀服務(wù)？

原因一：讀數(shù)據(jù)壓力方面：

Kafka 的 Partition 分布在多個(gè)broker，當(dāng) Comsuer 消費(fèi)數(shù)據(jù)的Partiton

是被分配到不同的Broker上，已經(jīng)是負(fù)載均衡之后的請(qǐng)求。

Mysql讀寫數(shù)據(jù)都在主DB上，主DB請(qǐng)求壓力太大，所以需要讀寫分離進(jìn)行負(fù)載均衡。

原因二：數(shù)據(jù)一致性問題：

Kafka 的副本機(jī)制是異步消息拉取，因此就存在 Leader 和 Follwer 之間的不一致性。并且Kafka

保存的數(shù)據(jù)具有消費(fèi)的概念，是流數(shù)據(jù)，具有嚴(yán)格的順序要求，所以消費(fèi)需要 Offset。如果從Kafka

的多個(gè)Follwer進(jìn)行讀，Offset無法保證正確性。

Mysql

主從數(shù)據(jù)同步在處理得當(dāng)?shù)那闆r下，在讀數(shù)據(jù)的情況下是很少感受不到主從數(shù)據(jù)不一致。

原因三：應(yīng)用場(chǎng)景：

Mysql在針對(duì)就是讀頻繁，寫較少的的場(chǎng)景下，所以采用讀寫分離是很不錯(cuò)的方案。

Kafka

的使用場(chǎng)景更多情況是消息引擎而不是作為數(shù)據(jù)存儲(chǔ)對(duì)外提供讀服務(wù)，通常涉及到頻繁的生產(chǎn)消息和消費(fèi)消息，不屬于讀多寫少的場(chǎng)景，因此讀寫分離不適用這個(gè)Kafka。