消息系统类型
一、消息系统分类
- 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，它少量代码就可以高效地实现高级应用场景。