RocketMq——Consume相关源码

摘要

RocketMQ只要有CommitLog文件就可以正常运行了，那为何还要维护ConsumeQueue文件呢？

ConsumeQueue是消费队列，引入它的目的是为了提高消费者的消费速度。毕竟RocketMQ是基于Topic主题订阅模式的，消费者往往只关心自己订阅的消息，如果每次消费都从CommitLog文件中检索数据，无疑性能是非常差的。有了ConsumeQueue，消费者就可以根据消息在CommitLog文件中的偏移量快速定位到消息进行消费了。

Broker会将客户端发送的消息写入CommitLog文件，持久化存储。但是整个流程并没有涉及到ConsumeQueue文件的操作，那么ConsumeQueue文件是如何被构建的呢？

一、CommitLog文件构建分析

ReputMessageService是消息重放服务，请允许我这么命名。Broker在启动的时候，会开启一个线程每毫秒执行一次doReput()方法。

它的目的就是对写入CommitLog文件里的消息进行「重放」，它有一个属性reputFromOffset，记录的是消息重放的偏移量，MessageStore启动的时候会对其进行赋值。

它的工作原理是，根据重放偏移量reputFromOffset去读取CommitLog里的待重放的消息，并构建DispatchRequest对象，然后将DispatchRequest对象分发出去，交给各个CommitLogDispatcher处理。

MessageStore维护了CommitLogDispatcher对象集合，目前只有三个处理器：

  1. CommitLogDispatcherBuildConsumeQueue：构建ConsumeQueue索引。
  2. CommitLogDispatcherBuildIndex：构建Index索引。
  3. CommitLogDispatcherCalcBitMap：构建布隆过滤器，加速SQL92过滤效率。

doReput()方法1毫秒执行一次，它的方法体是一个for循环，只要reputFromOffset没有到达CommitLog文件的最大偏移量，就会一直继续重放消息。

private boolean isCommitLogAvailable() {
    return this.reputFromOffset < DefaultMessageStore.this.commitLog.getMaxOffset();
}

它首先会根据reputFromOffset去CommitLog文件中截取一段ByteBuffer，这个缓冲区里就是待重放的消息数据。

public SelectMappedBufferResult getData(final long offset, final boolean returnFirstOnNotFound) {
    // CommitLog单个文件的大小
    int mappedFileSize = this.defaultMessageStore.getMessageStoreConfig().getMappedFileSizeCommitLog();
    // 根据索引构建进度找到等待构建的文件，文件名就是起始Offset，遍历文件即可找到
    MappedFile mappedFile = this.mappedFileQueue.findMappedFileByOffset(offset, returnFirstOnNotFound);
    if (mappedFile != null) {
        // 计算Offset在当前文件的读指针位置
        int pos = (int) (offset % mappedFileSize);
        /**
         * 基于MappedFile的MappedByteBuffer派生出一个ByteBuffer对象
         * 共享同一块内存，但是拥有自己的指针
         */
        SelectMappedBufferResult result = mappedFile.selectMappedBuffer(pos);
        return result;
    }
    return null;
}

SelectMappedBufferResult类属性如下：

// 起始偏移量
private final long startOffset;
// 缓冲区
private final ByteBuffer byteBuffer;
// 长度
private int size;
// 关联的MappedFile对象
private MappedFile mappedFile;

有了SelectMappedBufferResult，就可以读取消息数据了。由于消息重放并不需要知道消息主体内容，因此不会读取消息Body，只是读取相关属性，并构建DispatchRequest对象。读取的属性如下：

// 消息所属Topic
private final String topic;
// 消息所属队列ID
private final int queueId;
// 消息在CommitLog文件中的偏移量
private final long commitLogOffset;
// 消息大小
private int msgSize;
// 消息Tag哈希码
private final long tagsCode;
// 消息存盘时间
private final long storeTimestamp;
// 逻辑消费队列位点
private final long consumeQueueOffset;
private final String keys;
private final boolean success;
// 消息唯一键
private final String uniqKey;
// 消息系统标记
private final int sysFlag;
// 事务消息偏移量
private final long preparedTransactionOffset;
// 属性
private final Map<String, String> propertiesMap;

有了DispatchRequest对象，接下来就是调用doDispatch方法将请求分发出去了。此时CommitLogDispatcherBuildConsumeQueue将被触发，它会将请求转交给DefaultMessageStore执行。

