我的系统，有一部分的业务是“查询其它系统的订单处理结果，然后更新我的订单状态”。
目前问了两个“前辈”，都说写定时任务，去数据库里扫表，拿出处理中的订单，去挨个轮询状态。
我一直以为这种操作（查其它系统，修改自己订单的操作。）应该扔给消息队列，作为异步任务去处理。
但是前辈说，消息队列，不安全，会丢失，那么我想请教两个问题。
1.消息队列不安全，会丢失，是指什么？是指载体，类似rabbitmq和redis数据是放在内存的？难倒不可以持久化么？还是其它原因？
2.是不是相比于“查询补单”这样的业务，将结果通知给其它系统，这种业务更适合使用消息队列的异步任务（rabbitmq+celery）。
reids 的list可以作为消息队列来使用。当消费者从list中取出消息时redis就已经将消息删除，此时如果消费者消费失败，或者因为异常、不可抗拒因素（宕机等）时，可能会导致消息丢失的情况。
但是也可以使用RPOPLPUSH这些命令去弥补，当消费完成后再去进行删除，保证消息的可靠性。
当然有很多队列都是有可靠消费的保证，当你消费完成后，再次向队列发送完成的确认，队列才会删除消息。
首先确认“其他系统”是否可以针对你们业务进行开发。
如果不能开发，建议你的系统定时轮询。
如果可以开发，两个系统用消息队列或者其他接口形式沟通都可以。
具体问题具体分析
前辈说的方法简单,也能实现,就是对数据库造成额外压力.
用消息队列处理更及时,但需要额外维护.
个人建议:如非必要,勿增实体.
如果用队列 就要别人和你对接 无形中就增加了难度和时间上的开支， 这也是他们让用定时任务的一个原因之一 我猜 如果错了请见谅
rabbitmq和redis都可以持久化，并且工作的很良好，我维护过的一个rabbitmq消息队列运行一年左右时间也没有出现过丢消息之类的问题，并且还可以做热备，这两位"前辈"可能是舒适区呆惯了，不怎么愿意折腾新技术或者说也只是道听途说来的结果（题主自己也打了引号了，说明并不十分认同其技术能力）
但具体落实到实际操作中确实有各种各样的问题， @nigelvon 说的我觉得很不错，牵扯到这个其它系统的改造问题
还有一个是我补充的：
多引入一个额外的系统会增加运维的复杂度，如果你的订单量不大，或者说，目前这个惯用的轮询的方式已经工作的非常良好，那也不失为一个好方案。多引入一个rabbitmq或者redis，一方面，你程序的配置会变得更加复杂（意味着上线也会多步骤，比如要检查你消息队列中的消息是否要延后处理），另一方面，运维需要多一个东西要关注和监控，这是实实在在增加的成本
能在性能，开发便利性还有运维便利性之间做一个良好的平衡，才是一个好的技术方案