kafka异步发送数据,不阻塞

本文探讨了Kafka生产者在遇到服务端故障时的默认阻塞行为,并介绍了一种通过调整配置项来避免长时间阻塞的方法。对于分布式应用而言,这种优化可以显著提升系统的稳定性和响应速度。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

kafka生产者默认是回执机制的,即必须确认服务端(server)处理过数据之后才能算是发送完成。虽然生产者会使用线程池处理这些业务,但如果kafka的服务端挂掉生产者也会进行阻塞。
kafka日志收集上线之前,测试的时候就发生过关掉kafka服务端后页面访问非常缓慢,结果找到原因是因为如果kafka生产者没连接到服务端就会进行6秒的阻塞。这对需要嵌入到各个子系统的分布式应用来说存在很大的隐患。

可以通过设置配置选项让kafka生产者不进行阻塞
max.block.ms 控制block的时长,当buffer空间不够或者metadata丢失时产生阻塞(block) 默认时长6000毫秒
props.put(“max.block.ms”, “0”);

在 Apache Kafka 中,异步发送消息通常意味着你在发送请求的线程上等待响应。Kafka 生产者提供了异步 API(如 `send()` 或 `sendAsync()`),当你调用这些方法时,生产者会返回立即,而阻塞直到消息实际被投递到服务器。这个过程通常是这样的: 1. **发送请求**:你调用异步发送方法,传递消息及其配置信息。 2. **设置回调**:如果你提供了回调函数(如 CompletionHandler),生产者会在消息成功写入日志后调用这个函数,或者如果出现错误,则在回调中抛出异常。 3. **处理回调**:回调发生在生产者的线程上,是你的主线程。这意味着如果在回调中抛出了异常,主线程并会直接接收到这个异常,除非你主动捕获并传播。 为了确保主线程能够捕获到异步发送的异常,你需要在回调中适当地处理它。通常的做法是在回调中: - 捕获异常 - 将异常包装成一个新的 `Future` 对象或者自定义的 Promise 对象 - 使用 Future 的 `completeExceptionally()` 或 Promise 的 `reject()` 方法将异常标记为未完成 - 主线程通过检查这个 Future 或 Promise 是否已完成(即有异常)来判断并处理 示例代码: ```java Future<Void> future = producer.sendAsync(record, newCompletionHandler(...)); future.whenComplete((success, exception) -> { if (exception != null) { throw new RuntimeException("Failed to send message", exception); } }); ``` 或者,使用 Try-with-resources: ```java try (AutoCloseable ignored = future) { future.get(); } catch (ExecutionException | InterruptedException e) { throw new RuntimeException("Failed to send message", e.getCause()); } ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值