kafka丢数据的原因

目录

    • 背景
    • kafkaClient代码
    • 消息丢失的可能原因
      • `broker is down`
      • `RD_KAFKA_MSG_SIZE_TOO_LARGE`
      • 分区问题
      • Kafka Broker的处理能力无法跟上，可能会出现以下情况
    • Some基础知识补充

背景

采用的client是librdkafka，在producerClient Send的数据时候发现会有数据丢失，并没有到达kafka对应topic的xxx.log中。

写ut测试

kafka_config为：

{"kafka_config": {"is_async_sending": true,"kafka_consume_batch": 5000,"kafka_consume_millsec": 1000,"kafka_ip_list": ["kafka-0.kafka-headless.middlewares.svc.cluster.local"],"kafka_port": 9092,"kafka_type": "librdkafka"},"operation_logger_thread_num": 16
}

UT测试，当is_async_sending设置为false的时候，测试推送1、10、100均无问题，当推送1k-1w时，发现这一次插入的数据均丢失，也就是说send前后kafka的offset没有变化

#include "xxx/common/kafka/kafka_log_producer.h"
#include "xxx/common/kafka/kafka_log_consumer.h"
#include <glog/logging.h>
#include <gflags/gflags.h>
#include <gtest/gtest.h>
#include "common/storage/log/log_factory.h"
#include "common/config/rapidjson_helper.h"
#include "common/config/json_config_helper.h"
#include "common/error_code.h"
#include "common/config/jsonizable.h"
#include <boost/shared_ptr.hpp>
#include <gtest/gtest.h>
#include <glog/logging.h>
#include <gmock/gmock.h>using namespace std;
using namespace xxx;DEFINE_int32(total_num, 100, "导入的数据总量");
DEFINE_string(kfk_topic, "track_surveillance", "需要检查的topic");
int main(int argc, char **argv)
{int rtn;google::ParseCommandLineFlags(&argc, &argv, false);JsonConfigHelper mConfig;mConfig.Load("kfk_config.json");xxx::common::storage::kafka::KafkaClientConfig kafkaConfig;rtn = xxx::product::face_platform::fig_app_worker_helper::GetKafkaConfig(mConfig, kafkaConfig);if (rtn < 0){CHECK_RTN_LOGE_DESC(XXX_INVALID_ARGUMENT_ERROR, "GetKafkaConfig ERROR config = " + mConfig.ToString());}boost::shared_ptr<common::storage::log::ILogProducer> producer(new common::storage::kafka::KafkaLogProducer(kafkaConfig));boost::shared_ptr<common::storage::log::ILogConsumer> consumer(new common::storage::kafka::KafkaLogConsumer(kafkaConfig));// JsonConfigHelper config;// config.Load("op_log_sample.json");std::cout << "FLAGS_total_num: " << FLAGS_total_num;std::cout << "FLAGS_kfk_topic: " << FLAGS_kfk_topic;// SAMPLE dataJsonConfigHelper config;config.Load("kfk_sample_data.json");std::string data = config.ToString();std::cout << "data=" << data.c_str() << std::endl;int64_t currentOffset = 0;currentOffset = consumer->GetCurrentOffset(FLAGS_kfk_topic, 0);// 循环插入for (int i = 0; i < FLAGS_total_num; i++){xxx::common::storage::log::LogEnvelope logEnv(FLAGS_kfk_topic, 0, data);int rtn = producer->SendMessage(logEnv);std::cout << "第" << i << "轮" << std::endl;}boost::this_thread::sleep(boost::posix_time::seconds(5));int64_t tmpOffset = consumer->GetCurrentOffset(FLAGS_kfk_topic, 0);if (tmpOffset > 0 && (tmpOffset - currentOffset) == FLAGS_total_num){std::cout << "UT PASS"<< std::endl;}else{std::cout << "DIFF OFFSET = " << (tmpOffset - currentOffset) << std::endl;}return 0;

当改成同步的时候，每次推送耗时稳定在100ms，观察librdkafka的发送代码可以看出异步的话发送流程会多一个ProducerFlush流程

kafkaClient代码

// For Producer
int RdKafkaClient::Send(const std::string &topic, int partition,const std::vector<KafkaMessage> &messages)
{if (!mInitSucc){LOG(ERROR) << "Fail to Initialize";return XXX_KAFKA_FAILED_TO_SENDING_MESSAGES_ERROR;}RdkafkaTopicPtr pTopicPtr;CHECK_RTN_LOGE_OF_FUNC(GetTopic(topic, "producer", pTopicPtr));VLOG(1) << "finished getting topic for producer, topic name: " << topic;// Produce Messagefor (int i = 0; i < messages.size(); ++i){RdKafka::ErrorCode resp = mpProducer->produce(pTopicPtr.get(), partition,RdKafka::Producer::RK_MSG_COPY,const_cast<char *>(messages[i].mValue.c_str()),messages[i].mValue.size(), &messages[i].mKey, nullptr);if (resp != RdKafka::ERR_NO_ERROR){if (resp == RdKafka::ERR__QUEUE_FULL){// retry for queue fullint reservedEventsNum = mpProducer->poll(mConfigParam.produceTimeout);LOG(WARNING) << "Fail to Produce, error: " << RdKafka::err2str(resp)<< "\nWaiting for queue space, reservedEventsNum: " << reservedEventsNum;i--;continue;}LOG(ERROR) << "Fail to produce, error: " << RdKafka::err2str(resp);if (resp == RdKafka::ERR_MSG_SIZE_TOO_LARGE){LOG(ERROR) << "Message is too large, message len: " << messages[i].mValue.size();}return XXX_KAFKA_FAILED_TO_SENDING_MESSAGES_ERROR;}else{// Serve the queued callbacks waiting to be calledmpProducer->poll(0);}}if (!mConfigParam.isAsyncSending){CHECK_RTN_LOGE_OF_FUNC(ProducerFlush());}return XXX_SUCC;
}
int RdKafkaClient::ProducerFlush()
{int reservedEventsNum = 0, sumWaitTime = 0;if (mpProducer.get() == nullptr){// 现在的代码计算是用作consumer也会创建producer实例LOG(WARNING) << "This is not a producer, no need to flush producer";}elsewhile (mpProducer->outq_len() > 0){reservedEventsNum = mpProducer->poll(mConfigParam.pollTimeout);LOG_EVERY_N(INFO, 100) << "ReservedEventsNum: " << reservedEventsNum<< ", Waiting for: " << mpProducer->outq_len();sumWaitTime += mConfigParam.pollTimeout;if (sumWaitTime > mConfigParam.flushTimeout){CHECK_RTN_LOGE_DESC(XXX_UNEXPECTED_ERROR,"fail to wait all messages be sent, timeout: " << mConfigParam.flushTimeout);}}return XXX_SUCC;
}

mpProducer->outq_len():当前等待发送的消息数量

poll()方法的返回值reservedEventsNum表示处理的事件数量。

该函数通过循环调用poll()方法等待所有消息被发送和确认，以确保消息成功提交到Kafka服务器。如果在规定的等待时间内无法完成发送操作，将输出错误日志并返回错误码

消息丢失的可能原因

消息丢失可能由以下原因导致，需要从客户端到Kafka内部的各个组件进行分析：

  1. 客户端配置：首先，您应该检查客户端的配置是否正确。确保您设置了适当的参数，例如bootstrap.servers、acks和retries等。这些参数控制着消息发送的行为，错误的配置可能导致消息丢失。
    1. bootstrap.servers：这个参数指定了 Kafka 服务的地址列表，用于在 Producer 初始化时建立与 Kafka 集群的连接。如果配置错误，Producer 将无法连接到正确的 Kafka 集群，导致消息无法发送。
    2. acks：该参数指定了 Producer 在发送消息后需要收到多少个副本的确认才视为成功。可选的值包括 "all"（所有副本都确认）、"0"（不需要任何确认）和大于等于 1 的整数值（表示需要指定数量的副本确认）。如果设置得太低，可能会导致消息发送后因为网络延迟或节点故障而丢失；如果设置得太高，可能会影响性能和吞吐量。
    3. retries：该参数指定了在发生可重试的发送错误时，Producer 进行重试的次数。如果设置得太低，可能会导致消息发送失败后未经过足够多次的重试；如果设置得太高，可能会增加延迟和网络负载。
  2. 网络故障：网络问题可能导致消息丢失。当客户端无法连接到Kafka集群或与其中的某个节点断开连接时，消息可能会丢失。您可以检查网络连接并确认没有防火墙或其他网络设备阻止了消息的传输。
  3. Kafka集群状态：确认Kafka集群是否正常工作。如果集群中的某个Broker发生故障或宕机，那么在该Broker上分布的分区可能无法接收到消息。使用Kafka命令行工具或Kafka管理界面来监控集群状态，并确保所有Broker都处于正常运行状态。
  4. 分区分配策略：Kafka使用分区来存储和分发消息。如果未正确配置分区分配策略，消息可能会被发送到错误的分区中，或者分区可能无法分配给任何可用的Broker，导致消息丢失。
  5. 消息过大：如果您发送的消息超出了Kafka Broker的message.max.bytes配置值，那么消息将被拒绝并丢失。
  6. 发送速率过快：在连续发送大量消息的情况下，如果消息发送速率过快，可能会超出Kafka Broker的处理能力。这可能导致消息被丢弃或拒绝。您可以尝试控制消息发送速率，例如通过增加延迟或减少发送频率来避免过载。
  7. 异常处理：在使用librdkafka时，您应该适当处理异常情况。例如，检查消息发送结果的返回值、重试失败的消息等。没有正确处理异常可能导致消息丢失。

下面是遇到的问题：

broker is down

Kafka 打印 “broker is down” 的日志消息通常表示某个 Kafka 代理（broker）在集群中不可用或无法连接。

这种情况可能有几个原因：

  1. 代理故障：如果一个或多个 Kafka 代理发生故障，例如宕机、崩溃或网络故障，那么其他代理就可能无法与它建立连接。此时，其他代理将打印 “broker is down” 的日志消息来指示该故障代理的状态。
  2. 网络问题：Kafka 集群中的代理之间通过网络进行通信。如果代理之间的网络出现问题，如网络分区、延迟过高或丢包等，那么可能会导致某个代理被标记为不可用。这时其他代理可能会记录 “broker is down” 的日志消息。
  3. 配置错误：如果配置文件中的代理信息设置不正确，比如指定了错误的主机名或端口号，那么连接到该代理时会失败，并导致 “broker is down” 的日志消息出现。
  4. 资源不足：如果代理所在的机器资源不足，例如 CPU、内存或磁盘空间等，可能会影响代理的正常运行，并导致其他代理报告 “broker is down” 错误。

要解决 “broker is down” 的问题，可以考虑以下步骤：

  • 检查故障的代理是否真正不可用，可以尝试连接到该代理并检查其状态。
  • 检查网络是否正常，确保所有代理之间能够正常通信。
  • 确保代理的配置信息正确，并且主机名、端口号等参数与实际情况匹配。
  • 检查代理所在的机器资源是否充足，例如 CPU、内存和磁盘空间等。

RD_KAFKA_MSG_SIZE_TOO_LARGE

默认情况下，当消息大小超过message.max.bytes时，client 会返回一个RD_KAFKA_MSG_SIZE_TOO_LARGE错误码。这个错误表示消息大小超出了Broker设置的限制，并且不允许将该消息写入主题中。

message.max.bytes是Kafka Broker的一个配置参数，它用于限制单个消息的最大大小。该参数的默认值是1000000字节（1MB）

应用程序可以通过捕获此异常并采取适当的处理措施，例如拆分消息、压缩消息或增加message.max.bytes的值来适应更大的消息。

如果修改了这个值，还需要记得同步修改这几个参数：

包括replica.fetch.max.bytes和fetch.message.max.bytes

  1. replica.fetch.max.bytes：该参数用于控制副本同步时从主题分区获取数据的最大字节大小。当副本需要从主题分区中拉取数据进行同步时，如果单个消息的大小超过该参数设置的值，则副本不会拉取该消息。默认情况下，该参数的值与message.max.bytes相同。
  2. fetch.message.max.bytes：该参数用于控制消费者从Broker获取消息的最大字节大小。当消费者从主题分区中获取消息时，如果单个消息的大小超过该参数设置的值，则对应的消息将被截断，并且仅返回截断后的部分。默认情况下，该参数的值也与message.max.bytes相同。

这些参数的存在是为了限制单个消息的大小，以防止网络传输和存储负载过大，同时也可以保护系统免受恶意或异常情况下的过大消息影响。在调整这些参数时，需要综合考虑生产者、消费者和副本同步等方面的需求。

分区问题

如果未正确配置分区分配策略，可能会导致消息被发送到错误的分区中或者分区无法分配给可用的Broker，从而导致消息丢失。

librdkafka会返回一个错误码来指示问题。以下是一些常见的错误码及其含义：

  1. RD_KAFKA_RESP_ERR__UNKNOWN_PARTITION：表示未知分区错误。这个错误码通常表示Producer尝试将消息发送到不存在的分区，或者未正确配置分区分配策略，导致无法确定应该将消息发送到哪个分区。
  2. RD_KAFKA_RESP_ERR__UNKNOWN_TOPIC：表示未知主题错误。这个错误码通常表示Producer尝试将消息发送到不存在的主题，或者未正确配置主题和分区的元数据信息。
  3. RD_KAFKA_RESP_ERR__PARTITION_EOF：表示分区已达到末尾错误。这个错误码通常表示Consumer尝试从分区中读取消息，但该分区已经没有更多消息可供消费。
  4. RD_KAFKA_RESP_ERR__UNKNOWN_TOPIC_OR_PART：表示未知主题或分区错误。这个错误码通常表示Producer或Consumer尝试操作一个不存在的主题或分区。

注意分区数的设置依赖于创建主题时指定的num_partitions参数，一旦主题创建后，分区数通常是固定的，无法更改。

Kafka Broker的处理能力无法跟上，可能会出现以下情况

  1. RequestTimedOut（请求超时）：当消息发送请求无法及时得到Broker的响应时，例如由于Broker过载导致无法及时处理请求，librdkafka会返回请求超时的错误。这通常意味着消息被丢弃，因为没有及时得到Broker的确认。
  2. NotEnoughReplicas（副本不足）：在某些情况下，如果消息发送请求无法满足复制因子（replication factor）要求，例如由于可用的副本数量不足，Broker会拒绝接收消息并返回此错误。这表明消息可能会被丢弃或者在复制因子满足后重新发送。
  3. LeaderNotAvailable（无可用Leader）：如果消息发送请求的分区的Leader不可用，例如由于Leader选举正在进行或Leader所在的Broker发生故障，那么Broker会拒绝接收消息并返回此错误。这可能会导致消息被丢弃或在Leader重新恢复后重新发送。

消息发送请求为什么需要满足复制因子的要求呢？

在Kafka中，每个分区都有若干个副本（Replica），其中一个被称为Leader副本（Leader），其他副本被称为追随者副本（Follower）。Leader负责处理消息的写入和读取请求，而追随者副本则用于实现数据的冗余备份。

当消息发送请求到达Kafka Broker时，Broker会将消息写入Leader副本，并通过一定的机制将消息复制到追随者副本。只有当消息被成功写入所有指定的副本（即满足复制因子）后，Kafka才会向Producer确认消息写入成功。

复制因子可以在创建主题时进行配置，指定了要为每个分区使用多少个副本。通常，常见的复制因子值为大于1的整数，例如3或2。这意味着每个分区将在多个Broker上维护多个副本，以提供数据冗余和容错能力。

  1. 容错性：如果某个Broker或副本发生故障，仍然可以从其他副本中获取数据，保证数据的可用性和服务的连续性。
  2. 可靠性：只有当消息被成功写入所有指定的副本后，Kafka才会向Producer确认消息写入成功。这样可以确保数据在多个副本之间得到复制，防止消息丢失。
  3. 可扩展性：通过在多个Broker上维护多个副本，Kafka能够提供更高的吞吐量和并行处理能力。

需要注意的是，复制因子也会对消息发送请求的性能产生一定的影响。增加复制因子将增加消息复制和同步的开销，可能导致稍微延迟较高的写入操作。tips:设置一个奇数的复制因子可以更容易进行Leader选举

Some基础知识补充

在Kafka中，分区（Partition）、Broker和Topic是三个核心概念，并且它们之间存在着密切的关系。

  1. 分区（Partition）：分区是Kafka中数据存储和分发的基本单元。每个主题（Topic）可以被分成多个分区，每个分区是一个有序、持久化的日志流。分区允许主题的数据水平扩展和并行处理。每个分区都有一个唯一的标识符（partition ID），从0开始递增。
  2. Broker：Broker是Kafka集群中的一个节点或服务器实例。每个Broker负责管理若干个分区，并且可以接收来自Producers的消息和为Consumers提供消息数据。一个Kafka集群由多个Broker组成，它们协同工作来提供高可用性和扩展性。
  3. 主题（Topic）：主题是Kafka中数据记录的逻辑分类单元。生产者（Producers）将消息发布到特定的主题，消费者（Consumers）则从主题中读取消息进行处理。每个主题可以拥有一个或多个分区，这些分区可以分布在不同的Broker上，以实现数据的分散存储和负载均衡。

一个主题（Topic）可以由多个分区（Partition）组成，每个分区属于某个Broker，而一个Kafka集群由多个Broker组成。

在Kafka中，同一个主题的多个分区不会被强制地分布在同一个Broker上。相反，Kafka通过将不同分区均匀地分布在不同的Broker上实现负载均衡和容错性。

当创建一个新的主题并指定分区数时，Kafka会根据集群中可用的Broker数量，自动将分区分配到不同的Broker上。这样做可以确保消息在整个集群中的分散存储，并允许并行处理。

具体的分区分配策略是由Kafka的partitioner配置参数决定的。默认情况下，Kafka使用一种称为"consistent_random"的分区分配策略，它会根据Producer发送的消息键（如果有）进行计算，以确保具有相同键的消息被分配到同一个分区，而没有键的消息则随机分配到各个分区，当然也可以直接指定消息的分区id。

在分布式环境中，Kafka通过在Broker之间共享分区元数据信息来维护分区的分布情况。这样，当消费者（Consumer）需要读取消息时，它们可以根据分区元数据信息直接找到存储该分区的Broker，从而实现高效的消息传递和消费。

当创建一个新的主题并指定分区数时，Kafka会根据集群中可用的Broker数量自动将分区分配到不同的Broker上。如果主题的分区数大于可用的Broker数量，Kafka会对一些Broker进行多个分区的分配。

这种情况下，Kafka使用的是一种称为"partition reassignment"的机制。它会尽量将分区均匀地分配给可用的Broker，并确保每个Broker上承载的分区数量尽可能接近。这样可以实现负载均衡和高吞吐量。

然而，如果可用的Broker数量远远少于主题所需的分区数，那么可能无法保证每个分区都能被分配到不同的Broker上。在这种情况下，某些Broker可能需要承载多个相同主题的分区。

需要注意的是，虽然这种情况下会在一个Broker上存在多个同一主题的分区，但Kafka仍然能够正确处理消息的存储和传递。每个分区都是独立存储和维护的，Kafka可以根据分区元数据信息准确地将消息发送到目标分区，并由消费者进行消费。

Broker是以进程为单位的。在Kafka中，每个Broker都是一个独立的Kafka服务器实例，运行在单独的进程中。

一个机器上可以运行多个Broker实例，这样就可以创建一个Kafka集群。每个Broker都有一个唯一的标识符（Broker ID），用于在集群中进行识别和通信。在集群中，每个Broker负责管理若干个分区，并处理来自Producers的消息和为Consumers提供消息数据。

通过在不同的机器上运行多个Broker实例，可以实现高可用性和容错性。如果一个Broker因故障或其他原因不可用，仍然可以通过其他可用的Broker继续提供服务。此外，通过多个Broker，Kafka还能够将负载分布在不同的机器上，提供更好的吞吐量和性能。

每个Broker实例需要配置独立的端口、日志存储路径和其他相关参数，以确保它们之间的互相独立性和协作。同时，Broker之间会建立网络连接和通信，以便进行消息复制和集群管理操作，例如分区分配和Leader选举等。

总结起来，Broker是以进程为单位的，每个Broker是一个独立的Kafka服务器实例。在一个机器上可以运行多个Broker实例，形成一个Kafka集群，提供高可用性、容错性和负载均衡。

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

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Maven - 国内 Maven 镜像仓库（加速包，冲冲冲～）

Maven - 国内 Maven 镜像仓库（加速包，冲冲冲～）

<?xml version"1.0" encoding"UTF-8" ?><!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding…
阅读更多...
onclick事件的用法

onclick事件的用法

onclick 事件是一种在网页开发中用来处理用户点击操作的事件。它通常用于 HTML 元素&#xff08;如按钮、链接、图像等&#xff09;&#xff0c;以便在用户单击该元素时触发 JavaScript 函数或执行一些特定的操作。以下是 onclick 事件的用法&#xff1a; HTML 元素上的 onclic…
阅读更多...
react关于类组件this指向

react关于类组件this指向

在 React 中&#xff0c;类组件中 this 的指向和普通的 JavaScript 类相同&#xff0c;指向当前实例对象。但是&#xff0c;在事件处理函数中&#xff0c;this 的指向会有所不同。 当我们使用类组件的时候&#xff0c;事件处理函数中的 this 默认指向 undefined。为了保证 thi…
阅读更多...
一、灵动mm32单片机_开发环境的搭建(Keil)

一、灵动mm32单片机_开发环境的搭建(Keil)

1、安装Keil MDK。 略。 2、安装芯片对应的Pack包。 (1)这里以MM32F0130单片机为例。 (2)进入灵动微电子官网。上海灵动微电子股份有限公司 (3)点击“支持”→“KEILPacl”。 (3)点击下载Pack包。 (4)下载后&#xff0c;解压下载的压缩包&#xff0c;找到对应的Pack包&…
阅读更多...
【ARMv8 SIMD和浮点指令编程】NEON 通用数据处理指令——复制、反转、提取、转置...

【ARMv8 SIMD和浮点指令编程】NEON 通用数据处理指令——复制、反转、提取、转置...

NEON 通用数据处理指令包括以下指令（不限于）： • DUP 将标量复制到向量的所有向量线。 • EXT 提取。 • REV16、REV32、REV64 反转向量中的元素。 • TBL、TBX 向量表查找。 • TRN 向量转置。 • UZP、ZIP 向量交叉存取和反向交叉存取。 1 DUP (element) 将…
阅读更多...
改进YOLOv3！IA-YOLO：恶劣天气下的目标检测

改进YOLOv3！IA-YOLO：恶劣天气下的目标检测

恶劣天气条件下从低质量图像中定位目标还是极具挑战性的任务。现有的方法要么难以平衡图像增强和目标检测任务&#xff0c;要么往往忽略有利于检测的潜在信息。本文提出了一种新的图像自适应YOLO (IA-YOLO)框架&#xff0c;可以对每张图像进行自适应增强&#xff0c;以提高检测…
阅读更多...
3. t2t_vit inference

3. t2t_vit inference

前言 对vit 进行fp16推理 参考链接&#xff1a; https://github.com/open-mmlab/mmpretrain/tree/master/configs/t2t_vit run code &#xff1a; https://mmclassification.readthedocs.io/en/latest/getting_started.html#inference-and-test-a-dataset https://mmclas…
阅读更多...
PHP如何批量修改二维数组中值

PHP如何批量修改二维数组中值

每个name值加pex&#xff0c;age加5&#xff0c; 原数据&#xff1a; $data[["name">a,age>12],["name">b,age>22],["name">c,age>33],["name">d,age>44], ];实现效果 方案一、foreach引用方式 $data[["…
阅读更多...
R语言生物群落（生态）数据统计分析与绘图实践技术应用

R语言生物群落（生态）数据统计分析与绘图实践技术应用

R 语言作的开源、自由、免费等特点使其广泛应用于生物群落数据统计分析。生物群落数据多样而复杂&#xff0c;涉及众多统计分析方法。以生物群落数据分析中的最常用的统计方法回归和混合效应模型、多元统计分析技术及结构方程等数量分析方法为主线&#xff0c;通过多个来自经典…
阅读更多...
iis前端代理后台tomcat

iis前端代理后台tomcat

1)tomcat服务器配置运行好&#xff0c;服务地址位于 localhost:8080/wechat 2)iis 绑定了域名 api.abc.com 希望访问 api.abc.com/wechat时&#xff0c;实际由tomcat的服务处理; 3)iis上需要添加组件 requestRouter_amd64.msi rewrite_amd64_zh-CN.msi 4)iis进行相关配置…
阅读更多...
jvm对象内存划分

jvm对象内存划分

写此篇博客源于面试问到内存分配的细节&#xff0c;然后不明白问的是什么。回过头发现以前看过这块内容&#xff0c;只是有些印象&#xff0c;但是无法描述清楚。 额外概念了解 jvm内存空间是逻辑上连续的虚拟地址空间&#xff08;虚拟内存中的概念&#xff09;映射到物理内存…
阅读更多...
Java集成腾讯云OCR身份证识别接口

Java集成腾讯云OCR身份证识别接口

一、背景 项目用到身份证识别获取人员信息的功能&#xff0c;于是想到了腾讯云提供这样的API。在整合代码过程都很顺利&#xff0c;利用腾讯云官方SDK很快集成进来。但是在上测试环境部署时有了新的问题&#xff0c;通过Nginx代理后的环境无法访问到目标腾讯云接口&#xff0c;…
阅读更多...
腾讯云轻量应用服务器地域北京、上海和广州怎么选择比较好？

腾讯云轻量应用服务器地域北京、上海和广州怎么选择比较好？

腾讯云轻量应用服务器地域是指轻量服务器数据中心所在的地理位置&#xff0c;如上海、广州和北京等地域&#xff0c;如何选择地域&#xff1f;腾讯云百科txybk.com建议地域选择遵循就近原则&#xff0c;用户距离轻量服务器地域越近&#xff0c;网络延迟越低&#xff0c;速度就越…
阅读更多...
前端移动web高级详细解析三

前端移动web高级详细解析三

模拟移动设备&#xff0c;方便查看页面效果 屏幕分辨率 分类&#xff1a; 物理分辨率&#xff1a;硬件分辨率&#xff08;出厂设置&#xff09; 逻辑分辨率&#xff1a;软件 / 驱动设置 结论&#xff1a;制作网页参考 逻辑分辨率 视口 作用&#xff1a;显示 HTML 网页的区…
阅读更多...
目标检测YOLO实战应用案例100讲-基于无人机图像的房屋目标检测（续）

目标检测YOLO实战应用案例100讲-基于无人机图像的房屋目标检测（续）

目录 房屋目标数据集的构建 3.1 数据集的相关说明 3.2 图像的预处理 3.2.1 图像的变换与增强 <
阅读更多...
了解神经网络

了解神经网络

阅读更多...
linux 模块安装与卸载

linux 模块安装与卸载

文章目录 模块实现编译模块的 makefile编译报错解决模块编译日志自动化模块安装模块卸载配置头文件路径 模块实现 新建 my_module.c 文件 #include <linux/types.h> #include <linux/kernel.h> #include <linux/init.h> #include <linux/module.h>st…
阅读更多...
uni-app/vue 文字转语音朗读（附小程序语音识别和朗读）uniapp小程序使用文字转语音播报类似支付宝收款播报小程序语音识别和朗读）

uni-app/vue 文字转语音朗读（附小程序语音识别和朗读）uniapp小程序使用文字转语音播报类似支付宝收款播报小程序语音识别和朗读）

uni-app/vue 文字转语音朗读&#xff08;小程序语音识别和朗读&#xff09; uniapp小程序功能集合 1、uniapp小程序文字转语音播报 一、第一种方式&#xff1a;直接加语音包 固定的文本 先利用工具生成了 文本语音mp3文件&#xff0c;放入项目中&#xff0c;直接用就好了 …
阅读更多...
敏捷开发框架Scrum-概述

敏捷开发框架Scrum-概述

如果你是一个程序员&#xff0c;可能会觉得这是个程序开发框架。我开始也是这样认为的。后来学习了PMP、敏捷后&#xff0c;才知道Scrum是一个用于管理团队工作的敏捷框架。Scrum可以理解成一个团队在一段时间里完成工作的方式。这里的一段时间通常很短&#xff0c;一到两周&am…
阅读更多...
使用Terraform管理已经存在的kubernates和默认的节点池

使用Terraform管理已经存在的kubernates和默认的节点池

背景&#xff1a; 通过terraform resource "alicloud_cs_managed_kubernetes" "k8s" {...}创建集群时&#xff0c;会产生一个默认的节点池default-nodepool&#xff0c;但是如何去修改这个默认节点池的信息呢&#xff1f; 解决思路&#xff1a; 因为Ter…
阅读更多...
最新文章

Copyright @ 2022~2023