为什么常说消息队列不安全?

[aiqier]

我的系统，有一部分的业务是“查询其它系统的订单处理结果，然后更新我的订单状态”。

目前问了两个“前辈”，都说写定时任务，去数据库里扫表，拿出处理中的订单，去挨个轮询状态。
我一直以为这种操作（查其它系统，修改自己订单的操作。）应该扔给消息队列，作为异步任务去处理。
但是前辈说，消息队列，不安全，会丢失，那么我想请教两个问题。

1.消息队列不安全，会丢失，是指什么？是指载体，类似 rabbitmq 和 redis 数据是放在内存的？难倒不可以持久化么？还是其它原因？
2.是不是相比于“查询补单”这样的业务，将结果通知给其它系统，这种业务更适合使用消息队列的异步任务（ rabbitmq+celery ）。

[yinheli]

交易系统, 使用过 rabbitmq, 对于重要的消息可以开启持久化和手工确认, 不会丢失.

目前大部分的消息, 异步处理业务全部是通过 rabbitmq 处理, 实时性和效果都非常好.

[lianz]

有部分消息队列软件是仅存在内存里，不持久化的，如果出问题的话真的就丢了。所以，要用能持久化的软件（效率会降低），比如楼上说的 rabbitmq ，还有其他一系列 mq 都可以用， google 一下

[HentaiMew]

大部分 JMS 实现产品都能持久化队列消息的…例如 kafuka 这种不完全为了实现 JMS 的消息中间件都会把未处理的消息持久化，更别提 AMQ 或者 RMQ 了

[tonyVex]

rabbitmq 支持持久化，当然这样会降低效率。

[sunus]

因为前辈对消息队列不了解

你让前辈们给你讲讲他们用过哪些消息队列？消息队列支持事物么？数据库怎么支持事物的，为啥数据库数据不会丢失

[adrianzhang]

为啥不问问那两个前辈“ why ”?

[wuliao49]

这种说法我觉得是有一定道理的，具体看要场景。
以前我再某大型国有金融机构工作过，买的是 IBM 的 MQ ，应该说无论哪方面 MQ 都强过 rabbitmq 。
但是用下来确实有问题，某些情况下，一旦队列满了，为保证时效性，不得不手动清理，丢过很多重要数据。

[HentaiMew]

@wuliao49 那你们当时为什么不考虑分布式消息队列呢……

[9hills]

支付宝就用消息队列。。

[lucky2touch]

从另外一个角度看一下，也许前辈就是敷衍你一下，一般来说，引入新的技术就有新的风险。
1.消息可以持久化，也支持事务，有其它情况，比如队列满了需要处理等等，设备要不要配盘阵之类。
2.业务不是很明白，一般来说有数据交互的地方都可以用消息中间件，一对多还可以用 topic 啥的。
一般我认为有把握可以在自己系统范围内尝试，但是如果涉及要别人配合你修改代码或架构就比较麻烦了......

[aiqier]

@9hills 是通知的部分用消息队列？还是提交部分？或者补状态模块？

[aiqier]

@lucky2touch 是不是比起补状态任务，通知才更适合用消息队列做异步部任务,因为后者任务不需要太多的逻辑判断和异常考虑？

[clino]

我觉得即使消息队列有丢失的可能 也可以想办法做到安全的

[huson]

你可以写个 demo 出来给他们看 问问他们哪里不安全了。。

[julyclyde]

应该是前辈对（他们自己）未知的事物怀恐惧心理

[huobazi]

那前辈快混到退休了吧。

[akira]

对于自己不熟悉的东西，最好摸清楚了再用。。

[elcamino]

@wuliao49 MQ 有 queue depth event ，完全不用手工做这些

[elcamino]

@huobazi 倒不是年纪大，可能就是不熟悉。消息中间件都是 90 年代末的东西了，几乎所有的金融机构都在用，而且用了几十年...