https://www.cnblogs.com/listenfwind/p/12465409.html
kafka只有l(wèi)eader處理讀寫請求，而es的副班可以處理讀請求，提高性能。
Kafka為什么不提供像 MySQL 那樣允許副本對外提供讀服務(wù)？
原因一：讀數(shù)據(jù)壓力方面：
Kafka 的 Partition 分布在多個broker，當(dāng) Comsuer 消費數(shù)據(jù)的Partiton
是被分配到不同的Broker上，已經(jīng)是負(fù)載均衡之后的請求。
Mysql讀寫數(shù)據(jù)都在主DB上，主DB請求壓力太大，所以需要讀寫分離進行負(fù)載均衡。
原因二：數(shù)據(jù)一致性問題：
Kafka 的副本機制是異步消息拉取，因此就存在 Leader 和 Follwer 之間的不一致性。并且Kafka
保存的數(shù)據(jù)具有消費的概念，是流數(shù)據(jù)，具有嚴(yán)格的順序要求，所以消費需要 Offset。如果從Kafka
的多個Follwer進行讀，Offset無法保證正確性。
Mysql
主從數(shù)據(jù)同步在處理得當(dāng)?shù)那闆r下，在讀數(shù)據(jù)的情況下是很少感受不到主從數(shù)據(jù)不一致。
原因三：應(yīng)用場景：
Mysql在針對就是讀頻繁，寫較少的的場景下，所以采用讀寫分離是很不錯的方案。
Kafka
的使用場景更多情況是消息引擎而不是作為數(shù)據(jù)存儲對外提供讀服務(wù)，通常涉及到頻繁的生產(chǎn)消息和消費消息，不屬于讀多寫少的場景，因此讀寫分離不適用這個Kafka。