DefaultMessageStore.this.putMessagePositionInfo(request);

MessageStore先根据消息Topic和QueueID定位到ConsumeQueue文件，然后将索引追加到文件中。

public void putMessagePositionInfo(DispatchRequest dispatchRequest) {
    // 根据Topic和QueueID定位到ConsumeQueue文件
    ConsumeQueue cq = this.findConsumeQueue(dispatchRequest.getTopic(), dispatchRequest.getQueueId());
    // 追加索引到文件
    cq.putMessagePositionInfoWrapper(dispatchRequest);
}

写索引之前，会先确保消息仓库是可写状态：

boolean canWrite = this.defaultMessageStore.getRunningFlags().isCQWriteable();

然后，初始化一个ByteBuffer，容量为20字节，依次往里面写入：消息Offset、size、tagsCode。

// 每个索引的长度是20字节，byteBufferIndex是循环使用的
this.byteBufferIndex.flip();
this.byteBufferIndex.limit(CQ_STORE_UNIT_SIZE);
/**
* 索引结构:Offset+size+tagsCode
* 8字节 4字节 8字节
*/
this.byteBufferIndex.putLong(offset);
this.byteBufferIndex.putInt(size);
this.byteBufferIndex.putLong(tagsCode);

根据消费队列位点和单个索引的长度计算索引应该写入的文件位置，因为是顺序写的嘛，所以获取最新的ConsumeQueue文件，如果文件写满会创建新的继续写。 

final long expectLogicOffset = cqOffset * CQ_STORE_UNIT_SIZE;
MappedFile mappedFile = this.mappedFileQueue.getLastMappedFile(expectLogicOffset);

写之前，校验预期的偏移量和逻辑偏移量是否相等，正常情况下两者应该相等，如果不等说明数据构建错乱了，需要重新构建了。、

if (cqOffset != 0) {
    // 偏移量:当前文件的写指针位置+文件起始偏移量(文件名)
    long currentLogicOffset = mappedFile.getWrotePosition() + mappedFile.getFileFromOffset();

    // 正常情况下，expectLogicOffset和currentLogicOffset应该相等
    if (expectLogicOffset < currentLogicOffset) {
        log.warn("Build  consume queue repeatedly, expectLogicOffset: {} currentLogicOffset: {} Topic: {} QID: {} Diff: {}",
                 expectLogicOffset, currentLogicOffset, this.topic, this.queueId, expectLogicOffset - currentLogicOffset);
        return true;
    }
    if (expectLogicOffset != currentLogicOffset) {
        LOG_ERROR.warn(
            "[BUG]logic queue order maybe wrong, expectLogicOffset: {} currentLogicOffset: {} Topic: {} QID: {} Diff: {}",
            expectLogicOffset,
            currentLogicOffset,
            this.topic,
            this.queueId,
            expectLogicOffset - currentLogicOffset
        );
    }
}

检验通过后，就可以正常写了。先更新当前ConsumeQueue记录消息的最大偏移量maxPhysicOffset，再将20个字节的索引数据写入到文件。 

至此，就完成了CommitLog中的消息到ConsumeQueue文件里的索引同步。

ConsumeQueue是RocketMQ用来加速消费者消费效率的索引文件，它是一个逻辑消费队列，并不保存消息本身，只是一个消息索引。索引长度为20个字节，记录了消息在CommitLog文件里的偏移量，消息长度，和消息Tag的哈希值。Consumer消费消息时可以根据Tag哈希值快速过滤消息，然后根据偏移量快速定位到消息，再根据消息长度读取出一条完整的消息。
​

Broker将消息写入CommitLog后并不会马上写ConsumeQueue，而是由一个异步线程ReputMessageService将消息进行重放，重放的过程中由CommitLogDispatcherBuildConsumeQueue将消息构建到ConsumeQueue文件，构建的频率为1毫秒一次，几乎是近实时的，不用担心消费会延迟。

二、Consumer消息拉取和消费分析

MQConsumer是RocketMQ提供的消费者接口，从接口定义上可以看到，它主要的功能是订阅感兴趣的Topic、注册消息监听器、启动生产者开始消费消息。

