bao2901203013的专栏

RocketMQ中消息消费以消费组的模式开展，一个消费组内可以包含多个消费者，每一个消费者组可订阅多个主题，消费组内消费者之间有集群模式和广播模式两种消费模式。集群模式，主题下的同一条消息只允许被其中一个消费者消费。广播模式，主题下的同一条消息，将被集群内的所有消费者消费一次。消息服务器与消费者之间的消息传递也有两种模式：推模式、拉模式。所谓的拉模式即PullConsumer，是消费端主动拉起拉消息请求，而推模式即PushConsumer,是消息达到消息服务器后，推送给消息消费者。......

在步骤3中，会对topic进行检查，如果topic不存在，且设置成自动创建topic，就会在Broker上自动创建topic。第3步，最终回调的Callback类将数据写入buffer中，消息的序列化也是在callback里面完成的。putMessage会做一下检查，然后调用CommitLog的putMessage方法来写入消息。Broker最后调用MessageStore来存储数据。做接收和处理producer发送过来的消息。在RocketMQ中，Broker通过。...

在DefaultMQProducer的构造函数中，主要是创建了类DefaultMQProducerImpl的实例，通过类DefaultMQProducerImpl的实例来实现各种逻辑。Producer作为生产者是RocketMQ的重要组成部分，下面我们通过一个消息发送的例子来说明Producer的工作原理。1、首先创建一个DefaultMQProducer实例，然后设置NameSrv的地址，再启动实例。2、当需要发送消息时，创建消息实例，然后发送消息给Broker。2.选择要发送到的消息队列。...

RocketMQ中写入的消息会存储再commit文件下，然后再异步的转存到consumeQueue以及indexFile

