RocketMQ源码分析之消息发送

最新推荐文章于 2024-01-09 08:00:00 发布
最新推荐文章于 2024-01-09 08:00:00 发布
阅读量255 收藏
点赞数
分类专栏： 面试 消息中间件 文章标签： java 队列
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Ethan_199402/article/details/115064255
版权

由于之前线上发生了很严重的消息堆积问题，所以研究了一下rocket的发送源码，这里主要研究消息发送：生产者在发送消息的时候，会根据消息的Topic，选出对应路由信息，再挑选出某个Queue，将消息发送至Queue对应的Broker。

消息对应的Topic信息以及具体内容被封装在了Message中，并交由DefaultMQProducer，调用send（）进行发送。DefaultMQProducer 只是一个面向调用方的代理，真正的生产者是DefaultMQProducerImpl，而消息发送的具体实现，便在DefaultMQProducerImpl中的这个方法内：

话不多说直接上源码：

private SendResult sendDefaultImpl(
        Message msg,
        final CommunicationMode communicationMode,
        final SendCallback sendCallback,
        final long timeout
    )

第一步：找到Topic对应的路由信息。

TopicPublishInfo topicPublishInfo = this.tryToFindTopicPublishInfo(msg.getTopic());

寻找Topic路由并不会这么一行代码那么简单，我们分析下tryToFindTopicPublishInfo(final String topic)中的逻辑。

首先当然是进行本地查表，本地路由信息存放在topicPublishInfoTable中。但是如果本地没有，则会向NameSrv发起请求，获取路由信息，更新本地路由表。接着再次尝试从本地路由表中获取路由信息。

private TopicPublishInfo tryToFindTopicPublishInfo(final String topic) throws MQClientException {
		//本地路由信息存放在topicPublishInfoTable中，第一次调用为null
        TopicPublishInfo topicPublishInfo = this.topicPublishInfoTable.get(topic);
        if (null == topicPublishInfo || !topicPublishInfo.ok()) {
        //如果本地没有，则会向NameSrv发起请求
            this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);
            topicPublishInfo = this.topicPublishInfoTable.get(topic);
        }

        if (topicPublishInfo != null && (topicPublishInfo.isHaveTopicRouterInfo() || topicPublishInfo.ok())) {
            return topicPublishInfo;
        } else {
        //如果Topic事先没有在任何Broker上进行配置，那么Broker在向NameSrv注册路由信息时便不会带上该Topic的路由，所以生产者也就无法从NameSrv中查询到该Topic的路由了
            if (defaultMQProducer.isUseDefaultTopicIfNotFound()) {
                this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic, true, this.defaultMQProducer);
                topicPublishInfo = this.topicPublishInfoTable.get(topic);
                return topicPublishInfo;
            } else {
                throw new MQClientException(ResponseCode.TOPIC_NOT_EXIST, "Topic " + topic + " not exist!");
            }
        }
    }

  1. 如果Topic事先有过设置，从NameSrv上查询到了，此处便会直接返回所找到的路由信息：topicPublishInfo。但是如果Topic事先没有在任何Broker上进行配置，那么Broker在向NameSrv注册路由信息时便不会带上该Topic的路由，所以生产者也就无法从NameSrv中查询到该Topic的路由了。

  2. 对于这种没有事先配置Topic的情况，RocketMQ不会直接抛出错误，而是会走到上面的else分支里，再次调用 updateTopicRouteInfoFromNameServer(topic, true, this.defaultMQProducer)，从NameSrv 获取路由信息。

既然前面已经从NameSrv中没有查询到，为何还要在查询一次呢？
让我们先查看updateTopicRouteInfoFromNameServer方法（第一次从NameSrv获取Topic路由信息）：

public boolean updateTopicRouteInfoFromNameServer(final String topic) {
        return updateTopicRouteInfoFromNameServer(topic, false, null);
    }

该方法又调用了同名方法updateTopicRouteInfoFromNameServer，只是参数多了两个，并且加有默认值，获取有读者已经注意到，这个方法跟第二次查询路由信息的方法调用很相似：