消费者获取消息的模式有两种：推模式和拉模式，对应的类分别是DefaultMQPushConsumer和DefaultMQPullConsumer，需要注意的是，在4.9.0版本，DefaultMQPullConsumer已经被废弃了。

Push模式下，由Broker接收到消息后主动推送给消费者，实时性较高，但是会增加Broker的压力。Pull模式下，由消费者主动从Broker拉取消息，主动权在消费者，这种方式更灵活，消费者可以根据自己的消费能力拉取适量的消息。

实际上，Push模式也是通过Pull的方式实现的，消息统一由消费者主动拉取，那如何保证消息的实时性呢？

Consumer和Broker会建立长连接，一旦分配到MessageQueue，就会立马构建PullRequest去拉取消息，在不触发流控的情况下，不管有没有拉取到新的消息，Consumer都会立即再次拉取，这样就保证了消息消费的实时性。

如果Broker长时间没有新的消息，Consumer一直拉取，岂不是空转CPU浪费资源？

Consumer在拉取消息时，会携带参数suspendTimeoutMillis，它表示Broker在没有新的消息时，阻塞等待的时间，默认是15秒。如果没有消息，Broker等待15秒再返回结果，避免客户端频繁拉取。如果15秒内有新的消息了，立马返回，保证消息消费的时效性。

2.1 Consumer相关组件

DefaultMQPushConsumer

RocketMQ暴露给开发者使用的基于Push模式的默认生产者类，和DefaultMQProducer一样，它也仅仅是一个外观类，基本没有业务逻辑，几乎所有操作都转交给生产者实现类DefaultMQPushConsumerImpl完成。这么做的好处是RocketMQ屏蔽了内部实现，方便在后续的版本中随时更换实现类，而用户无感知。

DefaultMQPushConsumerImpl

默认的基于Push模式的消费者实现类，拥有消费者的所有功能，例如：拉取消息、执行钩子函数、消费者重平衡等等。

PullAPIWrapper

调用拉取消息API的包装类，它是Consumer拉取消息的核心类，它有一个方法特别重要pullKernelImpl，是拉取消息的核心方法。它会根据拉取的MessageQueue去查找对应的Broker，然后构建拉取消息请求头PullMessageRequestHeader发送到Broker，然后执行拉取回调，在回调里会通知消费者消费拉取到的消息。

OffsetStore

OffsetStore是RocketMQ提供的，用来帮助Consumer管理消费位点(消费进度)的接口，它有两个实现类：LocalFileOffsetStore和RemoteBrokerOffsetStore，从名字就可以看出来，一个是将消费进度存储在本地，一个是将消费进度存储在Broker上。
LocalFileOffsetStore会将消费进度持久化到本地磁盘，Consumer启动后会从指定目录读取文件，恢复消费进度。
RemoteBrokerOffsetStore将消费进度交给Broker管理，Consumer不会存储到文件，没有意义，但是消费消息时会暂存消费进度在内存，然后在拉取消息时上报消费进度，由Broker负责存储。

什么场景下需要将消费进度存储在本地呢？这和RocketMQ消息消费模式有关，RocketMQ支持两种消息消费模式：集群消费和广播消费。一个ConsumerGroup下可以有多个消费者实例，集群模式下，消息只会投递给其中一个Consumer实例消费，而广播模式下，消息会投递给每个Consumer实例。

综上所述，集群模式下，消费进度由Broker管理，使用RemoteBrokerOffsetStore。广播模式下，因为消息需要被每个Consumer实例消费，每个实例消费的进度是不一样的，因此由实例自己存储消费进度，使用LocalFileOffsetStore。

ConsumeMessageService

消费消息的服务，客户端拉取到消息后，是需要有线程去消费的，因此它是一个线程池，线程数由consumeThreadMin和consumeThreadMax设置，默认线程数为20。

它是一个接口，比较重要的两个方法如下：

// 当前线程直接消费消息
ConsumeMessageDirectlyResult consumeMessageDirectly(final MessageExt msg, final String brokerName);

// 提交消费请求，由线程池去调度
void submitConsumeRequest(
    final List<MessageExt> msgs,
    final ProcessQueue processQueue,
    final MessageQueue messageQueue,
    final boolean dispathToConsume);

一个是由当前线程直接消费消息，另一个是提交消费请求ConsumeRequest由线程池去负责调度，一般情况下使用的还是后者。

