原文连接：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送的快递,你先来后来无所谓,先来,快递到了立马拿走,如何快递到了,还没来,那么放到门卫处,你到了再拿走.
现在你该知道如何选择了吧???
标签：订阅,队列,redis,快递,mq,消息,下单 来源： https://www.cnblogs.com/bzfsdr/p/16447467.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。