updateTopicRouteInfoFromNameServer(topic, false, null);//第一次
updateTopicRouteInfoFromNameServer(topic, true, this.defaultMQProducer)//第二次

两次调用为何参数不同？我们继续往下看实现逻辑：

public boolean updateTopicRouteInfoFromNameServer(final String topic, boolean isDefault,
        DefaultMQProducer defaultMQProducer) {
        try {
            if (this.lockNamesrv.tryLock(LOCK_TIMEOUT_MILLIS, TimeUnit.MILLISECONDS)) {
                try {
                    TopicRouteData topicRouteData;
                    //注意这里便是外部调用传进来的boolean参数，起到流程控制的作用
                    if (isDefault && defaultMQProducer != null) {
                        topicRouteData = this.mQClientAPIImpl.getDefaultTopicRouteInfoFromNameServer(defaultMQProducer.getCreateTopicKey(),
                            1000 * 3);
                        if (topicRouteData != null) {
                            for (QueueData data : topicRouteData.getQueueDatas()) {
                                int queueNums = Math.min(defaultMQProducer.getDefaultTopicQueueNums(), data.getReadQueueNums());
                                data.setReadQueueNums(queueNums);
                                data.setWriteQueueNums(queueNums);
                            }
                        }
                    } else //第一次因为isDefault为false进入这个分支
                        topicRouteData = this.mQClientAPIImpl.getTopicRouteInfoFromNameServer(topic, 1000 * 3);
                    }
                    if (topicRouteData != null) {
                    //首次为null
                        TopicRouteData old = this.topicRouteTable.get(topic);
                        //判断topicRouteData是否改变
                        boolean changed = topicRouteDataIsChange(old, topicRouteData);
                        if (!changed) {
                    
                            changed = this.isNeedUpdateTopicRouteInfo(topic);
                        } else {
                            log.info("the topic[{}] route info changed, old[{}] ,new[{}]", topic, old, topicRouteData);
                        }
						//如果路由表有变化，则Update Pub info和Update sub info
                        if (changed) {
                            TopicRouteData cloneTopicRouteData = topicRouteData.cloneTopicRouteData();

                            for (BrokerData bd : topicRouteData.getBrokerDatas()) {
                                this.brokerAddrTable.put(bd.getBrokerName(), bd.getBrokerAddrs());
                            }

                            // Update Pub info
                            {
                                TopicPublishInfo publishInfo = topicRouteData2TopicPublishInfo(topic, topicRouteData);
                                publishInfo.setHaveTopicRouterInfo(true);
                                Iterator<Entry<String, MQProducerInner>> it = this.producerTable.entrySet().iterator();
                                while (it.hasNext()) {
                                    Entry<String, MQProducerInner> entry = it.next();
                                    MQProducerInner impl = entry.getValue();
                                    if (impl != null) {
                                        impl.updateTopicPublishInfo(topic, publishInfo);
                                    }
                                }
                            }

                            // Update sub info
                            {
                                Set<MessageQueue> subscribeInfo = topicRouteData2TopicSubscribeInfo(topic, topicRouteData);
                                Iterator<Entry<String, MQConsumerInner>> it = this.consumerTable.entrySet().iterator();
                                while (it.hasNext()) {
                                    Entry<String, MQConsumerInner> entry = it.next();
                                    MQConsumerInner impl = entry.getValue();
                                    if (impl != null) {
                                        impl.updateTopicSubscribeInfo(topic, subscribeInfo);
                                    }
                                }
                            }
                            log.info("topicRouteTable.put. Topic = {}, TopicRouteData[{}]", topic, cloneTopicRouteData);
                            this.topicRouteTable.put(topic, cloneTopicRouteData);
                            return true;
                        }
                    } else {
                        log.warn("updateTopicRouteInfoFromNameServer, getTopicRouteInfoFromNameServer return null, Topic: {}", topic);
                    }
                } catch (Exception e) {
                    if (!topic.startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX) && !topic.equals(MixAll.DEFAULT_TOPIC)) {
                        log.warn("updateTopicRouteInfoFromNameServer Exception", e);
                        if (e instanceof MQClientException && ResponseCode.TOPIC_NOT_EXIST == ((MQClientException) e).getResponseCode()) {
                            // clean no used topic
                            cleanNoneRouteTopic(topic);
                        }
                    }
                } finally {
                    this.lockNamesrv.unlock();
                }
            } else {
                log.warn("updateTopicRouteInfoFromNameServer tryLock timeout {}ms", LOCK_TIMEOUT_MILLIS);
            }
        } catch (InterruptedException e) {
            log.warn("updateTopicRouteInfoFromNameServer Exception", e);
        }

        return false;
    }

  1. 外部调用传进来的topic，isDefault参数，起到流程控制的作用，如果指定的topic没有查到路由信息，则使用默认topic。该默认Topic为 TBW102 ，这个Topic就是用来创建其他Topic所用的，则同时传入defaultMQProducer,通过defaultMQProducer.getCreateTopicKey()方法自动创建topic，然后再查询路由信息

    如果某Broker配置了 autoCreateTopicEnable，允许自动创建Topic，那么在该Broker启动后，便会向自己的路由表中插入TBW102这个Topic，并注册到NameSrv，表明处理该Topic类型的消息。

  2. 判断返回的topicRouteData和原来的是否有改变

    	private boolean topicRouteDataIsChange(TopicRouteData olddata, TopicRouteData nowdata) {
	        if (olddata == null || nowdata == null)
	            return true;
	        TopicRouteData old = olddata.cloneTopicRouteData();
	        TopicRouteData now = nowdata.cloneTopicRouteData();
	        Collections.sort(old.getQueueDatas());
	        Collections.sort(old.getBrokerDatas());
	        Collections.sort(now.getQueueDatas());
	        Collections.sort(now.getBrokerDatas());
	        return !old.equals(now);
	
	    }

  3. 若有改变，则更新发布和订阅信息

  4. 更新发布：通过topicRouteData2TopicPublishInfo方法组装publishInfo，将QueueDatas中的每一个写队列（默认8个）生成一个MessageQueue 放入集合中

    List<QueueData> qds = route.getQueueDatas();
            Collections.sort(qds);
            for (QueueData qd : qds) {
                if (PermName.isWriteable(qd.getPerm())) {
                    BrokerData brokerData = null;
                    for (BrokerData bd : route.getBrokerDatas()) {
                        if (bd.getBrokerName().equals(qd.getBrokerName())) {
                            brokerData = bd;
                            break;
                        }
                    }
                    if (null == brokerData) {
                        continue;
                    }
                    if (!brokerData.getBrokerAddrs().containsKey(MixAll.MASTER_ID)) {
                        continue;
                    }
                    //将写队列生成一个MessageQueue 放入集合中
                    for (int i = 0; i < qd.getWriteQueueNums(); i++) {
                        MessageQueue mq = new MessageQueue(topic, qd.getBrokerName(), i);
                        info.getMessageQueueList().add(mq);
                    }
                }
            }

    下面是QueueDatas和BrokerDatas的具体截图
    在这里插入图片描述

  5. 更新订阅：通过topicRouteData2TopicSubscribeInfo方法组装subscribeInfo，将QueueDatas中的每一个读队列（默认8个）生成一个MessageQueue 放入集合中

    for (QueueData qd : qds) {
            if (PermName.isReadable(qd.getPerm())) {
                for (int i = 0; i < qd.getReadQueueNums(); i++) {
                    MessageQueue mq = new MessageQueue(topic, qd.getBrokerName(), i);
                    mqList.add(mq);
                }
            }
        }

  6. 最后更新本地路由表：this.topicRouteTable.put(topic, cloneTopicRouteData);

