rocketmq 适合做消费耗时长的任务吗?

[dnjat]

客户点击导出 excel,这时发送一条消息到 rocketmq

rocketmq 在消费时,会有超时重试机制,默认 15S,重试(不管有没有错误,到时间就认为超时,虽然可以修改)

生成个 excel 的时间可能在 3~5 分钟,可能生成时发生错误(如读取数据超时,有一定容错,但无法避免完全不出问题).

这种情况是不是太适合用 rocketmq 来做触发和重试?

用数据库做轮询是不是比较好?

或是更好的实现方式?

[feidao158]

貌似你把 ack 的做法给理解错了吧，你应该在收到消息的那一刻就确认消息，然后在线程池之类的地方开始处理任务，如果失败再重新投递到 mq 重试或者进行其他逻辑，我理解你是想等待任务同步处理完再 ack ，那你用 mq 的目的是什么

[feidao158]

mq 的精髓是异步解耦，重点是异步..

[feidao158]

当你的消费者收到 mq 投递的消息那一刻，后续的业务逻辑应该就跟 mq 无关了

[potatowish]

看你公司用户体量，mq 不是银弹，它的作用是异步解耦、削峰，超时重试和容错处理完全可以放在你的业务代码中处理。

[EscYezi]

这是要做超时重试？ rocketmq 应该有个延时消息

[pennai]

楼上两个背八股背魔怔了吧...mq 不用超时重试不用 ack ，不用考虑收到消息后服务立刻挂掉的情况，不用考虑扩容缩容的情况？

[ttthys]

mq 只做异步，你把消息发出去确定消费者能够接收到就行了，这个和你业务的处理时间有什么关系？，你是想下载完了有消息能够检测到？，那你可以处理完了再发送个 mq 告知生产者不就行了，然后生产者收到消息通过 websocket 发送消息到前端，或者收到消息后在 redis 中存放一个消息，前端轮询请求 redis 中是否有这个消息

[NickX]

太扯淡了。直接前端轮询 Excel 生成完毕了没，完毕就再请求后端下载，生成失败让用户再点多次，做个标志位的事情，搞那么多，过度设计了。

[Beats]

跟 mq 毛关系啊， 做个任务管理器，用户点击就创建一个任务，给前端返回一个任务 id ，然后另外提供一个长轮询的接口让前端调用等待就行了。 再做好点可以提供个下载进度查询页面

[dnjat]

@potatowish
@EscYezi
@pennai
@ttthys
确实对 mq 的理解有误,想得太简单了,把业务功能中出现的重试去交给了 mq😂. 谢谢大伙.
接下来要想一下如何保证业务上的重试流程了.

[dnjat]

@NickX
@Beats 想稍微自动一点,比如 mq 收到消息,触发了任务. 任务在执行中调用接口超时了,还需继续重试.

[Beats]

@dnjat 所以让你考虑做成任务的形式，任务执行过程中失败了你把状态更新成失败，后面会有检测服务去定时查找失败的任务进行重试。

业务量不大你就纯数据库也能做，每来一个请求就插入一条记录，状态为待执行。 一群 worker 线程去从数据库获取任务，同时将状态改为执行中。 执行完毕将状态改为成功，失败就记录下失败状态。 一个任务检测线程，定期检查失败的和超时未执行的任务，做重试或者告警

[dnjat]

@Beats 非常谢谢,好像有点开始明白 mq 的正确使用方式了😂