Kafka竟然不支持读写疏散！本日才知道！
|
在 Kafka 中，出产者写入动静、斲丧者读打动静的操纵都是与 leader 副本举办交互的，从 而实现的是一种主写主读的出产斲丧模子。数据库、Redis 等都具备主写主读的成果，与此同时还支持主写从读的成果，主写从读也就是读写疏散，为了与主写主读对应，这里就以主写从读来称号! Kafka 并不支持主写从读，这是为什么呢? 从代码层面上来说，固然增进了代码伟大度，但在 Kafka 中这种成果完全可以支持。对付 这个题目，我们可以从“收益点”这个角度来做详细说明。主写从读可以让从节点去分管主节 点的负载压力，提防主节点负载过重而从节点却空闲的环境产生。可是主写从读也有 2 个很明明的弱点:
实际环境下，许多应用既可以忍受必然水平上的延时，也可以忍受一段时刻内的数据纷歧致的环境! 那么对付这种环境，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 优越的架构计划，从某种意义上来说，主写从读是因为计划上的缺陷而形成的权宜之计。 【责任编辑：庞桂玉 TEL：（010）68476606】点赞 0 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