RocketMQ提供了两个实现类，分别是ConsumeMessageConcurrentlyService和ConsumeMessageOrderlyService，前者用来并发消费消息，后者用来消费有序消息。

PullMessageService

消息拉取服务，负责从Broker拉取消息，然后提交给ConsumeMessageService消费。它也是一个线程，它的run方法是一个死循环，通过监听阻塞队列来判断是否需要拉取消息。阻塞队列里存放的就是PullRequest对象，当Consumer实例上线后，会做一次负载均衡，从众多MessageQueue中给自己完成分配，当有新的MessageQueue被分配给自己，就会创建PullRequest对象提交到阻塞队列，然后PullMessageService就会开始拉取消息，在拉取完成的回调函数中，不管有没有拉取到新的消息，在不触发流控的情况下，都会一直拉取。

2.2 Consumer相关源码分析

整个Consumer的运行可以大致分为四个过程：

  1. 消费者启动
  2. 消费者组负载均衡
  3. 消息的拉取
  4. 消息的消费

Consumer的启动流程和Producer有部分重合之处。

首先自然是创建DefaultMQPushConsumer，在它的构造函数中，会创建消费者实现类DefaultMQPushConsumerImpl。

public DefaultMQPushConsumer(final String namespace, final String consumerGroup, RPCHook rpcHook,
    AllocateMessageQueueStrategy allocateMessageQueueStrategy) {
    // 消费组名
    this.consumerGroup = consumerGroup;
    // 命名空间
    this.namespace = namespace;
    // 消息队列分配策略算法
    this.allocateMessageQueueStrategy = allocateMessageQueueStrategy;
    // 消费者实现类
    defaultMQPushConsumerImpl = new DefaultMQPushConsumerImpl(this, rpcHook);
}

前面说过，DefaultMQPushConsumer只是一个外观类，它更多的职责只是保存Consumer的配置，它的属性可以重点关注一下：

// 消费者实现
protected final transient DefaultMQPushConsumerImpl defaultMQPushConsumerImpl;
// 消费者组名
private String consumerGroup;
// 消费类型：集群消费/广播消费
private MessageModel messageModel = MessageModel.CLUSTERING;
// 新加入的ConsumerGroup，从哪里开始消费消息？
// 只针对Broker没有消费位点的新ConsumerGroup，已经存在的消费组设置无意义。
private ConsumeFromWhere consumeFromWhere = ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET;
// 当ConsumeFromWhere设为CONSUME_FROM_TIMESTAMP时，
// 从哪个时间点开始消费？默认半小时前。
private String consumeTimestamp = UtilAll.timeMillisToHumanString3(System.currentTimeMillis() - (1000 * 60 * 30));
// 消费者分配消息的策略算法
private AllocateMessageQueueStrategy allocateMessageQueueStrategy;
// Topic订阅关系
private Map<String /* topic */, String /* sub expression */> subscription = new HashMap<String, String>();
// 消息监听器
private MessageListener messageListener;
/**
 * 消费进度管理
 * 1.集群消费:RemoteBrokerOffsetStore
 * 2.广播消费:LocalBrokerOffsetStore
 */
private OffsetStore offsetStore;
// 最小消费线程数
private int consumeThreadMin = 20;
// 最大消费线程数
private int consumeThreadMax = 20;
// 动态调整线程池，代码被删除，暂不支持，忽略。
private long adjustThreadPoolNumsThreshold = 100000;
// 并发消息的最大位点差，超过该值说明客户端消息积压较多，降低拉取速度
private int consumeConcurrentlyMaxSpan = 2000;
// 单个Queue缓存的消息阈值，达到阈值流控处理
private int pullThresholdForQueue = 1000;
// 单个Queue缓存的消息字节数阈值，单位MB
private int pullThresholdSizeForQueue = 100;
// 单个Topic缓存的消息数阈值
private int pullThresholdForTopic = -1;
// 单个Topic缓存的消息字节数阈值
private int pullThresholdSizeForTopic = -1;
// 消息拉取间隔，单位ms
private long pullInterval = 0;
// 消费者批量消费的消息数
private int consumeMessageBatchMaxSize = 1;
// 批量拉取的消息数
private int pullBatchSize = 32;
// 每次拉取消息是否更新订阅关系？
private boolean postSubscriptionWhenPull = false;
private boolean unitMode = false;
// 最大消费重试次数，默认16
private int maxReconsumeTimes = -1;
// 需要降低拉取速度时，暂停拉取的时间
private long suspendCurrentQueueTimeMillis = 1000;
// 消费超时时间，单位:分钟
private long consumeTimeout = 15;
// 关闭消费者时，等待消息消费的时间，默认不等待。
private long awaitTerminationMillisWhenShutdown = 0;
// 消息轨迹跟踪
private TraceDispatcher traceDispatcher = null;

