一、消息系统分类
- Peer-to-Peer:
- 一般基于Pull或者Polling接受消息
- 即使有多个消费者监听,但是消息在发送到消息队列之后只能被一个消费者消费
- 生产者在将消息放入消息队列之后不再关心该消息是否被消费,即"即发即弃"的消息传输方式,也支持同步请求应答方式
- 发布/订阅:
- 发布到一个主题的消息可以被多个订阅者订阅
- 发布/订阅模型主要基于Push机制,也可以基于Pull或者Polling机制
- 解耦能力比P2P要强
二、消息系统的适用场景
- 解耦:各个系统之间通过消息系统这个统一接口交换数据,无须了解彼此的存在
- 冗余:部分消息系统拥有持久化的能力,可以规避消息处理前丢失的风险
- 消峰限流:消息系统可顶住峰值流量,业务系统可根据处理能力从消息系统中获取数据
- 异步通信:在不需要立即处理请求的场景下,可以将请求放入消息系统在需要的时候再取出处理
三、消息队列对比
- RabbitMQ
- RabbitMQ是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正因如此,它非常重量级,更适合于企业级的开发
- 实现了Broker构架,这意味着消息在发送给客户端时先在中心队列排队。对路由,负载均衡或者数据持久化都有很好的支持
- Redis
- Redis是一个基于Key-Value对的NoSQL数据库,开发维护很活跃
- 虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用
- ZeroMQ
- ZeroMQ号称最快的消息队列系统,尤其针对大吞吐量的需求场景
- ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,技术上的复杂度是对这MQ能够应用成功的挑战
- ZeroMQ仅提供非持久性的队列,也就是说如果宕机,数据将会丢失。其中,Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输(Storm从0.9版本开始同时支持ZeroMQ和Netty(NIO)作为传输模块)
- ActiveMQ
- ActiveMQ是Apache下的一个子项目
- 类似于ZeroMQ,它能够以代理人和点对点的技术实现队列
- 类似于RabbitMQ,它少量代码就可以高效地实现高级应用场景。