Springboot 整合 Kafka入门

最新推荐文章于 2024-03-27 17:57:11 发布
最新推荐文章于 2024-03-27 17:57:11 发布
阅读量1.1k 收藏 9
点赞数 2
分类专栏： Spring 全家桶 文章标签： kafka java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/oschina_40730821/article/details/108619389
版权

Springboot 整合 Kafka入门

kafka 简介

  1. Kafka 特点
    Kafka 最早是由 LinkedIn 公司开发一种分布式的基于发布/订阅的消息系统，之后成为 Apache 的顶级项目。主要特点如下：

  2. 同时为发布和订阅提供高吞吐量
    Kafka 的设计目标是以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对TB 级以上数据也能保证常数时间的访问性能。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条消息的传输。

  3. 消息持久化
    将消息持久化到磁盘，因此可用于批量消费，例如 ETL 以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数据丢失。

  4. 分布式
    支持 Server 间的消息分区及分布式消费，同时保证每个 partition 内的消息顺序传输。这样易于向外扩展，所有的producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。

  5. 消费消息采用 pull 模式
    消息被处理的状态是在 consumer 端维护，而不是由 server 端维护，broker 无状态，consumer 自己保存 offset。

  6. 支持 online 和 offline 的场景。
    同时支持离线数据处理和实时数据处理

kafka 基本概念

  1. Broker
    Kafka 集群中的一台或多台服务器统称为 Broker

  2. Topic
    每条发布到 Kafka 的消息都有一个类别，这个类别被称为 Topic 。（物理上不同 Topic 的消息分开存储。逻辑上一个 Topic 的消息虽然保存于一个或多个broker上，但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处）

  3. Partition
    Topic 物理上的分组，一个 Topic 可以分为多个 Partition ，每个 Partition 是一个有序的队列。Partition 中的每条消息都会被分配一个有序的 id（offset）

  4. Producer
    消息和数据的生产者，可以理解为往 Kafka 发消息的客户端

  5. Consumer
    消息和数据的消费者，可以理解为从 Kafka 取消息的客户端

  6. Consumer Group
    每个 Consumer 属于一个特定的 Consumer Group（可为每个 Consumer 指定Group Name，若不指定 Group Name 则属于默认的 Group）。 这是 Kafka 用来实现一个 Topic 消息的广播（发给所有的 Consumer ）和单播（发给任意一个 Consumer ）的手段。一个 Topic 可以有多个 Consumer Group。Topic 的消息会复制（不是真的复制，是概念上的）到所有的 Consumer Group，但每个 Consumer Group 只会把消息发给该 Consumer Group 中的一个 Consumer。如果要实现广播，只要每个 Consumer 有一个独立的 Consumer Group 就可以了。如果要实现单播只要所有的 Consumer 在同一个 Consumer Group 。用 Consumer Group 还可以将 Consumer 进行自由的分组而不需要多次发送消息到不同的 Topic 。
    group概念可以类似的必做rabbit里的queue。一个group里的消息只能被一个消费者消费。
    topic的消息会发给所有订阅的用户组。我们可以自由的根据业务定制我们的实现。

kafka 安装

docker 极速安装kafka

Springboot 整合kafka小例子

1. 新建生产者项目

导入pom依赖

   <dependency>
            <groupId>org.springframework.kafka</groupId>
            <artifactId>spring-kafka</artifactId>
   </dependency>

application.yml配置

spring:
  jackson:
    serialization:
      FAIL_ON_EMPTY_BEANS: false

  # Kafka 配置项，对应 KafkaProperties 配置类
  kafka:
    bootstrap-servers: 47.114.161.233:9991 # 指定 Kafka Broker 地址，可以设置多个，以逗号分隔
    # Kafka Producer 配置项
    producer:
      acks: 1 # 0-不应答。1-leader 应答。all-所有 leader 和 follower 应答。
      retries: 3 # 发送失败时，重试发送的次数
      key-serializer: org.apache.kafka.common.serialization.StringSerializer # 消息的 key 的序列化
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer # 消息的 value 的序列化
logging:
  level:
    org:
      springframework:
        kafka: debug # spring-kafka INFO 日志太多了，所以我们限制只打印 ERROR 级别
      apache:
        kafka: debug # kafka INFO 日志太多了，所以我们限制只打印 ERROR 级别
