求问单生产者场景使用消息队列是否过度设计？

[TimG]

公司内部小程序开发，需求就是推送个人工作量月报到每个雇员的钉钉上。月报说白了就是个 PDF 文件，按照模板生成然后依次调用钉钉接口发送，业务比较简单，最多就是再生成一份部门月报发给主管。预测不会对接多个系统，这种情况下再引用一个 kafka 这样的消息队列是否有些过度设计了？以往工作都是前端，没有接触过这类，学习和后期使用成本会大于自己手动实现个基础功能的队列吗？

提前谢过各位大佬。

[inhzus]

为啥要引入消息队列呢，生产完表格后直接 webhook 调用就行？

[JoeJoeJoe]

你是想加上 kafka, 摸半个月的鱼并且让 KPI 更好看
还是想
半天搞完再去忙其他的项目

[kzfile]

没有强性能需求，用数据库的表模拟就行了

[mindddd]

我认为一个 redis 就可以了，维护两个队列，一个消费中队列，一个是准备消费队列。最简单最保障的实现

[TimG]

@inhzus 其实主要是看上有完整的日志和重放功能，我们在内网调钉钉的接口要经过挺多前置机转发，可能不稳定.......确实是，，自己想想都觉得有点多余

[JYii]

我甚至都不想把这个功能放小程序上，丢到后端定时任务或接口触发，查表，填充模版，导出，发送。什么 Kafka 消息队列 redis 都不想用

[TimG]

@JoeJoeJoe 摸了摸了 hhh

@kzfile
@mindddd
感谢回复。我有点盲人摸象了，不知道是否能符合需求，想提前问下各位心里有个底

[TimG]

@JYii 钉钉小程序是领导要求的，说显得专业 hhhh

[loading]

数据库加个表，每个人一行，定时扫这个表就行。没几个人，没必要增加技术和运维成本。

[TimG]

@loading 感谢回复。扫表肯定是要扫表的，有消息队列也要扫吧，并且传统服务行业，雇员数和类型...确实出乎意料的多

[seth19960929]

队列和定时任务
你这个需求很明显用定时任务来执行更合适，周报月报这种有很强的定时性
你可以说生成 pdf 慢，放到队列，但是就目前你这个需求定时任务
至于失败这种和队列无关，是你的业务相关，你自己加一个字段标记发没发，没发的定时任务扫描出来

[TimG]

@seth19960929 谢谢大佬，您说的我读了很多遍，现在感觉有点开窍了。我把消息队列按照字面意义理解了，认为跟弹夹一样，我提前把不同雇员的“调用钉钉发送任务”压进队列，让他自顾自的清理队列就行，至于失败重发、日志功能等等则借助消息队列自身的功能独立完成，我只管写程序压队列。听了您的解释，消息队列似乎是用来处理耗时操作的，像是高级模块化的线程调度器？它确实应该是工作在更底层的位置，而不是一个简单的 API 调度器。
失败重发我确实没想到要自己实现。看来无论如何也得自己实现一个简单队列，这个省不了了。

[TimG]

@seth19960929 确实查表填入 PDF 才是更耗时和容易出问题的操作，恍然大悟了！前面都在乱说什么真丢死人了哈哈哈，感谢感谢。

[seth19960929]

@TimG 你可以这么认为，队列就是可靠的异步线程，线程程序可能奔溃执行不到，但是队列不会
至于你说的自己实现，我和你说原理，你自己看看
失败重试，这些都是队列自带，但是这个更底层，比如你的发消息给钉钉要 2s ，但是执行到 1.5s 的时候进城奔溃了，当你重启服务的时候，队列系统还能让你重新执行这个任务，这是队列系统本身要实现的可靠性，
至于你说的发送没发送那是业务型的，你的表 send_status. send_month
这时候定时任务是 send_status!=1.send_month!=当前月份
查出来，扔到队列或者后台执行都行，然后执行完一个就把这条记录的这两个字段标记好，放定时任务再次扫描的时候就跳过这个任务了

[julyclyde]

只要前后两个的执行速度不同、业务数量比例不是一比一，都是值得用消息队列的
是解耦点，也是性能测量点