1.为啥要选用RabbitMQ
常见的消息队列有ActiceMQ,kafka,RocketMQ,RabbitMQ四种
ActiceMQ:
优点: 单机吞吐量万级,时效性ms级,几乎不丢失消息
缺点: 官方社区对ActiceMQ5.x维护越来越少,高吞吐量场景使用较少
kafka:
优点: 单机写入TPS约百万条/秒,最大的优点就是 吞吐量高,时效ms级.
大数据分布式常用,有管理界面,多用于实时计算及日志采集
缺点: 单机超过64个队列/分区,cup会发生明显的飙高现象,而且消息
也可能会丢失,一旦某一台代理宕机后,就可能丢失,社区更新也慢
RocketMQ
优点: 单机吞吐量十万级,可用性非常高,分布式架构,消息可以做到0丢失,
扩展性好,支持10亿级别的消息堆积,源码是java开发的
缺点: 支持的客户端语言不多,目前只支持java和c++,c++还不成熟.....
社区活跃度一般,系统迁移可能需要修改大量的代码
RabbitMQ
优点: 高并发,性能较好,吞吐量万级,功能比较完备,跨平台,支持多种语言,
社区活跃度也很高,更新频率相当高
缺点: 商业版需要收费,学习成本较高
基于以上MQ的特性,就选择了符合当前项目的RabbitMQ
2.常见的作用及应用场景
解耦合(为soa提供最终一致性的实现):
例如常见的订单,库存,支付等,如果写一块不仅处理速度慢,可用性也不高,一旦
某一个节点出现问题都会导致订单失败.如果引入RabbitMQ,只要在写入消息
队列这一步是成功的,就可以直接返回给用户下单成功,剩下的就可以分批处理了
提升效率:
例如订单流程: 将下单--修改库存--支付等流程通过异步的方式同时进行处理,将
极大的提升下单的总时间
再例如用户注册: 用户注册--发送邮件--发送短信也可以三步同时进行
流量削峰
例如秒杀/抢购等活动,在秒杀的那一段时间内,会瞬间接收远超当前能处理的
吞吐量,但是过了这段时间流量就又下来了,总不能多加好几个服务器在那儿放
着,只为了这几分钟甚至这几十分钟吧.引入MQ后,就可以正常处理请求,将超出
当前服务器支持的流量先进行一个保留,积压,等这段时间过去后就可以很快的处
理这些堆积的请求
引入消息队列的优缺点:
优点:
解耦,异步提升效率,削峰
缺点
1.系统复杂度
加任何一个框架都会增加系统的复杂度,mq自己的问题也有很多,例如消息的丢失,
重复消费等待问题
2.系统的可用性降低
一旦MQ出现问题,其他本来能用的系统接口也会挂掉,导致系统崩溃
3.一致性
因为MQ是异步处理请求的,也就意味着很有可能前面显示成功了,但是后面
处理失败了,还需要另外的机制来解决这个问题
还是看自己的业务需求,小项目不建议引入,中大型有需要的项目可根据项目需求选择适当的MQ进行引入
|