server:
  port: 9991

创建日志消息类，模拟发送日志对象到kafka

@Data
@NoArgsConstructor
public class Log {

    /**
     * 日志消息
     */
    String msg;

    /**
     * 日志类型
     */
    String type = "手动操作";

    /**
     * 日志时间
     */
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss",timezone = "GMT+8")
    Date date;
}

创建发送消息的controller，便于调试

@RestController
public class Provide1 {

    @Resource
    private KafkaTemplate<Object, Object> kafkaTemplate;

    /**
     * 同步发送消息 
     * @param msg
     * @return
     * @throws ExecutionException
     * @throws InterruptedException
     */
    @GetMapping("syncSend")
    public Object syncSend(String msg) throws ExecutionException, InterruptedException {
        // 创建log 消息
        Log log  = new Log();
        log.setMsg(msg);
        log.setDate(new Date());
        // 同步发送消息
        SendResult<Object, Object> logTopic = kafkaTemplate.send("logTopic", log).get();
        return logTopic;
    }


    /**
     * 异步发送消息不会等待结果
     * @param msg
     * @return
     */
    @GetMapping("asyncSend")
    public ListenableFuture<SendResult<Object, Object>> asyncSend(String msg) {
        // 创建log 消息
        Log log  = new Log();
        log.setMsg(msg);
        log.setDate(new Date());
        // 异步发送消息
        return kafkaTemplate.send("logTopic", log);
    }

}

2. 新建消费者项目

导入pom依赖

   <dependency>
            <groupId>org.springframework.kafka</groupId>
            <artifactId>spring-kafka</artifactId>
   </dependency>

消费者application.yml配置

spring:
  jackson:
    serialization:
      FAIL_ON_EMPTY_BEANS: false
  # Kafka 配置项，对应 KafkaProperties 配置类
  kafka:
    bootstrap-servers: 47.114.161.233:9991 # 指定 Kafka Broker 地址，可以设置多个，以逗号分隔
    # Kafka Consumer 配置项
    consumer:
      auto-offset-reset: earliest # 设置消费者分组最初的消费进度为 earliest 。可参考博客 https://blog.csdn.net/lishuangzhe7047/article/details/74530417 理解
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
    # Kafka Consumer Listener 监听器配置
    listener:
      missing-topics-fatal: false # 消费监听接口监听的主题不存在时，默认会报错。所以通过设置为 false ，解决报错
logging:
  level:
    org:
      springframework:
        kafka: error # spring-kafka INFO 日志太多了，所以我们限制只打印 ERROR 级别
      apache:
        kafka: error # kafka INFO 日志太多了，所以我们限制只打印 ERROR 级别
server:
  port: 9001

建立一个消费者监听类

@Component
public class Customer1 {
    private Logger logger = LoggerFactory.getLogger(getClass());

    @KafkaListener(topics = "logTopic",
            groupId = "consumer-group-logTopic-1")
    public void onMessage(String message, ConsumerRecord record) {
        logger.info("(正常)[onMessage][线程编号:{} 消息内容：{}]", Thread.currentThread().getId(), message);
    }
}

这里我们时候用的cnsumer-group为 consumer-group-logTopic-1
根据概念，我们的消息会被接受并消费一次。

3.启动两个项目测试看看

在这里插入图片描述
调用发送消息的接口。
可以观察到，消费者已经接收并消费了。

