使用java在kafka中传输单条大于1M的数据

最新推荐文章于 2025-04-22 19:04:56 发布
转载 最新推荐文章于 2025-04-22 19:04:56 发布 · 2k 阅读 · 8 ·
CC 4.0 BY-SA版权
原文链接：https://blog.youkuaiyun.com/qq_35803514/article/details/88848852
文章标签：

#kafka

用久了kafka，我们都知道，在kafka的默认配置下，限制了数据传输的大小（默认情况下为1M），那么但我们需要单次传输超过1M的数据时，我们究竟该如何修改kafka的配置，让我们能够正常使用呢？这是本文即将要阐述的内容。

一.修改kafka的配置文件

​ 既然kafka默认配置是1M，那我们就来修改kafka的配置文件，让它能够支持我们传输超1M的数据，我们需要修改以下的三个配置文件:

①修改kafka安装目录下的conf/server.properties

         这里我们需要添加以下的两个内容

              message.max.bytes=10485760

                  #该值指的是broker能接收消息的最大字节数，这里我设置的是10M,该值的大小需 比replica.fetch.max.bytes的值小

               replica.fetch.max.bytes=11534336

                  #broker可复制的消息的最大字节数，这里我设置的是11M，小于message.max.bytes会导致数据发布出去

②修改kafka安装目录下的conf/producer.properties

         这里我们需要修改以下的一处内容

              max.request.size=10485760

                  #该值指请求的最大大小为字节。要不大于上述的message.max.bytes
③修改kafka安装目录下的conf/consumer.properties
	这里我们需要修改以下的一处内容

              max.partition.fetch.bytes=10485760

                  #该值指一次fetch请求，从一个partition中取得的records最大大小。要不大于上述的message.max.bytes

通过上述的一些配置，我们的kafka应用服务器已经可以成功的传输超过1M的数据了。但是在我们的java端，依旧不能传输超过1M的数据，我们还需要对我们的java代码进行下修改

二.修改java程序中kafka参数的配置

①修改java程序中生产者的参数配置

    修改java程序代码中kafka的producer的服务配置

    设置max.request.size为10485760

    设置compression.type为gzip

②修改java程序中消费者的参数配置

    设置max.partition.fetch.bytes设置为11534336

到这里为止，kafka就能够成功的传输数据量为10M的数据了。