RocketMQ作为一个消息队列需要一个高效的机制来存储消息，store模块就是RocketMQ的消息存储模块，下面介绍一下store中消息存储的核心流程。一、消息存储核心类DefaultMessageStore是消息存储的核心模块和入口，它的定义如下：public class DefaultMessageStore implements MessageStore { /** * 消息过滤器 */ private final MessageFilter

RocketMQ中Broker模块主要负责消息的存储、投递和查询以及服务高可用保证，它是RocketMQ中最为核心的模块，下面介绍一下它的启动流程。启动入口Broker是通过BrokerStartup的主函数启动的，代码如下：public static void main(String[] args) { start(createBrokerController(args));}先通过函数createBrokerController创建BrokerController对象，然后用st

remoting是RocketMQ的底层通信模块，RocketMQ底层通讯是使用Netty来实现的。

NameServer是RocketMQ的元数据管理模块，它负责整个RocketMQ集群的Broker和元数据管理。下面以NameServer的启动流程来说明NameServer的工作原理。一、启动入口NamesrvStartup 是的NameServer服务的启动类。 其入口是 main0( ) 方法。代码如下：public static NamesrvController main0(String[] args) { try { //创建NameSe

RocketMQ是阿里巴巴开源的一款高性能、高吞吐量、低延迟、高可用的分布式消息队列，通过对RocketMQ源码的学习可以知道一个出色的消息队列如何设计、如何运行。nameServerNameServer 是专为 RocketMQ 设计的轻量级元数据管理模块，相当与Kafka中的zookeeper，管理集群中的Broker和元数据，整个Rocketmq集群的工作原理如下图所示:可以看到，RocketMQ架构上主要分为四部分, Broker、Producer、Consumer、NameServ

Kafka的消费者consumer是通过遍历KafkaStream的迭代器ConsumerIterator来消费消息的，其数据来源是分配给给KafkaStream的阻塞消息队列BlockingQueue，而BlockingQueue中的消息数据来自于针对每个Broker Server的FetchThread线程。FetchThread线程会将Broker Server上的部分partition数据发送给对应的阻塞消息队列BlockingQueue。其具体流程如下：其中类kafka.consumer.

Kafka的Java客户端通过封封类kafka.producer.Producer来提供消息发送服务，所以消息发送的逻辑主要是在kafka.producer.Producer中完成。Producer的代码如下：class Producer[K,V](val config: ProducerConfig, private val eventHandler: EventHandler[K,V]) // only for unit testing extends

一、kafka-topic.sh为了便于操作Kafka集群，Kafka源码包中提供了多个shell脚本，其中kafka-topic.sh提供了Topic的创建、修改、列举、描述、删除功能，内部通过TopicCommand来实现。其脚本内容如下：//kafka-run-class.sh加载kafka的classpath，执行其中kafka.admin.TopicCommand的main函数exec $(dirname $0)/kafka-run-class.sh kafka.admin.Topic

作为Kafka的重要模块，KafkaController主要通过监听zookeeper节点的变化来感知集群中元数据的变化，KafkaController内置多个zookeeper监听函数，监听的对象包括：在线的Broker Server列表，Topic列表，Partition对应的AR列表，Partition对应的ISR列表等等

Kafka集群中，Topic的分区状态有PartitionStateMachine模块负责，通过在zookeeper上的目录/brokers/topics和/admin/delete_topics注册不同的监听函数，监听Topic的创建和删除事件，从而触发Topic的分区状态转换。

KafkaController模块的初始化是由ZookeeperLeaderElector决定的，当Broker Server被选为leader时，会触发调用onBecomingLeader回调函数，当

KafkaController是Kafka集群的控制管理模块，负责集群中Topic的创建、分区的重新分配以及分区副本Leader的重新选举等管理集群的功能。虽然每个Broker Server都有一个KafkaController模块，但是有且有一个处于leader状态的KafkaController模块对外提供管理服务。下面介绍一下KafkaController的选举策略。在kafka内部，所有的Broker Server都会启动一个KafkaController模块，但是只会有一个KafkaContr

KafkaApis模块是Kafka中负责不同业务请求的具体实现逻辑，本文主要讲一下KafkaApis处理FetchRequest请求的流程。当状态为Follower的Replica向状态为Leader的Replica同步数据或者消费者获取数据时，Replica会发送FetchRequest给Leader所在的Broker Server，Broker Server在接收到FetchRequest请求时，会返回相应的数据，同时还会根据情况更新对应的元数据。其详细的过程如下：def handleFetc

KafkaApis模块是Kafka中负责不同业务请求的具体实现逻辑，本文主要讲一下KafkaApis处理ProducerRequest请求的流程。

在Kafka内部有一个名为__consumer_offsets的topic，这个topic主要保存了每个消费组对topic下的partition消费的偏移量，即消费到了哪个offset。为了实现消费组offset管理的功能，当一个消费者获取到一条消息时，需要让消费者使用offset commit请求API来提交offsets。我们让brokers记录offset消息到磁盘上，并且使用消息的复制特征，达到持久性和可用性。所以实际上在broker端的offset提交处理和生产者请求的处理是一样的逻辑。在brok

当Broker Server被分配Replica的时候，该Replica有可能成为Leader状态的Replica或者Follower的状态的Replica。

一、MoP是啥MoP 即MQTT on Pulsar ，是一个在Pulsar基础上实现的MQTT协议，git地址：https://github.com/streamnative/mop通过MoP可以快速的搭建一个MQTT服务器，下面介绍一下MoP的主要的代码结构。二、MQTT消息定义MQTT的消息在MoP中的定义是MqttMesssage，其代码如下：public class MqttMessage { private final MqttFixedHeader mqttFixe

ReplicaManager负责kafka集群中Topic的分区副本数据的同步功能，当集群中发送副本的变化时，如Partition的Replicas发生leader切换的时候， ReplicaManager会接收来自controller的command命令，ReplicaManager会根据command作出不同的操作， 从而完成Replica的管理工作。ReplicaManager接收的command主要有两种， LeaderAndISRCommand和StopReplicaCommand。需要执行的

一、背景作为一个分布式的消息队列，kafka的日志模块主要用来存储、读取消息，它为kafka集群的高可用、高性能提供了基础。下面结合kafka的源码分析一下日志模块的设计思路。二、日志格式kafka的以topic为单位组织消息，为了提高系统的吞吐率，将一个topic分为N个partition。以partition为单位接收、消费消息。一个partition有多个分片，主分片接收生成者发送的消息，同时副分片从主分片出拉取消息，消费者也从主分片出消费消息。其工作原理如下图。图1-kafka消

SocketServer作为kafka集群中broker的通信模块，主要用来接收socket请求，然后产生为之服务的SocketChannel对象，再通过这个SocketChannel对象来和客户端通信。SocketServer的代码如下：class SocketServer(val brokerId: Int, val host: String, val port: Int, val n

Kafka集群是由若干个broker组成的，启动kafka集群就是将集群中的broker启动并正常运行。broker与broker之间、broker与生成者之间、broker与消费者之间都存在各种交互。下面简单介绍一下broker的启动流程。启动broker的脚本：nohup ./bin/kafka-server-start.sh config/server.properties &其中，脚本文件kafka-server-start.sh启动的操作如下：...

consumer 采用 pull（拉）模式从 broker 中读取数据。push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。pull 模式不足之处是，如果 kafka 没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka 的消费者在消费数

RabbitMQ与Kafka是两周常用的消息队列，下面介绍一下它们的原理和区别一、RabbitMQ的架构： RabbitMQ是一个分布式系统，这里面有几个抽象概念。broker：每个节点运行的服务程序，功能为维护该节点的队列的增删以及转发队列操作请求。 master queue：每个队列都分为一个主队列和若干个镜像队列。 mirror queue：镜像队列，作为master queue的备份。在master queue所在节点挂掉之后，系统把mirror queue提升为master ..