标签：nss redis 优先 展现 节点 red 架构 https 最新
在 Kafka 中，出产者写入音讯、顾客读取音讯的操作都是与 leader 副本进行交互的，从 而结束的是一种主写主读的出产消费模型。数据库、Redis 等都具有主写主读的功用，与此同时还支撑主写从读的功用，主写从读也便是读写分别，为了与主写主读对应，这儿就以主写从读来称谓。Kafka 并不支撑主写从读，这是为什么呢?
从代码层面上来说，虽然增加了代码复杂度，但在 Kafka 中这种功用完全能够支撑。关于 这个问题，咱们能够从“收益点”这个视点来做具体分析。主写从读能够让从节点去分管主节 点的负载压力，防范主节点负载过重而从节点却闲暇的状况发生。可是主写从读也有 2 个很明 显的缺陷:
(1)数据一致性问题。数据从主节点转到从节点必定会有一个延时的时间窗口，（waLsinsstube）这个时间 窗口会导致主从节点之间的数据纷歧致。某一时间，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个改动告知到从节点之前，运用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据纷歧致的问题。
(2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的进程需求经 历网络→主节点内存→网络→从节点内存这几个阶段，整个进程会耗费必定的时间。而在 Kafka 中，主从同步会比 Redis 愈加耗时，它需求阅历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时活络的运用而言，主写从读的功用并不太适用。
实践状况下，许多运用既能够忍受必定程度上的延时，也能够忍受一段时间内的数据纷歧 致的状况，那么关于这种状况，Kafka 是否有必要支撑主写从读的功用呢?
主写从读能够均摊必定的负载却不能做到完全的负载均衡，比方关于数据写压力很大而读 压力很小的状况，从节点只能分摊很少的负载压力，而绝大多数压力仍是在主节点上。而在 Kafka 中却能够抵达很大程度上的负载均衡，而且这种均衡是在主写主读的架构上结束的。咱们来看 一下 Kafka 的出产消费模型，如下图所示。
干货|为什么Kafka不支撑读写分别
在 Kafka 集群中有 3 个分区，每个分区有 3 个副本，正好均匀地散布在 3个 broker 上，灰色阴影的代表 leader 副本，非灰色阴影的代表 follower 副本，虚线表明 follower 副本从 leader 副本上拉取音讯。当出产者写入音讯的时分都写入 leader 副本，关于图 8-23 中的 现象，每个 broker 都有音讯从出产者流入;当顾客读取音讯的时分也是从 leader 副本中读取 的，关于图 8-23 中的现象，每个 broker 都有音讯流出到顾客。
咱们很明显地能够看出，每个 broker 上的读写负载都是相同的，这就说明 Kafka 能够通过 主写主读结束主写从读结束不了的负载均衡。（shikong-movies）上图展现是一种志向的组织状况，有以下几种 状况(包括但不只限于)会构成必定程度上的负载不均衡:
(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 优异的 架构规划，从某种意义上来说，主写从读是由于规划上的缺陷而构成的权宜之计。
标签：nss redis 优先 展现 节点 red 架构 https 最新
原文地址：https://www.cnblogs.com/monkey7788/p/11979931.html
