为什么要用消息队列或消息队列的优缺点
为什么要用消息队列(优点)
- 解耦:主要是消息中间件的发布订阅功能,多个模块可以订阅一个模块的消息,不过我从来没有做过相关的功能,而我接触到的主要是异步
- 异步:对于一次复杂操作可能需要耗时很长,这时候就可以对其进行时序性要求不高的功能进行拆分,通过发送消息来异步执行以提高系统响应速度
- 削峰:针对于大并发场景,大量请求到数据库对数据库造成压力,此时可以采用消息队列将请求信息缓存,然后按照数据库承受量对消息进行消费
带来的问题(缺点)
- 系统可用性降低:这个很好理解,如果消息服务挂掉,直接会导致整个依赖于消息服务的功能不可用,所以在设计系统时一定要考虑消息服务的高可用,从而提高系统的可用性。
- 系统一致性降低:这个是由于生产者发送消息成功后返回通知用户的是成功,而消费者在处理消息时失败了,这时候就会造成系统功能的不一致,所以设计时应该考虑消费失败的问题。
- 系统复杂性增高:没有引入时成功就是成功失败就是失败,引入后,就要考虑上面提到的一致性问题,可用性问题,还要考虑消息是否成功发送,消费者是否成功接收到消息这些属于消息的可靠投递问题,还有是否有重复消费的情况这属于幂等消费问题(即同一消息不管重复发送多少次都保证只能被消费一次)
主流消息队列产品
特性 | activemq | rabbitmq | rocketmq | kafka |
---|---|---|---|---|
开发语言 | java | erlang | java | scala |
单机吞吐量 | 万级 | 万级 | 十万级 | 十万级 |
时效性 | 毫秒级 | 微妙级 | 毫秒级 | 毫秒级 |
可用性 | 高,主从架构 | 高,主从架构 | 非常高,分布式 | 非常高,分布式 |
消息丢失 | 低 | 低 | 通过参数配置0丢失 | 通过参数配置0丢失 |
功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发,并发能力很强,性能极好,延时很低 | MQ 功能较为完善,还是分布式的,扩展性好 | 功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用 |
看了很多网上的建议,中小型公司一般建议选择rabbitmq,因为其开源社区且活跃,不会出现太大问题,这样考虑也不无道理,反正我现在的公司也是在用rabbitmq,不过我感觉rocketmq会更好一些,等找时间好好学习一下。