【Flink】kafka INVALID_PRODUCER_EPO send data to Kafka old epoch newer producer same transactionalId
九师兄
04-22 887
1.场景1 网友的一个问题。flink可不可以一个流进行多种处理，比如从一个kafka读出数据，进行订单的按日统计，按小时统计，再按人统计，实际上我想要输出的是多条，例如说每小时的GMV统计是一个输出保存到redis，按日统计的又是一个输出保存在redis 比如如下代码 我自己跑的时候也觉着没问题，现在测试的时候老是不断重启，总是报kafka Producer attempted an operation with an old epoch. ......
【技海登峰】Kafka漫谈系列（三）详解Kafka的数据结构与存储机制
这里是阿安的博客
03-02 371
【技海登峰】Kafka漫谈系列（三）详解Kafka的数据结构与存储机制：本文主要介绍了Kafka用来持久化保存数据的消息日志（Log）机制，包括 log、index、timeindex 三种核心存储结构。
使用JAVA在KAKFA中传输单条大于1M的数据
qq_35803514的博客
04-17 2419
用久了kafka，我们都知道，在kafka的默认配置下，限制了数据传输的大小（默认情况下为1M），那么但我们需要单次传输超过1M的数据时，我们究竟该如何修改kafka的配置，让我们能够正常使用呢？这是本文即将要阐述的内容。 一.修改kafka的配置文件 既然kafka默认配置是1M，那我们就来修改kafka的配置文件，让它能够支持我们传输超1M的数据，我们需要修改以下的三...
kafka09-1M以上消息的发送、存储以及消费
m0_63833709的博客
07-07 1039
由于Kafka不直接支持发送大型消息，需要自定义生产者来处理消息的上传和发送引用，以及消费者来处理从Kafka接收引用并从外部存储中检索原始数据。
Kafka：解决单条日志大于 1m
程序员无羡的博客
04-06 1209
Kafka：解决单条日志大于 1m
Kafka单条日志传输大小探究
mischen520的博客
09-11 3077
Kafka对于消息体的大小默认为单条最大值是1M但是在我们应用场景中，常常会出现一条消息大于1M，如果不对Kafka进行配置。则会出现生产者无法将消息推送到Kafka或消费者无法去消费Kafka里面的数据，这时我们就要对Kafka进行以下配置：server.properties replica.fetch.max.bytes: 1048576 broker可复制的消息的最大字节数, 默认为1M message.max.bytes: 1000012 kafka 会接收单个消息size的最大限制， 默认为
Java操作Kafka
06-23 4686
Kafka的介绍 Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 Kafka 有如下特性： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 Scale out：支持在
大厂消息中间件高频面试题与知识点整理（RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ）
热门推荐
张彦峰的博客
04-07 172万+
互联网高频面试之消息中间件基本问题和知识点整理分析
大数据领域Kafka在教育科技数据处理中的应用
AI天才研究院
04-22 1037
教育科技（EdTech）的数字化转型催生了海量数据：在线课程的播放记录、学生作业提交行为、智能硬件的课堂互动数据、教学管理系统的日志等。这些数据具有高并发（峰值数万条/秒）多源异构（Web/APP/IoT）、**实时性需求（如课堂互动即时反馈）**等特点。传统数据处理架构（如关系型数据库直写、日志文件定期汇总）已无法满足吞吐量、延迟和可靠性要求。本文聚焦Kafka在教育科技数据处理中的核心价值与实践方法Kafka适配教育数据特性的架构设计教育场景下的Kafka集群部署与调优。
kafka写入消息超过1M的解决办法
langmeng110的博客
02-23 1187
【代码】kafka写入消息超过1M的解决办法。
java创建一个内存10M的对象_JVM之内存和对象创建过程
weixin_35710050的博客
02-24 1129
1.5.3多核并行Lambda支持会极大改善目前Java语言不适合函数式编程的现状.函数式编程的一个重要优点就是天然适合并行运行.2.2.1程序计数器(每条线程独立私有)程序计数器是一块较小的内存空间，它可以看做是当前线程所执行的字节码的行号指示器字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支 循环 跳转 异常处理 线程恢复等基础功能都需要依赖这个计数器来完成j...
java虚拟机内存分布_Java虚拟机详解（六）------内存分配
weixin_35399360的博客
02-13 212
我们说Java是自动进行内存管理的，所谓自动化就是，不需要程序员操心，Java会自动进行内存分配和内存回收这两方面。前面我们介绍过如何通过垃圾回收器来回收内存，那么本篇博客我们来聊聊如何进行分配内存。对象的内存分配，往大方向上讲，就是堆上进行分配(但也有可能经过JIT编译后被拆散为标量类型并间接的在栈上分配)，对象主要分配在新生代 Eden 区上，如果启动了本地线程分配缓冲，将按线程优先在 TLA...
关于kafka发送消息过大导致的异常的解决方式
qq_34409900的博客
05-29 6182
在kafka发送消息的时候，如果消息过大超过了max.request.size的默认大小（1M），就会报下面的异常： 这个时候我们如果单独调整max.request.size参数的大小可能不起作用，因为在broker端和consumer端同样对消息的大小存在限制，我们在调整的时候要同时调整这三个参数，不然可能是broker接受不了producter端的消息，要不就是consumer端消费不了消息。调整如下： producer端： max.request.size=5242880（5M） broke
java值byte类型长度超出
baicp3的专栏
06-22 1486
本人遇到的问题是mysql字段定义的是tinyint(3) unsigned 对应的java里面的是byte。 一、遇到的问题是这样的： [RemoteTestNG] detected TestNG version 6.9.10 log4j: Parsing for [root] with value=[DEBUG,D,E,stepLog]. log4j: Level token is [DEBUG]. log4j: Category root set to DEBUG log4j: Parsing..
19-kafka单条日志传输大小
huaxing_ba的博客
05-29 2289
题目：kafka单条日志传输大小 答案： kafka对于消息体的大小默认单条最大值是1M。但是在我们应用场景中，常常会出现一条消息大于1M，如果不对kafka进行配置，则会出现生产者无法将消息推送到kafka或者消费者无法去消费kafka里面的数据，这时我们就要对kafka进行如下配置：server.properties 注意：message.max.bytes必须小于等于replica.fetch.max.bytes，否则就会导致replica之间数据同步失败。 ...
关于使用kafka时对于大数据消息体是遇到的问题
weixin_34326429的博客
04-26 886
kafka对于消息体的大小默认为单条最大值是1M. 但是在我们应用场景中, 常常会出现一条消息大于1M, 如果不对kafka进行配置. 则会出现生产者无法将消息推送到kafka或消费者无法去消费kafka里面的数据, 这是我们就要对kafka进行以下配置: 1. 在consumer.properties配置文件中添加：fetch.message.max.bytes : 每个提取请求...
byte java 比较大小_java byte最大值最小值问题
weixin_36454202的博客
02-12 1963
1.计算机编码1.1 原码、反码和补码在计算机内，定点数有3种表示法：原码、反码和补码。原码：就是二进制定点表示法，即最高位为符号位，“0”表示正，“1”表示负，其余位表示数值的大小。反码：表示法规定：正数的反码与其原码相同；负数的反码是对其原码逐位取反，但符号位除外。补码：表示法规定：正数的补码与其原码相同；负数的补码是在其反码的末位加1。原码、反码不能直接进行数值计算。1.2 计算机数值存储在...
使用Flink处理Kafka中的数据
2301_77578187的博客
01-22 1637
使用Flink处理Kafka中的数据
kafka支持大数据传输
能量守恒洛的专栏
03-26 3545
kafka对于消息体的大小默认为单条最大值是1M. 但是在我们应用场景中, 常常会出现一条消息大于1M, 如果不对kafka进行配置. 则会出现生产者无法将消息推送到kafka或消费者无法去消费kafka里面的数据, 这时我们就要对kafka进行以下配置: kafka_2.11-0.9.0.0/config/server.properties Producer的参数中添加：max.requ...
kafka监听用户退出信息实现单点登出，并基于redis的订阅发布同步内存数据
最新发布
08-07
<think>我们结合Kafka和Redis来实现单点登出功能，具体思路如下： 1. 用户退出时，业务系统发布一个退出事件到Kafka的特定主题（例如：user_logout_topic） 2. 各个微服务实例（或集群中的各个节点）都消费这个Kafka主题，当消费到退出事件时，在服务内部通过Redis发布订阅机制通知本节点清理用户相关的内存数据（如会话信息） 3. 每个服务节点都订阅一个Redis频道（例如：user_logout_channel），当收到该频道的消息时，执行本地内存清理操作 为什么需要两层消息传递（Kafka+Redis）？ - Kafka用于保证退出事件的可靠传递和持久化，即使服务重启也能重新消费事件。 - Redis的发布订阅用于实时通知同一服务内的所有节点（因为Redis订阅是实时的，且在同一服务内节点共享同一个频道），实现内存数据的快速清理。 具体步骤： 步骤1：用户退出时，业务系统向Kafka发送退出事件 事件内容可以包括用户ID、退出时间等。 步骤2：每个微服务实例（节点）启动一个Kafka消费者，持续消费user_logout_topic 当消费到退出事件时，该节点向Redis的user_logout_channel频道发布一条消息（消息内容同样包含用户ID）。 步骤3：每个微服务实例（节点）在启动时订阅Redis的user_logout_channel频道 当收到该频道的消息时，触发本地内存清理操作（例如：清除该用户的会话缓存、权限信息等）。 注意：每个服务节点既是Redis频道的发布者（当消费到Kafka消息时发布），也是订阅者（订阅该频道以接收清理通知）。 为什么不在消费Kafka消息后直接清理本地内存？ 因为一个微服务可能有多个实例（节点），Kafka的一个分区只能被一个消费者实例（同一消费者组）消费。如果多个服务实例属于同一个Kafka消费者组，那么一个退出事件只会被一个服务实例消费到。但我们需要所有服务实例都清理内存，所以需要通过Redis的发布订阅机制广播给所有实例。 架构图： 用户退出 --> 业务系统发布事件到Kafka --> 每个服务实例的Kafka消费者消费事件 --> 服务实例向Redis频道发布消息 --> 所有服务实例（包括发布者自身）收到Redis消息 --> 清理本地内存 代码示例（伪代码）： 1. Kafka消费者处理（每个服务实例中）： ```java // 初始化Kafka消费者，订阅user_logout_topic KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList("user_logout_topic")); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100)); for (ConsumerRecord<String, String> record : records) { // 解析退出事件 String userId = record.value(); // 假设消息体就是用户ID // 向Redis发布消息 jedis.publish("user_logout_channel", userId); } } ``` 2. Redis订阅处理（每个服务实例中）： ```java // 初始化Redis订阅 new Thread(() -> { Jedis jedis = new Jedis("redis-host", 6379); jedis.subscribe(new JedisPubSub() { @Override public void onMessage(String channel, String message) { // 收到退出消息，清理本地内存 if ("user_logout_channel".equals(channel)) { String userId = message; // 清理该用户相关的内存数据 localSessionCache.remove(userId); } } }, "user_logout_channel"); }).start(); ``` 注意事项： - Redis的发布订阅不保证可靠性：如果某个服务实例在消息发布时刚好断开连接，那么它可能错过消息。因此，我们还需要其他机制来保证数据一致性（例如：使用本地缓存过期时间，或者定期同步）。 - Kafka的消费位置管理：要确保每个服务实例都能正确消费Kafka消息，建议每个服务实例使用不同的消费者组（或者同一个消费者组但每个实例分配不同的分区，但这样需要分区数足够），但这里每个实例都需要消费所有消息，所以应该使用不同的消费者组，或者使用一个消费者组但主题只有一个分区（这样只有一个实例能消费到，然后通过Redis广播）。这里我们选择让每个服务实例都使用同一个消费者组，但将主题的分区数设置为大于等于服务实例数，这样每个实例都能分到分区，从而都能消费到消息（但每个消息只被一个实例消费）。但是，我们要求每个实例都执行清理，所以需要广播。因此，我们让每个服务实例使用不同的消费者组，这样每个实例都能独立消费到完整的退出事件。但这样会重复消费，所以需要主题支持多组订阅。 更优方案：为了避免每个服务实例都消费Kafka消息（增加Kafka压力），我们可以让一个专门的消费者服务（可以是单独的服务，也可以嵌入在业务服务中，但只有一个实例）来消费Kafka的退出事件，然后由这个服务通过Redis发布消息。但这样会引入单点问题。因此，我们采用原方案：每个服务实例都消费Kafka退出事件（使用不同的消费者组），然后发布到Redis，再通过Redis广播到所有实例（包括自己）。 但是，如果服务实例很多，每个退出事件会被重复消费（每个实例都消费一次）并发布多次相同的消息到Redis（同一个频道，每个实例都会发布一次），这会导致重复的清理操作。所以我们需要优化： 优化方案：每个服务实例在消费Kafka消息后，只发布一次Redis消息，并且确保所有实例（包括自己）都能收到。但Redis的发布订阅是广播，所以同一个频道的消息会被所有订阅者收到。因此，我们让每个服务实例都订阅同一个频道，但每个实例在消费Kafka消息后只发布一次。这样，一个退出事件会被每个服务实例消费一次（因为每个实例都是不同的消费者组），然后每个实例都会发布一次相同的消息，导致重复发布。为了避免重复发布，我们可以只让其中一个实例发布，但无法简单确定哪个实例发布。 因此，我们调整：只让其中一个服务实例负责消费Kafka消息并发布到Redis。我们可以创建一个独立的服务（比如：logout-event-broadcaster）专门负责消费Kafka的退出事件，然后发布到Redis。这样，每个业务服务实例只需要订阅Redis频道即可。这样避免了重复发布，且职责清晰。 架构调整为： 用户退出 --> 业务系统发布事件到Kafka --> 独立的广播服务（logout-event-broadcaster）消费事件 --> 广播服务向Redis频道发布消息 --> 所有业务服务实例收到Redis消息 --> 清理本地内存 这样，业务服务实例只需要订阅Redis频道，不需要消费Kafka。广播服务可以部署多个实例，但需要保证Kafka消息只被消费一次（使用同一个消费者组，分区分配）。广播服务也可以做成高可用的。 代码调整： 广播服务（logout-event-broadcaster）： ```java // Kafka消费者（使用一个消费者组） KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList("user_logout_topic")); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100)); for (ConsumerRecord<String, String> record : records) { String userId = record.value(); // 发布到Redis jedis.publish("user_logout_channel", userId); } } ``` 业务服务实例（每个）： ```java // 启动时订阅Redis频道 new Thread(() -> { Jedis jedis = new Jedis("redis-host", 6379); jedis.subscribe(new JedisPubSub() { @Override public void onMessage(String channel, String message) { if ("user_logout_channel".equals(channel)) { String userId = message; cleanLocalCache(userId); } } }, "user_logout_channel"); }).start(); ``` 这样，每个退出事件只被广播服务消费一次，发布一次Redis消息，所有业务服务实例都能收到并清理本地缓存。 总结：通过Kafka保证退出事件的可靠传递，通过广播服务将事件转换为Redis的发布订阅，实现实时通知所有业务服务实例清理内存，实现单点登出。 引用说明： - Kafka的高可靠性和持久化特性保证了退出事件不会丢失[^1]。 - Redis的发布订阅机制提供了实时消息传递能力[^2][^3][^4]。 - 通过独立的广播服务，我们避免了业务服务直接消费Kafka，简化了业务服务的逻辑。 注意事项： 1. 广播服务需要高可用，可以部署多个实例，使用同一个Kafka消费者组，这样其中一个实例宕机，其他实例可以接管。 2. Redis发布订阅不保证消息可靠传递，如果业务服务实例在消息发布时断开连接，可能会丢失消息。因此，业务服务需要处理这种情况（例如：设置本地缓存过期时间，或者使用其他机制补全）。 3. 如果业务服务实例扩容，新的实例会自动订阅Redis频道，从而能够收到之后的消息。 相关问题： §§相关问题§§ 1. 如何保证Redis发布订阅消息不丢失？ 2. 广播服务如何实现高可用？ 3. 除了Redis发布订阅，还有哪些方式可以实现服务实例间的消息广播？</think>### Kafka监听用户退出事件实现单点登录注销功能 要实现基于Kafka和Redis的单点登出功能，可通过以下方案实现： #### 核心架构设计 1. **用户退出事件采集** 用户退出时，认证服务向Kafka的`user_logout_topic`发送退出事件消息，格式示例： ```json {"userId": "u123", "sessionId": "sess_xyz", "logoutTime": 1685000000} ``` 2. **Kafka事件监听** 各微服务订阅`user_logout_topic`，消费退出事件： ```java // Kafka消费者配置 Properties props = new Properties(); props.put("bootstrap.servers", "kafka-cluster:9092"); props.put("group.id", "logout_consumer_group"); KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList("user_logout_topic")); ``` 3. **Redis发布订阅同步** 当服务消费到Kafka消息后，通过Redis发布频道通知： ```java // 收到Kafka消息后发布Redis通知 try (Jedis jedis = redisPool.getResource()) { jedis.publish("user_logout_channel", "u123"); } ``` 4. **内存数据清理** 所有服务节点订阅Redis频道并清理内存： ```java new Thread(() -> { Jedis jedis = new Jedis("redis-host"); jedis.subscribe(new JedisPubSub() { @Override public void onMessage(String channel, String userId) { localSessionCache.remove(userId); // 清理内存数据 } }, "user_logout_channel"); }).start(); ``` #### 关键优势 1. **可靠事件传递** Kafka保证退出事件不丢失，支持重试机制[^1] 2. **实时内存同步** Redis发布订阅实现毫秒级通知（通常<1ms延迟）[^2] 3. **分布式扩展能力** 新服务节点自动加入Kafka消费者组和Redis订阅 #### 注意事项 1. **Redis消息可靠性** - 添加离线消息存储：节点断线时暂存消息[^2] - 使用`PSUBSCRIBE`支持模式匹配的通配符频道[^3] 2. **Kafka消费控制** ```java // 确保至少一次消费 props.put("enable.auto.commit", "false"); consumer.commitSync(); // 手动提交offset ``` 3. **安全增强** - Redis频道名使用前缀隔离：`{tenantA}:user_logout` - Kafka消息启用SSL加密传输 > **性能数据**：单Kafka节点可处理10万+/秒消息[^1]，Redis发布订阅支持50万+/秒消息[^4]，完全满足高并发场景。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值