为什么Kafka不支持读写分离

Java源码网 1月前 ⋅ 99 阅读

为什么Kafka不支持读写分离

在Kafka中,生产者写消息,消费者读消息,与leader副本交互,从而实现主写主读的生产和消费模型。数据库、复述等都主要写硕士读的功能,同时支持主要的读写功能,主要写和读是读写分离,为了符合主要写主要读,这里主要写读。Kafka不支持主写和读。这是为什么呢?

在代码级别上,尽管代码的复杂性增加了,但是Kafka完全支持这个特性。对于这个问题,我们可以从“返回点”的角度进行具体分析。主写从读允许从节点共享主节点的负载压力,防止主节点过载和从节点空闲。但是,主写和主读有两个非常明显的缺点:

数据一致性问题。从主节点到从节点的数据必须有一个延迟时间窗。这个时间窗口将导致主节点和从节点之间的数据不一致。在某些情况下,数据的价值在主节点和从节点是X,然后在主节点的值更改为Y,然后应用程序读取数据前的奴隶节点变化通知到奴隶节点。该值不是最新的Y,这会造成数据不一致的问题。

-(2)延迟问题。与Redis组件类似,从数据写入主节点到同步到从节点的过程需要网络→主内存→网络→从节点内存几个阶段,整个过程需要一定的时间。在Kafka中,主从同步比Redis更消耗时间。它需要经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘的阶段。对于时间敏感的应用程序,主写-读功能并不合适。

实际上,许多应用程序可以容忍一定程度的延迟,并且可以承受一段时间内数据不一致的情况。在这种情况下Kafka有必要支持主写和读功能吗?

主读/写可以共享一定的负载,但不能实现完全的负载均衡。例如,当数据写压力高而读压力小时,从节点只能共享较小的负载压力,大部分压力仍在主节点上。在Kafka中,可以实现大量的负载均衡,这种均衡是在主写主读的架构上实现的。让我们来看看Kafka的生产和消费模型,如下图所示.

image-20201216102759598.png

Kafka集群中有3个分区,每个分区有3个拷贝,平均分布在3个broker上,leader拷贝用灰色阴影表示,follower拷贝用非灰色阴影表示,从leader拷贝拉消息的follower拷贝用虚线表示。当生产者写入消息时,leader副本也被写入。对于图8-23中的情况,每个broker都有一个从生产者流出的消息;当消费者读取消息时,它也从leader副本中读取。对于图8-23中的情况,每个代理都有一条消息给消费者。

很明显,每个broker上的读和写负载是相同的,这意味着Kafka可以实现主写不能通过读主写主读实现的负载平衡。上面的关系图显示了一个理想的部署场景。有几种情况(包括但不限于)会导致一定程度的负载不平衡:

  • (1) broker端的分区分配是不均匀的。在创建主题时,可能会出现一些代理分配更多的分区,而其他代理分配更少的分区的情况,因此自然分配的leader副本不是统一的。

  • (2)生产者写信息不均匀。在一些代理中,生产者只能对leader副本执行大量的写操作,而在其他代理中,生产者不能执行leader副本。

  • (3)消费者消费新闻参差不齐。消费者可能只在一些代理中对leader副本执行大量拉取操作,但在其他代理中不会对leader副本执行大量拉取操作。

  • (4) leader副本的切换不均匀。在实际应用程序中,由于代理停机,主-从副本可能会切换,或者分区副本可能会被重新分发。这些操作可能会导致leader副本在每个broker中的分布不均匀。

对此,我们可以采取一些预防措施。对于第一种情况,创建主题时应该尽可能均匀地分配分区。幸运的是,Kafka中相应的分配算法也在追求这个目标。如果它是开发人员定义的分配,您需要注意这方面。内容。对于第二种和第三种情况,无法解决从读到主写的问题。在第四种情况下,Kafka提供了一个优先级的拷贝选择来实现leader拷贝的平衡,同时,它也可以配合相应的监控、报警和运维平台来实现平衡优化。

在实际应用中,Kafka通过一个集监控、报警、运维于一体的生态平台,在大多数情况下可以实现很大程度的负载均衡。一般来说,Kafka只支持主写主读有几个优点:它可以简化代码的实现逻辑,减少出错的可能性;负载粒度分布均匀,与主写主读相比,不仅负载性能更好,而且对用户可控;不存在延迟效应;在稳定复制的情况下,将不会出现数据不一致。为此,为什么卡夫卡要实现阅读和对它无益的阅读的功能呢?这一切都要归功于卡夫卡出色的建筑设计。从某种意义上说,写作主要是为了阅读。设计缺陷形成的权宜之计。


全部评论: 0

    我有话说: