Kafka居然不支持读写分离！今天才知道！

Kafka居然不支持读写分离！今天才知道！ 在 Kafka 中，生产者写入消息、消费者读取消息的操做都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。数据库、Redis 等都具有主写主读的功能，与此同时还支持主写从读的功能，主写从读也就是读写分离，为了与主写主读对应，这里就以主写从读来称呼!

在 Kafka 中，生产者写入消息、消费者读取消息的操做都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。数据库、Redis 等都具有主写主读的功能，与此同时还支持主写从读的功能，主写从读也就是读写分离，为了与主写主读对应，这里就以主写从读来称呼!

Kafka 并不支持主写从读，这是为何呢?

从代码层面上来讲，虽然增长了代码复杂度，但在 Kafka 中这种功能彻底能够支持。对于 这个问题，咱们能够从“收益点”这个角度来作具体分析。主写从读可让从节点去分担主节 点的负载压力，预防主节点负载太重而从节点却空闲的状况发生。可是主写从读也有 2 个很明显的缺点:

• 数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会致使主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 以后将主节点中 A 的值修改成 Y，那么在这个变动通知到从节点以前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。
• 延时问题。相似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程须要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费必定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它须要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

现实状况下，不少应用既能够忍受必定程度上的延时，也能够忍受一段时间内的数据不一致的状况!

那么对于这种状况，Kafka 是否有必要支持主写从读的功能呢?

主写从读能够均摊必定的负载却不能作到彻底的负载均衡，好比对于数据写压力很大而读 压力很小的状况，从节点只能分摊不多的负载压力，而绝大多数压力仍是在主节点上。而在 Kafka 中却能够达到很大程度上的负载均衡，并且这种均衡是在主写主读的架构上实现的。咱们来看 一下 Kafka 的生产消费模型，以下图所示：

在 Kafka 集群中有 3 个分区，每一个分区有 3 个副本，正好均匀地分布在 3个 broker 上，灰色阴影的表明 leader 副本，非灰色阴影的表明 follower 副本，虚线表示 follower 副本从 leader 副本上拉取消息。当生产者写入消息的时候都写入 leader 副本，对于上图中的情形，每一个 broker 都有消息从生产者流入;当消费者读取消息的时候也是从 leader 副本中读取 的，对于图 8-23 中的情形，每一个 broker 都有消息流出到消费者。

咱们很明显地能够看出，每一个 broker上的读写负载都是同样的，这就说明 Kafka 能够经过 主写主读实现主写从读实现不了的负载均衡。上图展现是一种理想的部署状况，有如下几种 状况(包含但不只限于)会形成必定程度上的负载不均衡：

(1)broker 端的分区分配不均。当建立主题的时候可能会出现某些 broker 分配到的分区数 多而其余 broker 分配到的分区数少，那么天然而然地分配到的 leader 副本也就不均。

(2)生产者写入消息不均。生产者可能只对某些 broker 中的 leader 副本进行大量的写入操 做，而对其余 broker 中的 leader 副本漠不关心。

(3)消费者消费消息不均。消费者可能只对某些 broker 中的 leader 副本进行大量的拉取操 做，而对其余 broker 中的 leader 副本漠不关心。

(4)leader 副本的切换不均。在实际应用中可能会因为 broker 宕机而形成主从副本的切换， 或者分区副本的重分配等，这些动做都有可能形成各个 broker 中 leader 副本的分配不均。

对此，咱们能够作一些防范措施。

针对第一种状况，在主题建立的时候尽量使分区分配 得均衡，好在 Kafka 中相应的分配算法也是在极力地追求这一目标，若是是开发人员自定义的 分配，则须要注意这方面的内容。对于第二和第三种状况，主写从读也没法解决。对于第四种 状况，Kafka 提供了优先副本的选举来达到 leader 副本的均衡，与此同时，也能够配合相应的 监控、告警和运维平台来实现均衡的优化。

在实际应用中，配合监控、告警、运维相结合的生态平台，在绝大多数状况下 Kafka 都能 作到很大程度上的负载均衡。

总的来讲，Kafka 只支持主写主读有几个优势：

能够简化代码的实现逻辑，减小出错的可能;将负载粒度细化均摊，与主写从读相比，不只负载效能更好，并且对用户可控;没有延时的影响;

在副本稳定的状况下，不会出现数据不一致的状况。为此，Kafka 又何须再去实现对它而言毫无收益的主写从读的功能呢?这一切都得益于 Kafka 优秀的架构设计，从某种意义上来讲，主写从读是因为设计上的缺陷而造成的权宜之计。

以为不错请点赞支持，欢迎留言或进个人我的群855801563领取【架构资料专题目合集90期】、【BATJTMD大厂JAVA面试真题1000+】，本群专用于学习交流技术、分享面试机会，拒绝广告，我也会在群内不按期答题、探讨。