转自https://blog.csdn.net/weiaiyisheng_ljj/article/details/102913395
Kafka为什么不提供像 MySQL 那样允许副本对外提供读服务?
原因一:读数据压力方面:
- Kafka 的 Partition 分布在多个broker,当 Comsuer 消费数据的Partiton
是被分配到不同的Broker上,已经是负载均衡之后的请求。
*Mysql读写数据都在主DB上,主DB请求压力太大,所以需要读写分离进行负载均衡。
原因二:数据一致性问题:
- Kafka 的副本机制是异步消息拉取,因此就存在 Leader 和 Follwer 之间的不一致性。并且Kafka
保存的数据具有消费的概念,是流数据,具有严格的顺序要求,所以消费需要 Offset。如果从Kafka
的多个Follwer进行读,Offset无法保证正确性。 - Mysql
主从数据同步在处理得当的情况下,在读数据的情况下是很少感受不到主从数据不一致。
原因三:应用场景:
- Mysql在针对就是读频繁,写较少的的场景下,所以采用读写分离是很不错的方案。
- Kafka
的使用场景更多情况是消息引擎而不是作为数据存储对外提供读服务,通常涉及到频繁的生产消息和消费消息,不属于读多写少的场景,因此读写分离不适用这个Kafka。
为什么后来路转粉了
Kafka在2.4版本的时候,推出了新特性,KIP-392: 允许消费者从最近的跟随者副本获取数据。这样,就等于给了我们读写分离的选择。
那为什么路转粉了呢?
因为有了这样的适用场景,kafka存在多个数据中心,而数据中心存在于不同机房,当其中一个数据中心需要向另一个数据中心同步数据的时候,如果只能从首领副本进行数据读取的话,需要跨机房来完成,而这些流量带宽又比较昂贵,而利用本地跟随者副本进行消息读取就成了比较明智的选择。
所以kafka推出这一个功能,目的并不是降低broker的系统负载,分摊消息处理量,而是为了节约流量资源。
详情请看,转自https://zhuanlan.zhihu.com/p/404122105