SubscriptionData代表了消费者的订阅关系，属性如下：

// 启用Broker类过滤模式
private boolean classFilterMode = false;
// 订阅的Topic
private String topic;
// 子表达式 Tag/SQL92语法
private String subString;
// Tag集合
private Set<String> tagsSet = new HashSet<String>();
// Tag哈希集合，Broker根据Tag哈希快速过滤消息
private Set<Integer> codeSet = new HashSet<Integer>();
private long subVersion = System.currentTimeMillis();
// 表达式类型，默认是Tag，也可以用SQL92语法
private String expressionType = ExpressionType.TAG;
// 使用FilterClass过滤的源码
private String filterClassSource;

如果使用TAG的方式，会计算出Tag哈希值，Broker在ConsumeQueue索引中记录了Tag哈希，这样就可以根据Tag哈希快速过滤消息了。

订阅完Topic，就是注册消息监听MessageListener，就是一个赋值操作。

以上操作执行完，Consumer就可以启动了，接下来才是重头戏。

外观类启动的时候，会启动消费者实现类DefaultMQPushConsumerImpl，我们直接看它就好。启动主要做了以下事情：

  1. 校验消费者配置
  2. 拷贝订阅关系
  3. 创建MQClientInstance
  4. 设置RebalanceImpl
  5. 创建PullAPIWrapper，消息拉取核心类
  6. 加载消费进度(Local)
  7. 启动ConsumeMessageService
  8. 启动MQClientInstance
  9. 拉取订阅的Topic路由信息
  10. SQL表达式上传到Broker编译
  11. 给Broker发心跳，通知其他Consumer重平衡
  12. 自己重平衡,拉取消息

​

checkConfig方法，会在Consumer启动前做一系列的校验，确保服务满足启动条件，校验的事项有：

  1. 校验GroupName
  2. 校验消费模式:集群/广播
  3. 校验ConsumeFromWhere
  4. 校验开始消费的指定时间
  5. 校验AllocateMessageQueueStrategy
  6. 校验订阅关系
  7. 校验是否注册消息监听
  8. 校验消费线程数
  9. 校验单次拉取的最大消息数
  10. 校验单次消费的最大消息数
  11. 启动前校验通过，说明配置没有问题，具备启动的基本条件。

copySubscription方法会拷贝订阅关系到RebalanceImpl，Consumer在重平衡时需要用到，除了拷贝给定的Topic订阅关系，Consumer还会自动订阅ConsumerGroup的重试队列。

// 集群消费模式下，自动订阅重试Topic
final String retryTopic = MixAll.getRetryTopic(this.defaultMQPushConsumer.getConsumerGroup());
SubscriptionData subscriptionData = FilterAPI.buildSubscriptionData(retryTopic, SubscriptionData.SUB_ALL);
this.rebalanceImpl.getSubscriptionInner().put(retryTopic, subscriptionData);

创建客户端实例MQClientInstance，消息拉取核心对象PullAPIWrapper。

this.mQClientFactory = MQClientManager.getInstance().getOrCreateMQClientInstance(this.defaultMQPushConsumer, this.rpcHook);
this.pullAPIWrapper = new PullAPIWrapper(
    mQClientFactory,
    this.defaultMQPushConsumer.getConsumerGroup(), isUnitMode());
this.pullAPIWrapper.registerFilterMessageHook(filterMessageHookList);

根据消息消费模式，创建对应的OffsetStore

switch (this.defaultMQPushConsumer.getMessageModel()) {
    case BROADCASTING:
        this.offsetStore = new LocalFileOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
        break;
    case CLUSTERING:
        this.offsetStore = new RemoteBrokerOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
        break;
    default:
        break;
}
// 从磁盘恢复消费进度(Local)
this.offsetStore.load();

