消息系统类型

一、消息系统分类

1. Peer-to-Peer：
   1. 一般基于Pull或者Polling接受消息
   2. 即使有多个消费者监听，但是消息在发送到消息队列之后只能被一个消费者消费
   3. 生产者在将消息放入消息队列之后不再关心该消息是否被消费，即"即发即弃"的消息传输方式，也支持同步请求应答方式
2. 发布/订阅：
   1. 发布到一个主题的消息可以被多个订阅者订阅
   2. 发布/订阅模型主要基于Push机制，也可以基于Pull或者Polling机制
   3. 解耦能力比P2P要强

 

二、消息系统的适用场景

1. 解耦：各个系统之间通过消息系统这个统一接口交换数据，无须了解彼此的存在
2. 冗余：部分消息系统拥有持久化的能力，可以规避消息处理前丢失的风险
3. 消峰限流：消息系统可顶住峰值流量，业务系统可根据处理能力从消息系统中获取数据
4. 异步通信：在不需要立即处理请求的场景下，可以将请求放入消息系统在需要的时候再取出处理

 

三、消息队列对比

1. RabbitMQ
   1. RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发
   2. 实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持
2. Redis
   1. Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃
   2. 虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用
3. ZeroMQ
   1. ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景
   2. ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战
   3. ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty（NIO）作为传输模块）
4. ActiveMQ
   1. ActiveMQ是Apache下的一个子项目
   2. 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列
   3. 类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。