这是一个创建于 369 天前的主题，其中的信息可能已经有所发展或是发生改变。
客户点击导出 excel,这时发送一条消息到 rocketmq
rocketmq 在消费时,会有超时重试机制,默认 15S,重试(不管有没有错误,到时间就认为超时,虽然可以修改)
生成个 excel 的时间可能在 3~5 分钟,可能生成时发生错误(如读取数据超时,有一定容错,但无法避免完全不出问题).
这种情况是不是太适合用 rocketmq 来做触发和重试?
用数据库做轮询是不是比较好?
或是更好的实现方式?
 |
1
feidao158 2023-11-18 17:12:55 +08:00
貌似你把 ack 的做法给理解错了吧，你应该在收到消息的那一刻就确认消息，然后在线程池之类的地方开始处理任务，如果失败再重新投递到 mq 重试或者进行其他逻辑，我理解你是想等待任务同步处理完再 ack ，那你用 mq 的目的是什么
|
|
2
feidao158 2023-11-18 17:14:08 +08:00
mq 的精髓是异步解耦，重点是异步..
|
|
3
feidao158 2023-11-18 17:17:23 +08:00
当你的消费者收到 mq 投递的消息那一刻，后续的业务逻辑应该就跟 mq 无关了
|
 |
4
potatowish 2023-11-18 17:19:38 +08:00 via iPhone
看你公司用户体量，mq 不是银弹，它的作用是异步解耦、削峰，超时重试和容错处理完全可以放在你的业务代码中处理。
|
 |
5
EscYezi 2023-11-18 17:21:57 +08:00 via Android
这是要做超时重试？ rocketmq 应该有个延时消息
|
 |
6
pennai 2023-11-18 17:23:18 +08:00  1
楼上两个背八股背魔怔了吧...mq 不用超时重试不用 ack ，不用考虑收到消息后服务立刻挂掉的情况，不用考虑扩容缩容的情况？
|
 |
7
ttthys 2023-11-18 17:23:52 +08:00
mq 只做异步，你把消息发出去确定消费者能够接收到就行了，这个和你业务的处理时间有什么关系？，你是想下载完了有消息能够检测到？，那你可以处理完了再发送个 mq 告知生产者不就行了，然后生产者收到消息通过 websocket 发送消息到前端，或者收到消息后在 redis 中存放一个消息，前端轮询请求 redis 中是否有这个消息
|
 |
8
NickX 2023-11-18 17:36:40 +08:00 2
太扯淡了。直接前端轮询 Excel 生成完毕了没，完毕就再请求后端下载，生成失败让用户再点多次，做个标志位的事情，搞那么多，过度设计了。
|
 |
9
Beats 2023-11-18 17:54:04 +08:00
跟 mq 毛关系啊， 做个任务管理器，用户点击就创建一个任务，给前端返回一个任务 id ，然后另外提供一个长轮询的接口让前端调用等待就行了。 再做好点可以提供个下载进度查询页面
|
 |
10
dnjat OP @potatowish
@EscYezi @pennai @ttthys 确实对 mq 的理解有误,想得太简单了,把业务功能中出现的重试去交给了 mq😂. 谢谢大伙. 接下来要想一下如何保证业务上的重试流程了. |
|
11
dnjat OP |
Select Language