中国500强公司有哪些,网络优化工程师是干什么的,郑州网络营销公司,七牛云wordpress图床转载自 阿里面试#xff0c;为什么Kafka不支持读写分离
为什么数据库、redis都支持了读写分离功能#xff0c;而kafka却没有#xff1f;
厮大也是狠人#xff0c;直接打开源码从头开始讲#xff0c;我一看这情况不对#xff0c;按照这进度得讲到天黑了#xff0c;蹭着…转载自 阿里面试为什么Kafka不支持读写分离
为什么数据库、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 副本对于图 8-23 中的 情形每个 broker 都有消息从生产者流入;当消费者读取消息的时候也是从 leader 副本中读取 的对于图 8-23 中的情形每个 broker 都有消息流出到消费者。
我们很明显地可以看出每个 broker 上的读写负载都是一样的这就说明 Kafka 可以通过 主写主读实现主写从读实现不了的负载均衡。上图展示是一种理想的部署情况有以下几种 情况(包含但不仅限于)会造成一定程度上的负载不均衡: broker 端的分区分配不均。当创建主题的时候可能会出现某些 broker 分配到的分区数 多而其他 broker 分配到的分区数少那么自然而然地分配到的 leader 副本也就不均。 生产者写入消息不均。生产者可能只对某些 broker 中的 leader 副本进行大量的写入操 作而对其他 broker 中的 leader 副本不闻不问。 消费者消费消息不均。消费者可能只对某些 broker 中的 leader 副本进行大量的拉取操 作而对其他 broker 中的 leader 副本不闻不问。 leader 副本的切换不均。在实际应用中可能会由于 broker 宕机而造成主从副本的切换 或者分区副本的重分配等这些动作都有可能造成各个 broker 中 leader 副本的分配不均。
对此我们可以做一些防范措施。针对第一种情况在主题创建的时候尽可能使分区分配 得均衡好在 Kafka 中相应的分配算法也是在极力地追求这一目标如果是开发人员自定义的 分配则需要注意这方面的内容。对于第二和第三种情况主写从读也无法解决。对于第四种 情况Kafka 提供了优先副本的选举来达到 leader 副本的均衡与此同时也可以配合相应的 监控、告警和运维平台来实现均衡的优化。
所以从某种意义上来说主写从读是由于设计上的缺陷而形成的权宜之计。