第二步：选择某个Queue用来发送消息

当拥有了topicPublishInfo信息后，就要选择Queue来发送信息了

 MessageQueue mqSelected = this.selectOneMessageQueue(topicPublishInfo, lastBrokerName);

在看他的源码之前我们先回顾一下第一步的路由信息
QueueDatas的截图：
在这里插入图片描述
那么QueueDatas的结构呢？

public class TopicRouteData extends RemotingSerializable {
    private String orderTopicConf;
    private List<QueueData> queueDatas;
    private List<BrokerData> brokerDatas;
    private HashMap<String/* brokerAddr */, List<String>/* Filter Server */> filterServerTable;
}

里面简单的记录了brokerAddr 和两个int类型的QueueNums。

其实对于RokcetMQ来说，Queue是比较抽象的一个概念，并不是说某个具体的队列。Topic、QueueData以及Broker是 1:1:1 的，QueueData本质上是记录某个Topic在某个Broker上的所有路由信息。

brokerName：这个很容易理解，Queue所属的Broker；
readQueueNums：该Broker上，针对该Topic，配置的读队列个数；
writeQueueNums：该Broker上，针对该Topic，配置的写队列个数。

前面的第一步中，我们已经分析了当生产者从NameSrv获取到Topic对于的TopicRouteData时，是如何将其转成TopicPublishInfo,存放在本地路由表中。