创建ConsumeMessageService并启动，如果是有序消息，创建ConsumeMessageOrderlyService，并发消费创建ConsumeMessageConcurrentlyService。

if (this.getMessageListenerInner() instanceof MessageListenerOrderly) {
    this.consumeOrderly = true;
    this.consumeMessageService =
        new ConsumeMessageOrderlyService(this, (MessageListenerOrderly) this.getMessageListenerInner());
} else if (this.getMessageListenerInner() instanceof MessageListenerConcurrently) {
    this.consumeOrderly = false;
    this.consumeMessageService =
        new ConsumeMessageConcurrentlyService(this, (MessageListenerConcurrently) this.getMessageListenerInner());
}
this.consumeMessageService.start();

ConsumeMessageService是一个线程池，消息拉取服务拉取到消息后，会构建ConsumeRequest对象交给线程池调度执行。

前置操作完成后，就可以启动客户端实例了。MQClientInstance启动主要做了以下事情：

  1. 发请求获取NameServerAddr
  2. 启动Netty客户端
  3. 启动各种定时任务
  4. 启动消息拉取服务
  5. 启动重均衡服务

客户端如果没有指定NameServer地址，RocketMQ会读取环境变量rocketmq.namesrv.domain，它的期望值是一个URL链接，每隔2分钟发一个请求更新NameServer地址。在集群环境下，NameServer机器数和IP都是不固定的，通过配置中心下发比硬编码更灵活。

if (null == this.clientConfig.getNamesrvAddr()) {
    // 读取环境变量，发请求更新NameServer地址
    this.mQClientAPIImpl.fetchNameServerAddr();
}

RocketMQ基于Netty来完成网络通信，Consumer作为客户端是要和Broker通信的，因此还需要启动Netty客户端。

启动各种定时任务，这些任务包括：获取NameServer地址，从NameServer拉取Topic路由信息、清理下线的Broker、给Broker发心跳、持久化消费进度。
​

启动消息拉取服务PullMessageService，它是一个单独的线程，run方法会监听阻塞队列pullRequestQueue，只要队列中有拉取请求，它就会去Broker拉取消息。

public void run() {
    while (!this.isStopped()) {
        PullRequest pullRequest = this.pullRequestQueue.take();
        this.pullMessage(pullRequest);
    }
}

启动重平衡服务RebalanceService，也是一个单独的线程，默认会每隔20秒重新做一次负载均衡，给Consumer重新分配MessageQueue。例如，TopicA下有4个MessageQueue，此时只有一个消费者实例订阅了，那么这4个MessageQueue都会分配给它消费。过了一会儿，新的消费者实例上线，此时会做一次重平衡，重新分配，因为有两个消费者实例了，因此每个实例会分配2个MessageQueue。

@Override
public void run() {
    while (!this.isStopped()) {
        // 默认20秒做一次重新负载均衡
        this.waitForRunning(waitInterval);
        this.mqClientFactory.doRebalance();
    }
}

相关服务启动完成后，Consumer会自动向NameServer拉取订阅的Topic路由信息。

private void updateTopicSubscribeInfoWhenSubscriptionChanged() {
    Map<String, SubscriptionData> subTable = this.getSubscriptionInner();
    if (subTable != null) {
        for (final Map.Entry<String, SubscriptionData> entry : subTable.entrySet()) {
            final String topic = entry.getKey();
            this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);
        }
    }
}

博文参考

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/434253.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

184基于matlab的相关向量机（RVM）回归和分类算法

184基于matlab的相关向量机（RVM）回归和分类算法

基于matlab的相关向量机&#xff08;RVM&#xff09;回归和分类算法。该算法基于贝叶斯稀疏核⽅法&#xff0c;避免了支持向量机&#xff08;SVM&#xff09;的主要局限性。RVM关键是为每个权参数 都引入一个单独的超参数 &#xff0c;而不是一个共享超参数。程序已调通&#x…
阅读更多...
和鲸科技受邀参与湖南省气象信息中心开展人工智能研究型业务支撑平台学术交流

和鲸科技受邀参与湖南省气象信息中心开展人工智能研究型业务支撑平台学术交流

为推进湖南省机器学习统一平台建设&#xff0c;2 月 29 日&#xff0c;湖南省气象信息中心开展学术讲座活动&#xff0c;活动由中心副主任冯冼主持&#xff0c;中心业务骨干、湖南省气象台、湖南分院等技术人员参加。 本次讲座邀请上海和今信息科技有限公司&#xff08;简称“…
阅读更多...
MySQL——事务

