精华内容
下载资源
问答
  • 做broker需要什么
    万次阅读
    2018-06-13 15:40:22

    Broker是ActiveMQ的一个实例。

    我们可以将ActiveMQ看成一个服务,是需要我们下载解压后才能使用(免安装)。

    主要使用目的是为了将服务器和客户端解耦,用来做消息的传递。

    而Broker是ActiveMQ的一个简易实现,我们只需要在代码中启动Broker(用跑代码的方式启动ActiveMQ),从而实现嵌入式的ACtiveMQ。使用过程如下:

    (1) 运行Broker启动程序

    (2) 运行 sender(发送者) 代码,发送mq

    (3) 运行consume(消费者) 代码,接收mq

    其中broker的启动方式有两种:

    1. Broker Service启动 Broker, 例子如下:

      BrokerService broker = new BrokerService();

      broker.setUseJma(true);

      broker.addConnector("tcp://localhost:61616");

    broker.start();

    2. BrokerFactory方式启动 Broker,例子如下:

    String uri = "properties:broker.properties";

    BrokerService broker = BrokerFactory.createBroker(new URI(uri));

    broker.addConnector("tcp://localhost:61616");

    broker.start();

    其中,broker.properties 的内容如下所示:

    useJmx=true

    persistent=false

    brokerName=Cheese

    说白了,Broker其实就是实现了用代码的形式启动ActiveMq,将mq嵌入到java代码中,随时用随时启动,在用的时候再去启动。节省了资源,也保证了可靠性。

    更多相关内容
  • 如果使用 1024 以下的端口,Linux 需要使用 root 权限启动才能启动 kafka。 zookeeper.connect:保存 broker 元数据的 zookeeper 地址。该配置参数是用冒号分隔的一组 hostname:/port/path(path 是可选的 zookeeper ...
  • Ara_Broker_XP Ara_Broker_XP WoW插件的延续
  • RuntimeBroker什么进程,能禁用RuntimeBroker.exe进程么?今天看到网上有两位朋友因为这个进程,打起了口水仗,都是为别人好,这又何必呢?不过RuntimeBroker.exe进程确实有点特殊,如果我们打开Win8或者Win8.1系统,...

    RuntimeBroker是什么进程,能禁用RuntimeBroker.exe进程么?今天看到网上有两位朋友因为这个进程,打起了口水仗,都是为别人好,这又何必呢?不过RuntimeBroker.exe进程确实有点特殊,如果我们打开Win8或者Win8.1系统,偶尔会发现这个进程,可能由于误操作,这个进程会占用很多内存,一起部分朋友的惊慌,下面我们力图详细的为朋友解释下这个进程,希望能解决您的疑惑!

    一、RuntimeBroker是什么进程

    RuntimeBroker.exe进程Win8或者Win8.1系统中才会出现的进程,是一个重要的系统核心进程,是Win8或者Win8.1用来进行Metro App权限管理的一个进程。该程序正常情况下位于C:\Windows\System32目录下,大小一般为32.7KB。

    RuntimeBroker.exe进程,用来进行开始屏幕磁贴与桌面的后台交互,如果没有运行任何磁贴程序应用的话,可能不会出现的进程中。一般占用内存不会超过3M,如果系统出现该进程内存占用太高,应该是此贴应用没有彻底关闭(特别是Win8.1)。

    二、能禁用RuntimeBroker.exe进程么

    这么重要的进程,当然是不能随便禁用的啦!

    RuntimeBroker是什么进程,能禁用RuntimeBroker.exe进程么的内容,希望对您有所帮助!

    展开全文
  • rocketmq_broker.conf

    2020-12-04 14:34:50
    RocketMQ 配置文件:(下面是默认配置) brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 0 deleteWhen = 04 fileReservedTime = 48 brokerRole = ASYNC_MASTER flushDiskType = ASYNC_FLUSH
  • Ara_Broker_Reputations Ara_Broker_Reputations WoW插件的续集
  • Kafka的Controller Broker什么

    千次阅读 2020-07-09 09:39:55
    控制器组件(Controller),是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。...什么是Controller Broker Controller Broker是怎么被选举的 Controller Brok

    控制器组件(Controller),是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一台 Broker 都能充当控制器的角色,但是,在运行过程中,只能有一个 Broker 成为控制器,行使其管理和协调的职责。接下来,我们将讨论Controller原理和内部运行机制。通过本文你可以了解到:

    • 什么是Controller Broker
    • Controller Broker是怎么被选举的
    • Controller Broker主要作用是什么
    • Kafka是如何处理脑裂的
      在这里插入图片描述

    什么是Controller Broker

    在分布式系统中,通常需要有一个协调者,该协调者会在分布式系统发生异常时发挥特殊的作用。在Kafka中该协调者称之为控制器(Controller),其实该控制器并没有什么特殊之处,它本身也是一个普通的Broker,只不过需要负责一些额外的工作(追踪集群中的其他Broker,并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)。值得注意的是:Kafka集群中始终只有一个Controller Broker。

    Controller Broker是如何被选出来的

    上一小节解释了什么是Controller Broker,并且每台 Broker 都有充当控制器的可能性。那么,控制器是如何被选出来的呢?当集群启动后,Kafka 怎么确认控制器位于哪台 Broker 呢?

    实际上,Broker 在启动时,会尝试去 ZooKeeper 中创建 /controller 节点。Kafka 当前选举控制器的规则是:第一个成功创建 /controller 节点的 Broker 会被指定为控制器

    Controller Broker的具体作用是什么

    Controller Broker的主要职责有很多,主要是一些管理行为,主要包括以下几个方面:

    • 创建、删除主题,增加分区并分配leader分区
    • 集群Broker管理(新增 Broker、Broker 主动关闭、Broker 故障)
    • preferred leader选举
    • 分区重分配

    处理集群中下线的Broker

    当某个Broker节点由于故障离开Kafka群集时,则存在于该Broker的leader分区将不可用(由于客户端仅对leader分区进行读写操作)。为了最大程度地减少停机时间,需要快速找到替代的leader分区。

    Controller Broker可以对失败的Broker做出响应,Controller Broker可以从Zookeeper监听(zookeeper watch)中获取通知信息,ZooKeeper 赋予客户端监控 znode 变更的能力,即所谓的 Watch 通知功能。一旦 znode 节点被创建、删除,子节点数量发生变化,抑或是 znode 所存的数据本身变更,ZooKeeper 会通过节点变更监听器 (ChangeHandler) 的方式显式通知客户端。

    每个 Broker 启动后,会在zookeeper的 /Brokers/ids 下创建一个临时 znode。当 Broker 宕机或主动关闭后,该 Broker 与 ZooKeeper 的会话结束,这个 znode 会被自动删除。同理,ZooKeeper 的 Watch 机制将这一变更推送给控制器,这样控制器就能知道有 Broker 关闭或宕机了,从而进行后续的协调操作。

    Controller将收到通知并对此采取行动,决定哪些Broker上的分区成为leader分区,然后,它会通知每个相关的Broker,要么将Broker上的主题分区变成leader,要么通过LeaderAndIsr请求从新的leader分区中复制数据。

    处理新加入到集群中的Broker

    通过将Leader分区副本均匀地分布在集群的不同Broker上,可以保障集群的负载均衡。在Broker发生故障时,某些Broker上的分区副本会被选举为leader,会造成一个Broker上存在多个leader分区副本的情况,由于客户端只与leader分区副本交互,所以这会给Broker增加额外的负担,并损害集群的性能和运行状况。因此,尽快恢复平衡对集群的健康运行是有益的。

    Kafka认为leader分区副本最初的分配(每个节点都处于活跃状态)是均衡的。这些被最初选中的分区副本就是所谓的首选领导者(preferred leaders)。由于Kafka还支持机架感知的leader选举(rack-aware leader election) ,即尝试将leader分区和follower分区放置在不同的机架上,以增加对机架故障的容错能力。因此,leader分区副本的存在位置会对集群的可靠性产生影响。

    默认情况下auto.leader.rebalance.enabled为true,表示允许 Kafka 定期地对一些 Topic 分区进行
    Leader 重选举。大部分情况下,Broker的失败很短暂,这意味着Broker通常会在短时间内恢复。所以当节点离开群集时,与其相关联的元数据并不会被立即删除。

    当Controller注意到Broker已加入集群时,它将使用Broker ID来检查该Broker上是否存在分区,如果存在,则Controller通知新加入的Broker和现有的Broker,新的Broker上面的follower分区再次开始复制现有leader分区的消息。为了保证负载均衡,Controller会将新加入的Broker上的follower分区选举为leader分区。

    注意:上面提到的选Leader分区,严格意义上是换Leader分区,为了达到负载均衡,可能会造成原来正常的Leader分区被强行变为follower分区。换一次 Leader 代价是很高的,原本向 Leader分区A(原Leader分区) 发送请求的所有客户端都要切换成向 B (新的Leader分区)发送请求,建议你在生产环境中把这个参数设置成 false。

    同步副本(in-sync replica ,ISR)列表

    ISR中的副本都是与Leader进行同步的副本,所以不在该列表的follower会被认为与Leader是不同步的. 那么,ISR中存在是什么副本呢?首先可以明确的是:Leader副本总是存在于ISR中。 而follower副本是否在ISR中,取决于该follower副本是否与Leader副本保持了“同步”。

    始终保证拥有足够数量的同步副本是非常重要的。要将follower提升为Leader,它必须存在于同步副本列表中。每个分区都有一个同步副本列表,该列表由Leader分区和Controller进行更新。

    选择一个同步副本列表中的分区作为leader 分区的过程称为clean leader election。注意,这里要与在非同步副本中选一个分区作为leader分区的过程区分开,在非同步副本中选一个分区作为leader的过程称之为unclean leader election。由于ISR是动态调整的,所以会存在ISR列表为空的情况,通常来说,非同步副本落后 Leader 太多,因此,如果选择这些副本作为新 Leader,就可能出现数据的丢失。毕竟,这些副本中保存的消息远远落后于老 Leader 中的消息。在 Kafka 中,选举这种副本的过程可以通过Broker 端参数 **unclean.leader.election.enable **控制是否允许 Unclean 领导者选举。开启 Unclean 领导者选举可能会造成数据丢失,但好处是,它使得分区 Leader 副本一直存在,不至于停止对外提供服务,因此提升了高可用性。反之,禁止 Unclean Leader 选举的好处在于维护了数据的一致性,避免了消息丢失,但牺牲了高可用性。分布式系统的CAP理论说的就是这种情况。

    不幸的是,unclean leader election的选举过程仍可能会造成数据的不一致,因为同步副本并不是完全同步的。由于复制是异步完成的,因此无法保证follower可以获取最新消息。比如Leader分区的最后一条消息的offset是100,此时副本的offset可能不是100,这受到两个参数的影响:

    • replica.lag.time.max.ms:同步副本滞后与leader副本的时间
    • zookeeper.session.timeout.ms:与zookeeper会话超时时间

    脑裂

    如果controller Broker 挂掉了,Kafka集群必须找到可以替代的controller,集群将不能正常运转。这里面存在一个问题,很难确定Broker是挂掉了,还是仅仅只是短暂性的故障。但是,集群为了正常运转,必须选出新的controller。如果之前被取代的controller又正常了,他并不知道自己已经被取代了,那么此时集群中会出现两台controller。

    其实这种情况是很容易发生。比如,某个controller由于GC而被认为已经挂掉,并选择了一个新的controller。在GC的情况下,在最初的controller眼中,并没有改变任何东西,该Broker甚至不知道它已经暂停了。因此,它将继续充当当前controller,这是分布式系统中的常见情况,称为脑裂。
    在这里插入图片描述

    假如,处于活跃状态的controller进入了长时间的GC暂停。它的ZooKeeper会话过期了,之前注册的/controller节点被删除。集群中其他Broker会收到zookeeper的这一通知。

    在这里插入图片描述

    由于集群中必须存在一个controller Broker,所以现在每个Broker都试图尝试成为新的controller。假设Broker 2速度比较快,成为了最新的controller Broker。此时,每个Broker会收到Broker2成为新的controller的通知,由于Broker3正在进行"stop the world"的GC,可能不会收到Broker2成为最新的controller的通知。

    在这里插入图片描述
    等到Broker3的GC完成之后,仍会认为自己是集群的controller,在Broker3的眼中好像什么都没有发生一样。

    在这里插入图片描述

    现在,集群中出现了两个controller,它们可能一起发出具有冲突的命令,就会出现脑裂的现象。如果对这种情况不加以处理,可能会导致严重的不一致。所以需要一种方法来区分谁是集群当前最新的Controller。

    Kafka是通过使用epoch number(纪元编号,也称为隔离令牌)来完成的。epoch number只是单调递增的数字,第一次选出Controller时,epoch number值为1,如果再次选出新的Controller,则epoch number将为2,依次单调递增。

    每个新选出的controller通过Zookeeper 的条件递增操作获得一个全新的、数值更大的epoch number 。其他Broker 在知道当前epoch number 后,如果收到由controller发出的包含较旧(较小)epoch number的消息,就会忽略它们,即Broker根据最大的epoch number来区分当前最新的controller。
    在这里插入图片描述

    上图,Broker3向Broker1发出命令:让Broker1上的某个分区副本成为leader,该消息的epoch number值为1。于此同时,Broker2也向Broker1发送了相同的命令,不同的是,该消息的epoch number值为2,此时Broker1只听从Broker2的命令(由于其epoch number较大),会忽略Broker3的命令,从而避免脑裂的发生。

    总结

    本文主要讲解了什么是Kafka Controller,它其实就是一个普通的Broker,除了需要负责一些额外的工作之外,其角色与其他的Broker基本一样。另外还介绍了Kafka Controller的主要职责,并对其中的一些职责进行了详细解释,最后还说明了kafka是如何避免脑裂的。

    展开全文
  • 主要介绍了kafka调试中遇到Connection to node -1 could not be established. Broker may not be available的解决方法,小编觉得挺不错的,现在分享给大家,也给大家个参考。一起跟随小编过来看看吧
  • kafka之broker

    千次阅读 2021-03-22 18:17:37
    不同broker之间的关系 Kafka使用zookeeper来维护集群成员的信息。每个broker都有一个唯一标识符,这个标识符可以在配置文件中指定,也可以自动生成。在broker启动时,它通过建立临时节点把自己的ID注册到zookeeper。...

    不同broker之间的关系

    Kafka使用zookeeper来维护集群成员的信息。每个broker都有一个唯一标识符,这个标识符可以在配置文件中指定,也可以自动生成。在broker启动时,它通过建立临时节点把自己的ID注册到zookeeper。kafka组件订阅broker在zookeeper上的注册路径,当有broker进入或退出集群时,这些组件就可以获得通知

    在broker停机、出现网络分区或长时间垃圾回收停顿时,broker会从zookeeper上断开连接,此时broker的临时节点会自动从zookeeper上移除。监听broker列表的kafka组件会被告知该broker已移除。

    在关闭broker时,它对应的节点也会消失,不过它的ID会继续存在于其他数据结构中。例如,主题的副本列表里就可能包含这些ID。在完全关闭一个broker之后,如果使用相同的ID启动另一个全新的broker,它会立即加入集群,并拥有与旧broker相同的分区和主题。

    控制器

    控制器其实也是一个broker,只不过它除了具有一般broker的功能之外,还负责分区首领的选举集群里第一个启动的broker通过在zookeeper里创建一个临时节点让自己成为控制器。其他的broker在控制器节点上创建zookeeper watch对象,这样它们就可以收到这个节点的变更通知。

    如果控制器被关闭或者与zookeeper断开连接,zookeeper上的临时节点就会消失。集群里的其他broker通过watch对象得到控制器节点消失的通知,它们尝试让自己成为新的控制器。第一个在zookeeper里成功创建控制器节点的broker成为新的控制器,其他的broker会在新的控制器节点上创建新的watch对象。每个新选出的控制器通过zookeeper的条件递增操作获得一个全新的数值更大的controller epoch。同时,控制器使用epoch来避免“脑裂”。脑裂是指两个节点同时认为自己是当前的控制器。

    当控制器发现一个broker已经离开集群(通过观察相关的zookeeper路径),它就知道,那些失去首领的分区需要一个新首领(这些分区的首领刚好是在这个broker上)。控制器遍历这些分区,并确定谁应该成为新首领,然后向所有包含新首领或者现有跟随者的broker发送请求。该请求中包含了谁是新首领以及谁是分区跟随者的信息。

    当控制器发现一个broker加入集群时,它会使用brokerID来检查新加入的broker是否包含现在分区的副本。如果有,控制器就把变更通知发送给新加入的broker和其他broker,新broker上的副本开始从首领那里复制消息。

    复制

    kafka使用主题来组织数据,每个主题被分为如干个分区,每个分区有多个副本。那些副本被保存在broker上,每个broker可以保存成百上千个属于不同主题和分区的副本。

    副本类型

    • 首领副本
      每个分区都有一个首领副本。为了保证一致性,所有生产者和消费者请求都会经过这个首领副本
    • 跟随者副本
      首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求,它们唯一的任务就是从首领那里复制消息,保持与首领一致的状态。如果首领发生崩溃,其中一个跟随者会被提升为新首领,选举新首领是由控制器broker来完成的。

    首领的另一个任务是搞清楚哪个跟随者的状态和自己是一致的。为了与首领保持一致,跟随者向首领发送获取数据的请求,这种请求和消费者为了读取消息而发送的请求是一样的。首领将响应消息发送给跟随者。请求消息里包含了跟随者想要获取消息的偏移量,而且这些偏移量总是有序的。例如,一个跟随者副本先请求消息1,再请求消息2,然后请求消息3,在收到这三个请求的响应前,它是不会发送第4个请求消息的。如果跟随者发送了第4个消息,首领就知道它已经收到了前三个响应。通过查看每个跟随者的请求的最新偏移量,首领就会知道每个跟随者的复制进度。

    从复制的角度,副本又可以分为同步副本非同步副本

    同步副本需要满足的条件

    分区首领是同步副本,但对于跟随者副本来说是否是同步副本,需要满足下面三个条件:

    • 与zookeeper之间有一个活跃的会话,也就是说,它在过去的6s(可配置)内向zookeeper发送过心跳。
    • 在过去10s内(可配置replica.lag.time.max.ms)从首领那里获取过最新消息。光从首领那里获取消息是不够的,它还必须是几乎零延迟的。

    如果跟随者副本不能满足以上任何一点,那么它就会被认为是不同步副本。跟随者的正常不活跃时间或者称为不同步副本之前的时间是通过replica.lag.time.max.ms参数来设置的。这个时间间隔直接影响着首领选举期间的客户端行为和数据保留机制。一个不同步副本通过和zookeeper重新建立连接,并从首领那里获取最新消息,可以重新变成同步的。但是重新变成同步的过程在网络出现临时问题并很快得到修复的情况下会很快完成,但如果broker

    一个滞后的同步副本会导致生产者和消费者变慢,因为在消息被认为已提交之前,客户端会等待所有的同步副本接收到消息。而如果一个副本不同步了,我们就不再关心它是否已经收到消息。虽然非同步副本同样滞后,但是它不会对性能产生任何影响。但是,更少的同步副本意味着更低的有效复制系数,在发生宕机时丢失数据的风险更大。当然是否需要所有同步副本接收到消息才算提交,是可以通过生产者acks配置的,当然这个参数的配置需要我们在性能和一致性之间做出选择。

    我们知道一般在首领失效时,只有同步副本才有可能被选为最新首领副本。不同步副本是不能被选举为首领的,毕竟它没有包含全部消息。但是,如果我们将参数unclean.leader.election.enable设为true,就是允许不同步副本成为首领(也就是不完全的选举)。一般我们不提倡开启不完全选举,但是对于一些可用性要求比较高,比如实时点击流分析系统,一般会启用不完全的首领选举。

    根据kafka对可靠性数据保证的定义,消息只有在被写入到所有的同步副本之后才被认为是已提交的。但如果这里的“所有同步副本”只包含一个,那么在这个副本变为不可用的时,数据就会丢失。这时我们最好确保数据被写入不止一个副本,这就是需要把最小同步副本数量设置的大些。这样能保证在首领失效时,有其他的同步副本能被选为首领,但是如果同步副本数量小于我们设置的最小同步副本,那么broker就会停止接受生产者的请求。最小同步副本是通过min.insync.replicas设置的,在主题级别和broker级别都有这个参数,根据需要去设置。

    除了当前首领外,每个分区都有一个首选首领(分区的副本清单中第一个副本一般就是首选首领)—创建主题时选定的首领就是分区的首选首领。之所以把它叫做首选首领,是因为在创建分区时,需要在broker之间均衡首领。因此,我们希望首选首领成为真正的首领。默认情况下,auto.leader.rebalance.enable为true,它会检查首选首领是不是当前首领,如果不是,并且该副本是同步副本的,就会触发首领选举,让首选首领成为当前首领。

    broker处理请求

    kafka提供一个二进制协议,制定了请求消息的格式以及broker如何对请求作出响应。客户端发起连接和发送请求,broker按照请求到达的顺序来处理他们,这种顺序保证了kafka具有消息队列的特性,同时保证保存的消息也是有序的。

    那么broker是如何处理请求的呢?
    答:broker会在它所监听的每个端口上运行一个Acceptor线程,这个线程会创建一个连接,并把它交给Processor线程去处理。Processor线程(网络线程)的数量是可配置的。网络线程负责从客户端获取请求消息,把它们放进请求队列,请求消息放入请求队列后,IO线程会处理它们,并将处理结果放入响应队列,然后网络线程从响应队列中获取响应消息,把它们发送给客户端。

    生产请求和获取请求都必须发送给分区的首领副本。如果broker收到一个针对特定分区的请求,而该分区的首领在另一个broker上,那么发送请求的客户端会收到一个“非分区首领”的错误响应。同样获取请求时也会有同样的要求。kafka客户端要自己负责把生产请求和获取请求发送给正确的broker上。

    那么客户端怎么知道该往哪里发送请求呢?
    答:客户端使用了另一种请求类型,也就是元数据请求。这些请求中包含了客户端感兴趣的主题列表,以及这些主题包含的分区,每个分区都有哪些副本,以及哪个副本是首领。元数据请求可以发送给任何一个broker,因为所有broker都缓存了这些消息。
    一般情况下,客户端会把这些信息缓存起来,并直接往目标broker上发送生产请求和获取请求。客户端需要时不时地通过发送元数据请求来刷新这些信息(刷新频率可以通过metadata.max.age.ms配置)。如果客户端收到“非首领”错误,客户端在尝试重发请求之前先刷新元数据,因为这个错误说明了客户端正在使用过期的元数据信息。

    客户端从broker上获取消息时,客户端可以指定broker最多可以从一个分区里返回多少数据。这个限制非常重要的,因为客户端需要为broker返回的数据分配足够的内存。如果请求的偏移量存在,broker将按照客户端指定的数据上限从分区里返回读取消息,再把消息返回给客户端。kafka使用零复制技术向客户端发送消息—kafka直接把消息从文件里发送到网络通道,而不需要经过任何的缓冲区。客户端除了可以设置broker返回数据的上限,还可以设置下限。

    分区分配

    kafka的基本存储单元就是分区。分区无法在多个broker间进行再细分,也无法在同一个broker的多个磁盘上进行细分。
    对于分区分配的理解,我们可以用一个实际场景来解释。例如,假设我们有6个broker,打算创建一个包含10个分区的主题,复制系数3,那么kafka就会有30个分区副本。在进行分区分配时,我们要达到如下的目标:

    • 在broker间均匀地分布分区副本。
    • 确保每个分区的每个副本分布在不同的broker上。
    • 如果为broker制定了机架信息,那么尽可能把每个分区的副本分配到不同的机架的broker上。

    为了实现这个目标,我们先随机选择一个broker(假设是4),然后使用轮询的方式给每个broker分配首领。于是,首领分区0会在broker4上,首领分区1在broker5上,首领分区2在broker0上,以此类推。然后从分区首领开始,依次分配其跟随者副本。如果分区0的首领在broker4上,那么它的第一个跟随者在broker5上,第二个跟随者副本在broke0上。其他的分区也是同样的道理。

    broker中可靠性保证

    复制系数

    主体级别的配置参数是replication.factor,而在broker级别则可以通过default.replication.factor来配置自动创建的主题。
    复制系数N就需要至少N个broker,而且会有N个数据副本。也就是说复制系数其实也就决定这分区的副本个数。那么在N-1个broker失效的情况下,仍然能够从主体读取数据或向主体写入数据。
    例如我们假设主题的复制系数为3,也就是说每个分区总共会被3个不同的broker复制三次。不过用户可以修改它。即使是在主题创建之后,也可以通过新增或者移除副本来改变复制系数。
    从上面的描述可以看出更高的复制系数意味着更高的可用性、可靠性,但同时也意味着要付出更多磁盘空间,这就需要我们在可用性和存储空间之间做出权衡。那复制系数设置多少合适呢?遗憾的是这个没有统一的标准,要根据主题的重要层度来定。如果复制系数为1,那就意味着如果这个分区的副本所在的broker宕机时,这个分区就会立马不可用;如果复制系数为2可以容忍一个broker发生失效,看起来是足够了,但是有时候1个broker是学校会导致集群不稳定,迫使你重启另一个broker(集群控制器)。也就是说复制系数为2时,有可能因为重启等问题导致集群不可用,所以一般推荐设置为3,这也是kafka默认的设置
    另外,出于高可用的考虑,kafka默认会确保分区的每个副本被放在不同的broker上。但是为了更安全的考虑,我们最好将不同broker放到不同的机架上,这样防止一个机架发生故障导致所有的broker全军覆没。

    不完全首领选举

    允许不同步副本成为首领就是不完全的选举。现实业务中可能会出现首领不可用的同时其他的副本又都是不同步的,这时如果我们不允许不完全的选举,那么就要接收较低的可用性,因为分区在旧首领(最后一个同步副本)恢复之前是不可用的,有时候这种状态会持续数小时;但是如果我们允许不完全的选举就会承担丢失数据和数据不一致的风险。所以是否允许不完全的选举需要我们根据具体的业务场景来定,如果对可用性要求比较高,并且对消息丢失是可接受的,就可以允许不完全的选举。但是对于一些对数据质量和数据一致性要求比较高的系统会禁用这种不完全的首领选举。是否允许不完全选举是通过unclean.leader.election.enable参数来控制的,此参数只能在broker级别(实际上是在集群范围内)进行配置,默认值是true。
    但是需要注意的是如果不同步副本被选举为首领后,旧的首领重新变得可用,那么旧的首领会成为新首领的跟随者。这个时候,旧的首领会把比当前首领旧的消息全部删除,而这些消息的对于所有消费者来说都是不可用的。

    最小同步副本

    在主题级别和broker级别上,通过min.insync.replicas来设置。
    我们知道kafka对可靠性的保证的定义,消息只有在被写入到所有的同步副本之后才被认为是已提交的
    为了数据的可靠性,我们需要把上述参数设置为大于1,这样就可以保证已被提交的消息在超过一个副本上。例如,如果我们把这个参数设置为2,某个分区的同步副本数只要不小于2,那么这个分区就可以正常的工作,但是如果同步副本数小于2,那么broker就会停止接收生产者的消息。尝试发送消息的生产这会收到NotEnoughReplicasException异常。**消费者仍然可以继续读取已有的数据。其实这时当只剩下一个同步副本时,它就变成只读了,这是为了避免在发生不完全选举时数据的写入和读取出现非预期的行为。要想从只读状态中恢复,必须让之前其他不同步的副本变得同步才可以。

    展开全文
  • activemqBroker插件:activemqBroker-2.14-SNAPSHOT.war
  • 许多网友询问小编win10系统中的RuntimeBroker.exe进程是什么?有什么作用?而且发现Runtime Broker占用内存很高,有什么办法可以禁止?其实Runtime Broker进程非常特殊的,以下小编向我们详解详细内容,告诉我们win10...
  • webMethods Broker is the primary component in what is referred to as the “message backbone” in a webMethods integration environment. Along with other webMethods components, webMethods Broker ...
  • 如果需要开启主从切换,则该值需要设置为 true if (messageStoreConfig.isEnableDLegerCommitLog()) { brokerConfig.setBrokerId(-1); } //设置消息存储配置的高可用端口,10912 messageStoreConfig.setHaListenPort...
  • Kafka知识总结之Broker原理总结

    千次阅读 2022-03-18 19:31:30
    这篇文章介绍Kafka的Broker工作流程,包括其中控制器的选举过程;kafka副本的leader选举以及leader和follower故障流程;简单讲述了生产环境中如何调整分区副本;kafka的文件存储机制以及日志文件的删除策略;最后...
  • 在win10系统中,有着许多用户所不了解的重要进程,其中就包括Runtimebroker.exe,这是win10系统中的核心进程,用于执行Metro App权限管理的过程,可是有的用户发现自己的win10系统中Runtimebroker.exe进程总是占用了...
  • MQTT协议之broker

    千次阅读 2017-12-07 19:32:56
    两个App端发送和接收消息需要中间人,这个中间人就是消息服务器(比如ActiveMQ/RabbitMQ),三者通信协议就是MQTT。 Mosquitto 、Webspare、ActiveMQ/RabbitMQ这些代理支持该协议,kafka不支持该协议
  • 3.kafka中的broker 是干什么broker 是消息的代理,Producers往Brokers里面的指定Topic中写消息,Consumers从Brokers里面拉取指定Topic的消息,然后进行业务处理,broker在中间起到一个代理保存消息的中转站。 4...
  • RocketMQ-broker启动流程详解

    千次阅读 2020-12-06 20:23:06
    本文将从整体上分析broker如何启动。 文章目录一、broker启动1、createBrokerController()2、start() 一、broker启动 broker的启动类是BrokerStartup,其main方法如下: public static void main(String[] args) { ...
  • RocketMQ角色详解之Broker

    千次阅读 2019-01-30 17:39:57
    一、Broker概述 Broker是 RocketMQ 的核心,大部分‘重量级”工作都是由 Broker完成的。 包括接收 Producer 发过来的消息、处理 Consumer 的消费消息请求、消息的持 久化存储、消息的 HA 机制以及服务端过滤功能等 ...
  • brokerIP2 存在broker主从时,在broker主节点上配置了brokerIP2的话,broker从节点会连接主节点配置的brokerIP2来同步。 默认不配置brokerIP1和brokerIP2时,都会根据当前网卡选择一个IP使用,当你的机器有多块网卡...
  • Broker for J2ME-开源

    2021-04-27 05:51:49
    Broker for J2ME是基于J2ME的流行棋盘游戏Broker的实现。
  • RocketMQ 简介 -- Broker

    万次阅读 2018-04-12 18:10:44
    RocketMQ Broker RocketMQ Broker 概述 处理Producer消息 处理Consumer消息 内部服务 概述 Broker即是物理上的概念,也是逻辑上的概念。多个物理Broker通过IP:PORT区分,多个逻辑Broker通过BrokerName...
  • Kafka 几个监控指标的含义 网上也有很多文章讲解这些个指标的含义,但总感觉还不够透彻。至少我是一知半解的。我查看了kafka eagle的源码,再举一些栗子来说明。...Broker Spread 引用 kafka-eagle几个指标含义 ...
  • Broker设计模式范例

    2014-06-26 17:10:14
    这是一个基于broker设计模式的小范例,希望能给大家带来帮助。
  • RocketMq源码分析-Broker

    千次阅读 2022-03-23 16:14:17
    Broker源码解析: 启动流程: BrokerStartup main(): start(BrokerController controller=createBrokerController(args)): createBrokerController: 1:是否指定了netty通信时缓冲区的大小,若未指定初始化为128K ...
  • broker指定ip

    千次阅读 2020-12-25 12:18:28
    默认不配置brokerIP1和brokerIP2时,都会根据当前网卡选择一个IP使用,当你的机器有多块网卡或者装了docker后,很有可能会有问题,有可能brokerIP就是docker的ip,在其他机器是ping不通的 broker.properties broker...
  • 三, Kafka Broker

    千次阅读 2022-04-15 22:20:44
    文章目录三, Kafka Broker3.1 Kafka Broker 工作流程1. Zookeeper 中存储的Kafka信息2. Kafka Broker 总体工作流程2.1 Broker 重要参数3. 生产经验--节点服役(新增Broker)和退役3.1 服役新节点3.2 退役旧结点4. ...
  • RocketMQ(四)Broker配置文件详解

    千次阅读 2022-03-20 08:22:47
    # broker所属集群的名称 brokerClusterName = DefaultCluster # broker的名称 brokerName = broker-a # broker的ID, 0表示Master,非0表示Slave brokerId = 0 # 删除文件时间点,默认是凌晨4点 deleteWhen = 04 # ...
  • celery中间件:broker

    千次阅读 2020-12-29 10:30:45
    celery中间件:broker Celery 支持多种消息传输的方式。 中间人(Broker)使用指南 使用 RabbitMQ 使用 Redis 使用 Amazon SQS 中间人(Broker)概况 这是不同的中间件比对情况,更多的...
  • Broker 设计模式 JAVA

    2013-05-28 20:37:04
    20101610111刘良建_Broker.zip,20101610111刘良建_Broker,Broker,src,com,llj,broker,Client.java,Main.java,Broker.java,Server.java,bin,com,llj,broker,Server.class,Client.class,Main.class,Main$2.class,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 174,097
精华内容 69,638
热门标签
关键字:

做broker需要什么

友情链接: Cpp880-960.rar