更加了解过数据结构之后，让我们接着之前的话题：生产者如何选择某个Queue进行消息发送。

public MessageQueue selectOneMessageQueue(final String lastBrokerName) {
        if (lastBrokerName == null) {
            return selectOneMessageQueue();
        } else {
            int index = this.sendWhichQueue.getAndIncrement();
            for (int i = 0; i < this.messageQueueList.size(); i++) {
                int pos = Math.abs(index++) % this.messageQueueList.size();
                if (pos < 0)
                    pos = 0;
                MessageQueue mq = this.messageQueueList.get(pos);
                if (!mq.getBrokerName().equals(lastBrokerName)) {
                    return mq;
                }
            }
            return selectOneMessageQueue();
        }
    }
  1. 当lastBrokerName不为空，将计数器进行自增，再遍历MessageQueue列表，按照计数器数值对MessageQueue总个数进行取模，再根据取模结果，取出MessageQueue列表中的某个Queue，并判断Queue所属Broker的Name是否和lastBrokerName一致，一致则继续遍历。
  2. 当lastBrokerName为空时，同样将计数器进行自增，按照计数器数值对MessageQueue总个数进行取模，再根据取模结果，取出MessageQueue列表中的某个Queue，直接返回。
    这段逻辑的主要部分就是利用计数器，来进行Queue的负载均衡。

那么lastBrokerName的作用是什么？

当某条消息第一次发送时，lastBrokerName 为空，此时就是直接取模进行负载均衡操作。但是如果消息发送失败，就会触发重试机制，发送失败有可能是因为Broker出现来某些故障，或者某些网络连通性问题，所以当消息第N次重试时，就要避开第N-1次（上一次）时消息发往的Broker，也就是lastBrokerName。

第三步：消息发送的过程

接下来就是发送消息了

sendResult = this.sendKernelImpl(msg, mq, communicationMode, sendCallback, topicPublishInfo, timeout);

  1. 获取Queue所属Broker的地址：String brokerAddr = this.mQClientFactory.findBrokerAddressInPublish(mq.getBrokerName());

  2. 要将消息内容及其他信息封装进请求头

     SendMessageRequestHeader requestHeader = new SendMessageRequestHeader();
                requestHeader.setProducerGroup(this.defaultMQProducer.getProducerGroup());
                requestHeader.setTopic(msg.getTopic());
                requestHeader.setDefaultTopic(this.defaultMQProducer.getCreateTopicKey());
                requestHeader.setDefaultTopicQueueNums(this.defaultMQProducer.getDefaultTopicQueueNums());
                requestHeader.setQueueId(mq.getQueueId());
                requestHeader.setSysFlag(sysFlag);
                requestHeader.setBornTimestamp(System.currentTimeMillis());
                requestHeader.setFlag(msg.getFlag());
                requestHeader.setProperties(MessageDecoder.messageProperties2String(msg.getProperties()));
                requestHeader.setReconsumeTimes(0);
                requestHeader.setUnitMode(this.isUnitMode());
                requestHeader.setBatch(msg instanceof MessageBatch);

  3. 发送消息

