如题,2个问题:
1.什么场景需要考虑ActiveMQ(或者其他MQ框架),除了异构系统间的通讯这个用途。
2.既然有了rpc(比如thrift,dubbo)框架,也可以用来异步远程服务调用,为什么还需要MQ,各自的优缺点?
如题,2个问题:
1.什么场景需要考虑ActiveMQ(或者其他MQ框架),除了异构系统间的通讯这个用途。
2.既然有了rpc(比如thrift,dubbo)框架,也可以用来异步远程服务调用,为什么还需要MQ,各自的优缺点?
1、讲一个故事:
去火车站买票,有很多个售票窗口,你选择了一个人少的窗口买票,站在队尾慢慢往前排,售票阿姨可不管排队人数有多少总是按着自己的节奏在出票。
2、再讲一个故事:
上班期间太无聊,于是打开微信,找到女神逗趣。
又过了段时间,总是对着这么一个妹子暧昧,感觉还是太无聊,于是建了个女神群逗趣。
说说我个人的理解吧。
使用MQ的场景一般有这么几种,
进程间通讯,比如在分布式系统中。
解耦,比如像我们公司有许多开发团队,每个团队负责业务的不同模块,各个开发团队可以使用MQ来通信。
在一些高并发场景下,使用MQ的异步特性。
暂时想到这么多,其它的待补充。
至于RPC和MQ在分布式系统下的确是有一些功能类似的地方,这两个有时候是可以互相替换的,可以用RPC也可以用MQ。
这两个的区别在于RPC是单对单的,但MQ可以是单对多的。
一般来说RPC的性能要好于MQ(这个结论是我听一位大牛分享的时候提到的,自己没做过相关测试)。
消息队列的主要作用不是通讯,主要是用于解除子系统间的耦合,所以异构系统间的通讯实际并不是ActiveMQ发挥作用的场景,那反而是RPC发挥作用的时候。
消息队列更适合于需要更大流量和并发的大型系统场景,可以将消息队列视为一个可靠的通道,主交易过程在处理时,遇到需时较多同时又已经确定了条件的处理就丢到消息队列里进行后续处理,这样可以将主交易过程划分为一个一个可以异步处理的更小的处理过程,减少了主交易流程的处理时间,可以提供更快的响应速度和并发速度。例如,象淘宝这样的处理逻辑非常多的系统,在处理付款时,就可以将通知买家和卖家、记日志甚至记帐流程都放到消息队列里处理,整个主流程能够快速处理完成,继续处理下一个买家的请求。