MySQL——事务

事务 2024 年 1 月字节后端实习面试&#xff1a;说说对 ACID 的理解&#xff1f; 什么是事务&#xff1f; 事务&#xff08;Transaction&#xff09;是数据库管理系统中一个执行单元&#xff08;unit of work&#xff09;&#xff0c;它由一系列的操作&#xff08;例如读取数…
阅读更多...
（文末送书）《低代码平台开发实践：基于React》

（文末送书）《低代码平台开发实践：基于React》

最近&#xff0c;我发现了一个超级强大的人工智能学习网站。它以通俗易懂的方式呈现复杂的概念&#xff0c;而且内容风趣幽默。我觉得它对大家可能会有所帮助&#xff0c;所以我在此分享。点击这里跳转到网站。 前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&am…
阅读更多...
XGboost的整理

XGboost的整理

XGboost&#xff08;extreme gradient boosting&#xff09;:高效实现了GBDT算法并进行了算法和工程上的许多改进。 XGboost的思路&#xff1a; 目标&#xff1a;建立k个回归树&#xff0c;使得树群的预测尽量接近真实值&#xff08;准确率&#xff09;而且有尽量大的泛化能力…
阅读更多...
Docker安装+基础命令

Docker安装+基础命令

一、检测、配置安装环境 &#xff08;1&#xff09;查看linux版本&#xff0c;是否符合>centos 7 &#xff08;2&#xff09;查看网络是否通畅 &#xff08;3&#xff09;安装gcc&#xff0c;gcc-c编译器 &#xff08;4&#xff09;安装device-mapper-persistent-data和lvm2…
阅读更多...
IPsec VPN协议框架

IPsec VPN协议框架

IPsec是IETF&#xff08;Internet Engineering Task Force&#xff09;制定的一组开放的网络安全协议。它并不是一个单独的协议&#xff0c;而是一系列为IP网络提供安全性的协议和服务的集合&#xff0c;包括认证头AH&#xff08;Authentication Header&#xff09;和封装安全载…
阅读更多...
LeetCode刷题---填充每个节点的下一个右侧节点指针

LeetCode刷题---填充每个节点的下一个右侧节点指针

官方题解:LeetCode官方题解 解题思想: 因为是一棵满二叉树&#xff0c;所以除了叶子节点外的其他节点都有两个子节点。 可以根据每一层来依次遍历 从根节点开始&#xff0c;根节点的左子节点的next节点就指向根节点的右子节点 因为根节点的next节点为NULL&#xff0c;开始从根…
阅读更多...
C语言结构体的大小，结构体内存对齐

C语言结构体的大小，结构体内存对齐

1. 结构体的大小 在自己正真了解过之前&#xff0c;一直认为结构体的大小就是结构体内部成员大小的总和。 但当你去尝试打印结构体的大小时&#xff0c;会发现事实并非如此&#xff0c;也不会像你想的那样简单。 #include <stdio.h>struct S1 {char c1;char c2;int i;…
阅读更多...
腾讯云服务器99元一年购买入口链接

腾讯云服务器99元一年购买入口链接

腾讯云服务器99元一年购买入口链接如下&#xff0c;现在已经降价到61元一年&#xff0c;官方活动链接如下&#xff1a; 腾讯云99元服务器一年购买页面腾讯云活动汇聚了腾讯云最新的促销打折、优惠折扣等信息&#xff0c;你在这里可以找到云服务器、域名、数据库、小程序等等多种…
阅读更多...
springcloud：3.5测试慢调用熔断降级

springcloud：3.5测试慢调用熔断降级

服务提供者【test-provider8001】 Openfeign远程调用服务提供者搭建 文章地址http://t.csdnimg.cn/06iz8 相关接口 测试远程调用&#xff1a;http://localhost:8001/payment/index 服务消费者【test-consumer-resilience4j8004】 Openfeign远程调用消费者搭建 文章地址http://t…
阅读更多...
Python 系统学习总结（基础语法+函数+数据容器+文件+异常+包+面向对象）

Python 系统学习总结（基础语法+函数+数据容器+文件+异常+包+面向对象）