接下里拆解消息发送

  1. 请求参数

     if (sendSmartMsg || msg instanceof MessageBatch) {
            SendMessageRequestHeaderV2 requestHeaderV2 = SendMessageRequestHeaderV2.createSendMessageRequestHeaderV2(requestHeader);
            request = RemotingCommand.createRequestCommand(msg instanceof MessageBatch ? RequestCode.SEND_BATCH_MESSAGE : RequestCode.SEND_MESSAGE_V2, requestHeaderV2);
        } else {
            request = RemotingCommand.createRequestCommand(RequestCode.SEND_MESSAGE, requestHeader);
        }

    这里按照是否发送 smartMsg ，创建了不同请求命令号的请求，

  2. 接下来，按照发送方式（单向、同步、异步），调用不同的发送函数：

    switch (communicationMode) {
            case ONEWAY:
                this.remotingClient.invokeOneway(addr, request, timeoutMillis);
                return null;
            case ASYNC:
                final AtomicInteger times = new AtomicInteger();
                this.sendMessageAsync(addr, brokerName, msg, timeoutMillis, request, sendCallback, topicPublishInfo, instance,
                    retryTimesWhenSendFailed, times, context, producer);
                return null;
            case SYNC:
                return this.sendMessageSync(addr, brokerName, msg, timeoutMillis, request);
            default:
                assert false;
                break;
        }

这里复习下三种发送方式。

单向：只管发送，不管是否发送成功；
同步：阻塞至拿到发送结果；
异步：发送后直接返回，在回调函数中等待发送结果。
至此消息的发送就已经结束了，成功的从生产者传输到了Broker。

四： 总结

1：获取路由信息

2：按照负载均衡方式，选择queue

3：根据选择出的queue，发送消息到Broker。

4：Topic 没有提前配置的情况下如何进行路由选择？

  1. 如果某Broker配置了 autoCreateTopicEnable，允许自动创建Topic，那么在该Broker启动后，便会向自己的路由表中插入TBW102这个Topic，并注册到NameSrv，表明处理该Topic类型的消息。

  2. 如果指定的topic没有查到路由信息，则使用默认topic。该默认Topic为 TBW102 ，这个Topic就是用来创建其他Topic所用的，则同时传入defaultMQProducer,通过defaultMQProducer.getCreateTopicKey()方法自动创建topic，然后再查询路由信息

消息发送失败的情况下如何重试？
如果消息发送失败，就会触发重试机制，发送失败有可能是因为Broker出现某些故障，或者某些网络连通性问题，所以当消息第N次重试时，就要避开第N-1次（上一次）时消息发往的Broker，也就是lastBrokerName。