2020-09-16 13:26:53.753  INFO 30752 --- [ntainer#0-0-C-1] com.yu.customer_1.customer.Customer1     : (正常)[onMessage][线程编号:150 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 13:26:53"}]

如果再增加一个消费者2，topic想同，用户组不同

@Component
public class Customer2 {
    private Logger logger = LoggerFactory.getLogger(getClass());

    @KafkaListener(topics = "logTopic",
            groupId = "consumer-group-logTopic-2")
    public void onMessage(String message, ConsumerRecord record) {

        logger.info("[onMessage2][线程编号:{} 消息内容：{}]", Thread.currentThread().getId(), message);
    }
}

按照我们consumer-group的定义，应该两个用户组下的消费者都可以收到。

2020-09-16 16:42:02.796  INFO 40795 --- [ntainer#0-0-C-1] com.yu.customer_1.customer.Customer1     : (正常)[onMessage][线程编号:149 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 16:42:02"}]
2020-09-16 16:42:02.799  INFO 40795 --- [ntainer#2-0-C-1] com.yu.customer_1.customer.Customer2     : [onMessage2][线程编号:147 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 16:42:02"}]

Springboot kafka 消费重试和死信队列例子

我们在上面例子代码的基础上进行修改。

  • Spring-Kafka 的消费重试功能，通过实现自定义的 SeekToCurrentErrorHandler ，在 Consumer 消费消息异常的时候，进行拦截处理：
    在重试小于最大次数时，重新投递该消息给 Consumer ，让 Consumer 有机会重新消费消息，实现消费成功。
    在重试到达最大次数时，Consumer 还是消费失败时，该消息就会发送到死信队列。例如说，我们测试的 Topic 是 “logTopic” ，则其对应的死信队列的 Topic 就是 “logTopic.DLT” ，即在原有 Topic 加上 .DLT 后缀，就是其死信队列的 Topic 。

  • Spring-Kafka 提供消费重试的机制。在消息消费失败的时候，Spring-Kafka 会通过消费重试机制，重新投递该消息给Consumer ，让 Consumer 有机会重新消费消息，实现消费成功。

  • 当然，Spring-Kafka 并不会无限重新投递消息给 Consumer 重新消费，而是在默认情况下，达到 N 次重试次数时，Consumer 还是消费失败时，该消息就会进入到死信队列。

  • 死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，Spring-Kafka 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，Spring-Kafka 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

  • Spring-Kafka 将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。后续，我们可以通过对死信队列中的消息进行重发，来使得消费者实例再次进行消费。

@Configuration
public class KafkaConfig {

    @Bean
    @Primary
    public ErrorHandler kafkaErrorHandler(KafkaTemplate<?, ?> template) {
        // <1> 创建 DeadLetterPublishingRecoverer 对象  设置死信队列 默认为 toopic.DLT
        ConsumerRecordRecoverer recoverer = new DeadLetterPublishingRecoverer(template);
        // <2> 创建 FixedBackOff 对象  设置重试间隔 10秒 次数为 3次
        BackOff backOff = new FixedBackOff(10 * 1000L, 3L);
        // <3> 创建 SeekToCurrentErrorHandler 对象
        return new SeekToCurrentErrorHandler(recoverer, backOff);
    }
}
  • <1> 处，创建DeadLetterPublishingRecoverer对象，它负责实现，在重试到达最大次数时，Consumer 还是消费失败时，该消息就会发送到死信队列。
  • <2> 处，创建 FixedBackOff 对象。这里，我们配置了重试 3 次，每次固定间隔 30 秒。当然，胖友可以选择 BackOff 的另一个子类 ExponentialBackOff 实现，提供指数递增的间隔时间。
  • <3> 处，创建 SeekToCurrentErrorHandler对象，负责处理异常，串联整个消费重试的整个过程。

这里，我们来简单说说 SeekToCurrentErrorHandler 是怎么提供消费重试的功能的。

在消息消费失败时，SeekToCurrentErrorHandler会将 调用 Kafka Consumer 的 #seek(TopicPartition partition, long offset) 方法，将 Consumer 对于该消息对应的 TopicPartition 分区的本地进度设置成该消息的位置。这样，Consumer 在下次从 Kafka Broker 拉取消息的时候，又能重新拉取到这条消费失败的消息，并且是第一条。
同时，Spring-Kafka 使用 FailedRecordTracker对每个 Topic 的每个 TopicPartition 消费失败次数进行计数，这样相当于对该 TopicPartition 的第一条消费失败的消息的消费失败次数进行计数。😈 这里，胖友好好思考下，结合艿艿在上一点的描述。
另外，在 FailedRecordTracker 中，会调用 BackOff 来进行计算，该消息的下一次重新消费的时间，通过 Thread#sleep(...) 方法，实现重新消费的时间间隔。

有一点需要注意，FailedRecordTracker 提供的计数是客户端级别的，重启 JVM 应用后，计数是会丢失的。所以，如果想要计数进行持久化，需要自己重新实现下 FailedRecordTracker 类，通过 ZooKeeper 存储计数。

RocketMQ 提供的消费重试的计数，目前是服务端级别，已经进行持久化。

对了，SeekToCurrentErrorHandler 是只针对消息的单条消费失败的消费重试处理。如果胖友想要有消息的批量消费失败的消费重试处理，可以使用 SeekToCurrentBatchErrorHandler 。

我们设计一个死信队列的消费者

@Component
public class Customer1DLT {
    private Logger logger = LoggerFactory.getLogger(getClass());

    @KafkaListener(topics = "logTopic.DLT",
            groupId = "consumer-group-logTopic-1")
    public void onMessage(String message, ConsumerRecord record) {
        logger.info("（死信队列）[onMessage][线程编号:{} 消息内容：{}]", Thread.currentThread().getId(), message);
    }
}

在原有的消费者中加入异常

@Component
public class Customer1 {
    private Logger logger = LoggerFactory.getLogger(getClass());

    @KafkaListener(topics = "logTopic",
            groupId = "consumer-group-logTopic-1")
    public void onMessage(String message, ConsumerRecord record) {
        logger.info("(正常)[onMessage][线程编号:{} 消息内容：{}]", Thread.currentThread().getId(), message);
        throw new RuntimeException("我是个异常");
    }
}

接下来，启动生产者发送消息查看消费情况

2020-09-16 20:58:25.416  INFO com.yu.customer_1.customer.Customer1     : (正常)[onMessage][线程编号:149 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 20:58:25"}]
2020-09-16 20:58:35.420 ERROR 51441  essageListenerContainer$ListenerConsumer : Error handler threw an exception
2020-09-16 20:58:35.449  INFO 51441 com.yu.customer_1.customer.Customer1     : (正常)[onMessage][线程编号:149 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 20:58:25"}]
2020-09-16 20:58:45.453 ERROR 51441  essageListenerContainer$ListenerConsumer : Error handler threw an exception
2020-09-16 20:58:45.481  INFO 51441 com.yu.customer_1.customer.Customer1     : (正常)[onMessage][线程编号:149 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 20:58:25"}]
2020-09-16 20:58:55.488 ERROR 51441  essageListenerContainer$ListenerConsumer : Error handler threw an exception
2020-09-16 20:58:55.517  INFO 51441  com.yu.customer_1.customer.Customer1     : (正常)[onMessage][线程编号:149 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 20:58:25"}]
2020-09-16 20:58:55.553  INFO 51441  com.yu.customer_1.customer.Customer1DLT  : （死信队列）[onMessage][线程编号:151 消息内容：{"msg":"demoData","type":"手动操作","date":"2020-09-16 20:58:25"}]

通过观察日志可以看到 ，正常的消费者重试消费3次，并且间隔为10秒，后来被转发到死信队列，被死信队列的消费者所消费。

参考 http://www.iocoder.cn/Spring-Boot/Kafka/?self

Kafka 高吞吐量的秘诀

消息中间件从功能上看就是写入数据、读取数据两大类，优化也可以从这两方面来看。

为了优化写入速度 Kafak 采用以下技术：

  1. 顺序写入
    磁盘大多数都还是机械结构（SSD不在讨论的范围内），如果将消息以随机写的方式存入磁盘，就需要按柱面、磁头、扇区的方式寻址，缓慢的机械运动（相对内存）会消耗大量时间，导致磁盘的写入速度与内存写入速度差好几个数量级。为了规避随机写带来的时间消耗，Kafka 采取了顺序写的方式存储数据，如下图所示：
    在这里插入图片描述
  • 每条消息都被append 到该 partition 中，属于顺序写磁盘，因此效率非常高。 但这种方法有一个缺陷：没有办法删除数据。所以Kafka是不会删除数据的，它会把所有的数据都保留下来，每个消费者（Consumer）对每个 Topic 都有一个 offset 用来表示读取到了第几条数据。

消费消息

  • 上图中有两个消费者，Consumer1 有两个 offset 分别对应 Partition0、Partition1（假设每一个 Topic 一个 Partition ）。Consumer2 有一个 offset 对应Partition2 。这个 offset 是由客户端 SDK 保存的，Kafka 的 Broker 完全无视这个东西的存在，一般情况下 SDK 会把它保存到 zookeeper 里面。 如果不删除消息，硬盘肯定会被撑满，所以 Kakfa 提供了两种策略来删除数据。一是基于时间，二是基于 partition 文件大小，具体配置可以参看它的配置文档。 即使是顺序写，过于频繁的大量小 I/O 操作一样会造成磁盘的瓶颈，所以 Kakfa 在此处的处理是把这些消息集合在一起批量发送，这样减少对磁盘 I/O 的过度操作，而不是一次发送单个消息。

  1. 内存映射文件
    即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以 Kafka 的数据并不是实时的写入硬盘，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。Memory Mapped Files （后面简称mmap）也被翻译成内存映射文件，在64位操作系统中一般可以表示 20G 的数据文件，它的工作原理是直接利用操作系统的 Page 来实现文件到物理内存的直接映射。完成映射之后对物理内存的操作会被同步到硬盘上（由操作系统在适当的时候）。 通过 mmap 进程像读写硬盘一样读写内存，也不必关心内存的大小，有虚拟内存为我们兜底。使用这种方式可以获取很大的 I/O 提升，因为它省去了用户空间到内核空间复制的开销（调用文件的 read 函数会把数据先放到内核空间的内存中，然后再复制到用户空间的内存中） 但这样也有一个很明显的缺陷——不可靠，写到 mmap 中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用 flush 的时候才把数据真正的写到硬盘。所以 Kafka 提供了一个参数—— producer.type 来控制是不是主动 flush，如果Kafka 写入到 mmap 之后就立即 flush 然后再返回 Producer 叫同步(sync)；如果写入 mmap 之后立即返回，Producer 不调用 flush ，就叫异步(async)。

  2. 标准化二进制消息格式
    为了避免无效率的字节复制，尤其是在负载比较高的情况下影响是显著的。为了避免这种情况，Kafka 采用由 Producer，Broker 和 Consumer 共享的标准化二进制消息格式，这样数据块就可以在它们之间自由传输，无需转换，降低了字节复制的成本开销。

而在读取速度的优化上 Kafak 采取的主要是零拷贝

  • 零拷贝（Zero Copy）的技术：
    传统模式下我们从硬盘读取一个文件是这样的
    文件传输到 Socket 的常规方式

  1. 操作系统将数据从磁盘读到内核空间的页缓存区

  2. 应用将数据从内核空间读到用户空间的缓存中

  3. 应用将数据写会内核空间的套接字缓存中

  4. 操作系统将数据从套接字缓存写到网卡缓存中，以便将数据经网络发出

  • 这样做明显是低效的，这里有四次拷贝，两次系统调用。 针对这种情况 Unix 操作系统提供了一个优化的路径，用于将数据从页缓存区传输到 socket。在 Linux 中，是通过 sendfile 系统调用来完成的。Java提供了访问这个系统调用的方法：FileChannel.transferTo API。这种方式只需要一次拷贝：操作系统将数据直接从页缓存发送到网络上，在这个优化的路径中，只有最后一步将数据拷贝到网卡缓存中是需要的。
    零拷贝方式传输到 Socket

这个技术其实非常普遍，The C10K problem 里面也有很详细的介绍，Nginx 也是用的这种技术，稍微搜一下就能找到很多资料。

Kafka 速度的秘诀在于它把所有的消息都变成一个的文件。通过 mmap 提高 I/O 的速度，写入数据的时候是末尾添加所以速度最优；读取数据的时候配合sendfile 直接暴力输出。所以单纯的去测试 MQ 的速度没有任何意义，Kafka 的这种暴力的做法已经脱了 MQ 的底裤，更像是一个暴力的数据传送器。

大米饭66
关注
专栏目录
Kafka系列之：Dead Letter Queue死信队列DLQ
zhengzaifeidelushang的博客
08-14 344
当设置errors.deadletterqueue.context.headers.enable参数为true时，记录头将被添加到DLQ中——默认值为false。然后，可以使用kcat（以前称为kafkacat）实用程序，用于Confluent Platform查看记录头并确定记录失败的原因。要确定记录是否失败，必须使用内部度量标准，或计算源中的记录数并将其与处理的记录数进行比较。当errors.tolerance设置为none时，错误或无效记录会导致连接器任务立即失败，并将连接器置于失败状态。
【项目实战】SpringBoot整合Kafka消息队列（基于KafkaTemplate和@KafkaListener实现）
本本本添哥
01-04 5984
SpringBoot整合Kafka消息队列（基于KafkaTemplate和@KafkaListener实现）
SpringBoot整合kafka的使用
last_TrobleMaker的博客
01-19 347
在处理信息中，要使用异步消息队列，要搭建消息中间件。kafka作为一个快捷方便且成熟的中间件，对异步处理的能力还是很好的。 如何在SpringBoot中整合kafka呢，首先要引入kafka的依赖 <!--kafka配置--> <dependency> <groupId>org.springframework.kafk...
kafka SeekToCurrentErrorHandler过时
最新发布
zerolbsony的博客
03-27 454
Upgrading from SeekToCurrentErrorHandler to DefaultErrorHandler in Spring KafkaSeekToCurrentErrorHandler (Spring Kafka 2.4.12.RELEASE API)
IBMMQ消息队列整合
04-24
java IBM消息队列整合
python redis 模块 官方文档(中)
weixin_33785108的博客
04-29 766
2019独角兽企业重金招聘Python工程师标准>>> ...
python redis 模块 官方文档(上)
weixin_34234823的博客
04-29 702
2019独角兽企业重金招聘Python工程师标准>>> ...
python redis模块使用文档
wanzheng_96的博客
07-09 1248
官方手册 安装 源码安装最新版 redis-py 3.x（推荐） 下载地址 https://github.com/andymccurdy/redis-py/releases 解压，cd python setup.py install 或者 pip install redis 可能落后几个版本，redis 2.x 和 3.x 参数差异较多，使用 2.x 时，根据下文介绍注意区别 Gettin...
pyflink 读取kafka
zhaoyangjian724的专栏
06-12 1175
"enable.auto.commit": "false", # 关闭kafka 自动提交，此处不能传bool 类型会报错。).name(f"消费{TEST_KAFKA_TOPIC}主题数据")# 创建 StreamExecutionEnvironment 对象。
【微服务】springboot整合kafka-stream使用详解
热门推荐
congge
12-24 1万+
kafka stream使用详解
springboot集成kafka简单入门案例
06-13
这只是一个简单的入门案例，实际上Kafka和Spring Boot的整合功能远不止这些。例如，您可以配置多个主题、设置消费者分组、实现幂等性消费者、处理异常、使用Kafka Streams进行复杂的数据处理等。随着对Kafka和Spring...
springboot 整合消息队列kafka(kafka-with-springboot.rar)
08-19
这只是一个基础的Spring Boot整合Kafka的示例，实际上，Kafka支持更复杂的消息模式，如键值对、批处理、事务以及错误处理等。 此外，Kafka还提供了一个高可用性和容错性的特性，例如副本和分区，确保数据的可靠传输...
10分钟入门响应式:Springboot整合kafka实现reactive
m0_73088370的博客
08-24 734
Springboot引入Reactor已经有一段时间了，笔者潜伏在各种技术群里暗中观察发现，好像scala圈子的同仁们，似乎对响应式更热衷一点。也许是因为他们对fp理解的更深吧，所以领悟起来障碍性更少一些的原因吧。尽管webflux对于数据库的支持，还不那么完善，也不妨我们试上一试。首先请允许我引用全部的反应式宣言作为开篇，接下来会介绍webflux整合kafka做一个demo。在不同领域中深耕的组织都在不约而同地尝试发现相似的软件构建模式。希望这些系统会更健壮、更具回弹性 、更灵活，也能更好地满足现代化的
RocketMQ消息监听
weixin_43133012的博客
12-07 3379
定义生产者 初始化生产者 //消息监听处理完业务后，必须手动ACK消息，不然会重复消费，直到放入死信队列 DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(); consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public ConsumeConcurrentlyStatus consumeMessage(Li.
RocketMQ监听代码小记
feier352的博客
01-07 305
RocketMQ 消费者监听模型 解析——图解、源码级解析
如切如磋，如琢如磨
09-02 3141
文章目录 前面已经把RocketMQ发送消息的主要流程梳理了一遍，接下来我将介绍消费者消费消息的源码及流程，主要包含但不仅限于一下内容： 消息消费模式 消息消费的流程 消费者负载均衡算法 消费失败如何进行重试 消息如何进行重新投递 ...
消息队列MQ（Message Queue）及IBM MQ的安装和配置
weixin_42560974的博客
02-28 528
MQ（Message Queue）消息队列，是基础数据结构中“先进先出”的一种数据结构。指把要传输的数据（消息）放在队列中，用队列机制来实现消息传递——生产者产生消息并把消息放入队列，然后由消费者去处理。消费者可以到指定队列拉取消息，或者订阅相应的队列，由MQ服务端给其推送消息。
python redis 模块操作详解
爱死亡机器人
07-25 843
1. 简介 redis 是一个 Key-Value 数据库，Value 支持 string(字符串)，list(列表)，set(集合)，zset(有序集合)，hash(哈希类型)等类型。默认端口号为 6379 2. 安装 redis 模块 sudo pip3 install redis 或 sudo easy_install redis 或 sudo python setup.py install 源码地址：https://github.com/WoLpH/redis-py 测试是否安装成功： >&
kafka使用_当Flink遇到Kafka - FlinkKafkaConsumer使用详解
weixin_39710951的博客
12-03 5718
Flink是新一代的流处理计算引擎。通过轻量级的checkpoint，Flink可以在高吞吐量的情况下保证exactly-once(这需要数据源能够提供回溯消费的能力)。Flink支持众多的source(从中读取数据)和sink(向其写入数据)，列表如下：Kafka作为目前非常流行的消息中间件，它不仅能够提供极大的吞吐量，还能够配合Flink在消费端达到exactly-once。本文将详细介绍如何...
Springboot整合Kafka实现消息通信详解
"本文档详细介绍了如何使用Springboot整合Kafka进行消息通信，涵盖了Kafka的基本原理、应用搭建、主题与死信主题、多线程消费者、分区策略、日志刷新配置、批量消息处理、Springboot中的Kafka事务、可视化工具以及...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值