&#x1f525;博客主页&#xff1a; A_SHOWY&#x1f3a5;系列专栏&#xff1a;力扣刷题总结录 数据结构 云计算 数字图像处理 力扣每日一题_ 六天时间系统学习Python基础总结&#xff0c;目前不包括可视化部分&#xff0c;其他部分基本齐全&#xff0c;总结记录&#xff0…
阅读更多...
使用数据库实现增删改查

使用数据库实现增删改查

#include<myhead.h>//定义添加数据函数int do_add(sqlite3 *ppDb) {//1.准备sql语句,输入要添加的信息int add_numb; //工号char add_name[20]; //姓名char add_sex[10]; //性别double add_score; //工资printf("请输入要添加的工号:")…
阅读更多...
Android开发经典实战，Android面试题目

Android开发经典实战，Android面试题目

关于Android的近况 大家都知道&#xff0c;今年移动开发不那么火热了&#xff0c;完全没有了前两年Android开发那种火热的势头&#xff0c;如此同时&#xff0c;AI热火朝天&#xff0c;很多言论都说Android不行了。其实不光是Android&#xff0c;iOS也有类似的言论。 那么到底…
阅读更多...
[项目设计] 从零实现的高并发内存池(四)

[项目设计] 从零实现的高并发内存池(四)

&#x1f308; 博客个人主页&#xff1a;Chris在Coding &#x1f3a5; 本文所属专栏&#xff1a;[高并发内存池] ❤️ 前置学习专栏&#xff1a;[Linux学习] ⏰ 我们仍在旅途 ​ 目录 6.内存回收 6.1 ThreadCache回收内存 6.2 CentralCache回收内存 Rele…
阅读更多...
STM32CubeMX学习笔记11 ---RTC实时时钟

STM32CubeMX学习笔记11 ---RTC实时时钟

1、RTC实时时钟简介 STM32的实时时钟RTC是一个独立的定时器&#xff0c;RTC模块拥有一组连续计数的计数器&#xff0c;在相应软件配置下&#xff0c;可提供时钟日历的功能&#xff0c;修改计数器的值可以重新设置系统当前的时间和日期 RTC模块和时钟配置系统&#xff08;RCC_B…
阅读更多...
100 spring-security 中 /oauth/token 发送请求不携带参数 报错 “401 Unauthorized“

100 spring-security 中 /oauth/token 发送请求不携带参数 报错 “401 Unauthorized“

前言 最近存在这样的一个问题, 大致的复现方式是 访问 /oauth/token 接口, 然后不携带任何参数, 结果 服务器抛出了一个 "401 Unauthorized" 针对这个 401, 这里 梳理一下这个流程, 也会衍生出一些其他的问题 测试用例 客户端这边大致的情况是 构造参数, 然后发…
阅读更多...
Linux 之三：CentOS7 目录结构 和 日期及时区设置

Linux 之三：CentOS7 目录结构 和 日期及时区设置

Linux 目录 以下是对这些目录的解释&#xff1a; /bin&#xff1a;bin是Binary的缩写, 这个目录存放着最经常使用的命令。/boot&#xff1a; 这里存放的是启动Linux时使用的一些核心文件&#xff0c;包括一些连接文件以及镜像文件。/dev &#xff1a; dev是Device(设备)的缩写…
阅读更多...
[Java安全入门]二.序列化与反序列化

[Java安全入门]二.序列化与反序列化

一.概念 Serialization&#xff08;序列化&#xff09;是一种将对象以一连串的字节描述的过程&#xff1b;反序列化deserialization是一种将这些字节重建成一个对象的过程。将程序中的对象&#xff0c;放入文件中保存就是序列化&#xff0c;将文件中的字节码重新转成对象就是反…
阅读更多...
【广度优先搜索】【堆】【C++算法】407. 接雨水 II

【广度优先搜索】【堆】【C++算法】407. 接雨水 II

作者推荐 【二分查找】【C算法】378. 有序矩阵中第 K 小的元素 本文涉及知识点 广度优先搜索 堆 LeetCoce407. 接雨水 II 给你一个 m x n 的矩阵&#xff0c;其中的值均为非负整数&#xff0c;代表二维高度图每个单元的高度&#xff0c;请计算图中形状最多能接多少体积的雨…
阅读更多...
最新文章

Copyright @ 2022~2023