Ethan_199402
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Rocketmq 源码分析之发送消息
程序员Linc
05-07 546
在具体的实现过程中，RocketMQ并不直接将消息发送给一个指定的 Broker 节点，而是采用 Broker 的路由机制，通过 NameServer 自动获取到目标 Broker 上存储 Topic 相应的消息队列，在将消息发送到队列中。例如，消息的选择、创建、序列化等过程。3. 查找 Broker 端所在服务（根据 Topic 进行查找），然后从 Broker 端中获取到 Topic 所分配的消息队列（Message Queue）列表，并根据消息发送的策略，选择正确的消息队列进行消息发送。
RocketMQ 源码分析之消息轨迹
qq_61890005的博客
10-17 327
TraceContext中存储的是消息轨迹的上下文信息，具体包含：消息轨迹的类型、broker所属Region的ID、broker所属Region的名称、组名、耗时、被追踪的消息是否发送成功、请求ID、消费结果返回的状态码、轨迹数据的集合。TraceBean中存储的是消息轨迹数据，具体包含：消息topic、消息ID、消息offset、消息tag、消息key、消息存储地址、消息客户端地址、消息存储时间、消息重试次数、消息长度、消息类型。示例demo、消息轨迹的源码分析和消息轨迹中存储的信息。
RocketMQ源码分析
lx9876lx的博客
02-27 5338
RocketMQ源码分析
8、RocketMQ 源码解析之消息发送
carl.zhao的专栏
05-04 868
当我们启动了元数据管理 NameServer 以及 消息管理 Broker。下面我们就可以进行消息发送了。RocketMQ 支持三种消息发送方式： 同步消息发送(sync)：当 Producer 发送消息到 Broker 时会同步等待消息处理结果 异步消息发送(async)：当 Producer 发送消息到 Broker 时会指定一个消息发送成功的回调函数，调用消息发送后立即返回不会阻塞。消息发送成功或者失败会在一个新的线程中进行处理。 单向消息发送(oneway)：当 Producer 发送消息到 Br
Rocketmq 源码分析（一）消息发送
码农养家
04-15 424
@[TOC]Rocketmq 源码分析（一）消息发送 整体架构 nameserver : 存放 broker (服务代理) broker ： 服务代理 可以看到nameserver只是负责管理broker 的，提供broker的查找以及存储。而broker是服务代理，处理消息的接口以及转发，使用netty 作为消息的处理。 消息发送 从例子中可以看到 需要先设置下nameserver ，我们看...
RocketMQ源码分析之消息持久化
Ethan_199402的博客
03-23 337
说到消息的持久化，笔者因为对kafka了解在先，于是首先的疑问是： 消息是放在内存吗？ 这一点是不可能的，任何一个成熟的mq，消息都是持久化的，放内存不可能存贮那么多的消息 消息是放在队列里面吗？ 答案是不是的，kafka的消息持久化在分区，而rocketMq的消息持久化在commitLog中 那么rocketMq是不是也像kafka那样分块存储消息呢？ 如果所有消息全都存放到一个文件中，消息检索会很耗时，过期消息的清理也会很麻烦，所以消息肯定要进行多文件存储。 到底如何实现呢？ 每个Broker都对应有一
RocketMQ源码 发送消息源码分析
hzwangmr的博客
01-06 477
DefaultMQProducer 是默认生产者组件，是生产者客户端中，绝大部分关于生产者和broker、nameSrv进行网络通信的功能入口。其中，包含发送各种形式（同步、异步、事务、顺序）的消息，针对发送消息部分的实现，主要是封装好消息协议后，从NameSrv获取当前Topic路由信息，轮询悬着一个队列，通过RemotingClient 客户端，将请求发送给messageQueue所在的broker的主节点。 broker主节点收到消息后，SendMessageProcessor 发送消息处理组件处理
rocketmq源码分析
BraveHeart
04-23 2988
文章目录前言一、NameServer路由中心二、消息存储1.消息发送存储流程2.存储文件三、消息消费1、消息者启动流程2、消息拉取1、PullMessageService实现机制2、ProcessQueue实现机制3、消息拉取基本流程3.1客户端封装消息拉取请求3.2消息服务端Broker组装信息3.3消息拉取客户端处理消息3.4消息拉取长轮询机制分析3.5PullRequestHoldService3.6DefaultMessageStore$ReputMessageService详解总结 前言 疫情期
源码分析之RocketMQ发送消息与接收消息
evasnowind的专栏
10-13 571
说明 本文主要是本人学习、整理的笔记，涉及的内容可能来自网上，我会尽量注明来源。 我本人阅读的rocketmq代码版本为4.7.1。 producer发送消息 有关producer生产消息，之前参考极客时间 消息队列高手课，写过一篇学习笔记，参考这里源码分析之RocketMQ Producer生产消息的实现及其设计模式分析 此处再给出一些参考图片与资料 producer发送消息总体过程 此图来自：http://www.iocoder.cn/RocketMQ/message-send-and-receive
RocketMQ源码 发送 延迟消息 源码分析
最新发布
hzwangmr的博客
01-09 1071
rocketMQ 支持的延迟消息，简单理解就是对于生产者发送的消息，支持设置固定时间的延迟级别，在到达指定的延迟时间时，才会投递到消费者队列，消费者才能消费到消息。
springboot整合rocketmq源码
04-22
【标题】：SpringBoot整合RocketMQ源码解析 在当今的微服务架构中，消息队列（Message Queue）已经成为解耦、异步处理以及提高系统可靠性的关键组件。本主题将深入探讨如何在SpringBoot应用中整合Apache RocketMQ，...
rocketmq源码.zip
01-06
通过对RocketMQ源码的深入学习，我们可以了解到其实现消息的存储、传输、消费等过程的具体细节，这对于优化性能、解决实际问题以及理解分布式系统的设计理念具有重要意义。在源码中，你可以看到如MessageStore、...
深入探索RocketMQ源码：透视消息中间件的内核机制
12-22
《深入探索RocketMQ源码：透视消息中间件的内核机制》 RocketMQ，作为一款高性能、高可用的消息中间件，被广泛应用于分布式系统设计中。本文将带领读者深入其源码，理解其核心组件与功能，从而更好地掌握RocketMQ在...
rocketmq 源码 rocketmq 源码 rocketmq 源码
10-25
源码分析是深入理解其工作原理和优化技术的关键。RocketMQ 的源码解析有助于开发者更好地掌握其实现机制，提升在实际项目中的应用能力。 1. **整体架构** RocketMQ 采用主从复制模型，主要包含四个核心组件：...
Apache RocketMQ 源码解析1
08-03
在阅读RocketMQ源码时，理解Raft协议的工作原理至关重要。选主过程通常包括节点之间的通信和投票机制，确保只有一个节点能成为领导者，并且所有其他节点都认可这一选择。日志复制则涉及到领导者将新接收到的命令（或...
JVM （十）Java虚拟机栈栈详解，一文透彻栈的那些事（方法调用，动态分派，栈上分配等）
Ethan_199402的博客
12-30 1489
我们已经从JVM（一） 面试必知——运行时数据区域 了解到Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。 本篇详解Java虚拟机栈相关内容 运行时栈帧结构 Java虚拟机以方法作为最基本的执行单元，“栈帧”（Stack Frame）则是用于支持虚拟机进行方法 调用和方法执行背后的数据结构，它也是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。 每 一个方法从调用开始至执行结束的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程
rocketMQ 总结
Ethan_199402的博客
03-19 865
RocketMQ由哪些角色组成，每个角色作用和特点是什么？ Nameserver 无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。前者保证AP,后者保证CP，NameServer 每个节点相互之间没有数据过程、都是独立的 （ap模式）保证可用性、不保证每个NameServer 数据的一致性问题。存储Broker 的IP和端口号 主题信息、集群信息 过滤器等 Producer 消息生产者，负责发消息到Broker。采用轮询算法连接nameserver 如果能够获取到
从裸辞面试阿里说起
Ethan_199402的博客
06-17 783
        我呢，毕业于普通一本，一般般的双一流高校，没有名校光环。本科是自动化，软件硬件都学，c和汇编都会，而java则属于半路出家。         工作三年，有三份工作经验（着实挺尴尬的履历），第一份工作是一个巨无霸外企，但是作为成本中心并非是企业的核心板块，身边的人都是30岁靠上，在这样一个养老环境我坚持了一年半，期间前端后端运维都干，j
面试官：我们聊聊线程池吧
Ethan_199402的博客
07-30 769
阻塞队列 讲原理之前应该先了解一下阻塞队列，之所以是阻塞队列，是因为队列为空时，消费者从队列获取数据将一直阻塞直至队列非空，队列满时生产者往队列插入数据将一直阻塞直至队列非满 下面引用《java并发编程的艺术》原文： 在阻塞队列不可用时，这两个附加操作提供了4种处理方式 抛出异常：是指当阻塞队列满时候，再往队列里插入元素，会抛出 IllegalStateException(“Queue full”) 异常。当队列为空时，从队列里获取元素时会抛出 NoSuchElementException 异常 。 返回
深入理解字符串常量池，常见面试题总结
Ethan_199402的博客
12-29 662
什么是字符串常量池 string的string Pool是一个圉定大小的Hashtable，默认值大小长度是1009。如果放进string Pool的string非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用string.intern时性能会大幅下降。 参数设置 使用-xX :StringTablesize可设置stringTable的长度 在jdk6中stringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快。Stri
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值