Last Task - concurrent tasks for retry

本文讨论了在接收到Kafka消息后如何处理流式传输到第三方系统的过程,包括保存消息状态、处理失败情况及实现重试功能。当消息传输失败时,系统将设置状态为'failed',用户可通过重试API再次尝试。设计中提到使用数据库写锁或Redis锁来防止并发重试,并通过为状态字段建立索引来优化性能。
摘要由CSDN通过智能技术生成

task requirement

Background

There's a function in the product that after receive kafka msg, the system need to stream out the message content to third party system. For example, some merchant using this function to stream out their orders to warehouse after the customer paied the order.

However, not all the orders can be streamed out successfully, it might failed due to network issues or authentication issue or some runtime exceptions. The merchant is hoping to have retry function to stream out the failed orders.

Design

After received the kafka message, save it with "in-progress" status and stream it out. if it's successful, set the status to "succeed" and "failed" if not. When the user call the retry API, get the failed msg and do re-stream out function.

Concurrent situation

The existing implementation to consume Kafka message already has re-try mechanism :

@Transactional
@KafkaListener(topics = "${xxx}", containerFactory = "retryableKafkaListenerContainerFactory", concurrency = "#{@kafkaProperties.getConcurrencyValueForRetryableConsumers({'order-status-changed'}, ${service.app.instances:2})}")
public void processOrderStatusStreamingMessage(@Payload final Message<OrderStatusChangedPayload> message) {
    
        ...
}

And we also need to prevent the user call the "retry" API multi times, the data can only be streamed out once.

Solution

After receive the retry request, get the message with "failed" status with write lock, set the status to "in-progress", then run the stream out function.

If there's concurrent requests, it has to wait. After the first thread release the lock, the status already set to "in-progress", the stream out function won't be called.

Using db write lock is not the best way from performance view, but simple and easy to go. Redis lock should be considerred for better performance.

Using DB write lock, and the query is by the message status, when design the message persistance, should set index for the status so that only lock the row instead of the whole table.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值