（转载）redis的发布/订阅和mq消息队列的区别,该如何选择?

原文连接：https://blog.csdn.net/superit401/article/details/86171473

本文以reids和rocketmq对比

很多人一直有个疑问(包括我之前也是):redis支持已经消息队列(发布/订阅)了,为什么还需要mq呢?

项目已经集成了redis,为什么还要多集成一个mq,那不是显得更臃肿吗?增加了维护成本

redis和mq相同点：

解耦

服务与之间耦合度,比如订单服务与用户积分服务(需求:下单成功,增加积分)

如果不用消息队列,订单服务和积分服务就要通信,下单后调用积分服务的接口通知积分服务进行处理(或者定时扫描之类的),那么调用接口失败,或者延时等等...一系列的问题要考虑处理,非常繁琐

用户了消息队列,用户A下单成功后下单服务通过redis发布(mq的生产者)一消息,就不用管了.用户积分服务redis订阅了(mq的消费者),就会受到这用户A下单的消息,进行处理.这就降低了多个服务之间的耦合,即使积分服务发生异常,也不会影响用户正常下单.处理起来就非常的丝滑,各干各的互不影响.

redis和mq区别：

可靠性和机制不一样

redis客户端在订阅消息时，要求订阅在发布之前，否则无法订阅到客户端订阅前，已经发布的消息。(,需要先订阅,然后发布的信息才会被订阅者收到)

redis的消息发布与订阅，无法实现高并发和大数据量。前者受限于redis本身的并发量限制和内存大小；后者是因为redis发布消息时，会先将数据推送到每个客户端的连接缓冲区，如果单个消息过大会撑爆缓冲区，导致redis错误，就算redis没有撑爆缓冲区，如果消费者（订阅方）没有及时取走消息，也会因为数据积累而撑爆内存。

mq的生产者和消费者则不存在先后关系,生产者只管往队列里面加信息,消费者只管从队列里面取信息

可以拿送快递来比喻

redis 是兼职跑腿的

mq 是专业的快递公司投递

redis送的快递,你必须在指定位置等到,送来你就能立马拿到,如何送过来如何你没在,那么证明你不要了,过后你再来,你就收不到了.

mq送的快递,你先来后来无所谓,先来,快递到了立马拿走,如何快递到了,还没来,那么放到门卫处,你到了再拿走.

现在你该知道如何选择了吧???