在Kafka中，生产者写消息和消费者读消息的操作都与leader副本进行交互，从而实现了主写主读的生产消费模型。数据库、Redis等都有主写主读的功能。同时还支持主写从读功能。主写和从读，就是读和写的分离。让我们打电话吧！Kafka不支持主写从读。为什么？从代码层面来说，虽然增加了代码的复杂度，但是这个功能在Kafka中是完全可以支持的。对于这个问题，我们可以从“收入点”的角度来具体分析。主写从读可以让从节点分担主节点的负载压力，防止出现主节点过载而从节点空闲的情况。但是主写从读有两个明显的缺点：数据一致性问题。数据从主节点传输到从节点必须有一个延迟的时间窗口，这个时间窗口会导致主从节点之间的数据不一致。某一时刻，A数据在主节点和从节点中的值为X，然后将主节点中A的值更改为Y，然后在更改通知到从节点之前，应用程序读取从节点中A数据的值并不是最好的Y，从而导致数据不一致的问题。延迟问题。对于Redis这样的组件，从向主节点写入数据到同步到从节点的过程需要经历几个阶段：网络→主节点内存→网络→从节点内存，整个过程会耗费一定的时间.在Kafka中，主从同步比Redis更耗时，需要经过网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘等阶段。对于延迟敏感的应用，主写从读的功能不太适合。现实中很多应用不仅可以容忍一定程度的延迟，还可以容忍一段时间内的数据不一致！那么对于这种情况，Kafka是否有必要支持主写从读的功能呢？主写从读可以分担一定的负载但不能做到完全的负载均衡。例如，在数据写入压力大、读取压力小的情况下，从节点只能分担很小的负载压力，大部分压力还是在主节点上。优越的。而在Kafka中，很大程度上可以做到负载均衡，这种均衡是在主写主读的架构上实现的。我们来看看Kafka的生产和消费模型，如下图所示：Kafka集群中有3个partition，每个partition有3个副本，均匀分布在3个broker上。灰色阴影代表leader副本，非灰色阴影代表follower副本，虚线表示follower副本从leader副本拉取消息。当生产者写入消息时，它被写入领导副本。对于上图的情况，每个broker都有一条消息从producer流入；当消费者读取消息时，它也会从领导者副本中读取。对于图8-23的情况，每个broker都有消息流出给消费者。我们可以清楚的看到每个broker上的读写负载是一样的，也就是说Kafka可以通过master-write和master-read实现master-write和slave-read无法实现的负载均衡。上图是一个理想的部署情况。以下几种情况（包括但不限于）会造成一定程度的负载不平衡：（1）broker端partition分布不均匀。创建topic时，可能有的broker分配的partition多，有的broker分配的partition少，自然分配的leader副本会参差不齐。(2)生产者写入消息不均匀。producer可能只对部分broker中的leader副本进行大量写操作，而忽略其他broker中的leader副本。(3)消费者消费新闻不均衡。消费者可能只对某些broker中的leader副本进行大量pull操作，而忽略了其他broker中的leader副本。(4)leader副本切换不均匀。在实际应用中，可能会因为broker宕机导致主从副本切换，或者分区副本被重新分配。这些行为可能会导致每个broker中的leader副本分布不均。对此，我们可以采取一些预防措施。对于第一种情况，在创建topic时尽量让partition分布尽可能均衡。幸运的是，Kafka中相应的分发算法也在大力追求这个目标。如果是开发者自定义发行版，则需要关注这方面的内容。对于第二种和第三种情况，masterwrite和slaveread无法解决。对于第四种情况，Kafka提供了优先级副本的选举来实现领导副本的平衡。同时，还可以配合相应的监控、告警和运维平台，实现均衡优化。在实际应用中，Kafka通过一个集监控、告警、运维于一体的生态平台，在大多数情况下可以实现很大程度的负载均衡。一般来说，Kafka只支持master-write和master-read，有几个好处：可以简化代码的实现逻辑，减少出错的可能性；负载粒度细化，与主-写-从-读相比，不仅负载性能更好，而且用户可控；没有延迟的影响；当副本稳定时，不会出现数据不一致的情况。为此，Kafka为什么要实现对它没有任何好处的主写从读的功能呢？这一切都得益于卡夫卡出色的架构设计。从某种意义上说，主写从读是由于设计缺陷的权宜之计。
