1、最简单的架构模型
● Producer：消息生产者，负责产生和发送消息到 Broker；
● Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue；
● Consumer：消息消费者，从消息队列接收消息（负责从 Broker 中获取消息），并进行相应处理；
2、特性
异步性：将耗时的同步操作，通过以发送消息的方式，进行了异步化处理。减少了同步等待的时间。
松耦合：消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节，只要定义好消息的格式就行。
分布式：通过对消费者的横向扩展，降低了消息队列阻塞的风险，以及单个消费者产生单点故障的可能性（当然消息队列本身也可以做成分布式集群）。
可靠性（持久化）：消息队列一般会把接收到的消息存储到本地硬盘上（当消息被处理完之后，存储信息根据不同的消息队列实现，有可能将其删除），这样即使应用挂掉或者消息队列本身挂掉，消息也能够重新加载。
3、消息队列的应用场景
异步处理：例如：短信通知、终端状态推送、App推送、用户注册、秒杀等，实效性要高，吞吐量要大
数据同步：业务数据推送同步
重试补偿：记账失败重试
系统解耦：通讯上下行、终端异常监控、分布式事件中心
流量削峰：秒杀场景下的下单处理（层层肖锋，分成过滤，漏斗式设计处理请求）
【 CDN 】
【 缓存系 】
【 后台写系统 】
【 DB 】
发布订阅：HSF的服务状态变化通知、分布式事件中心
高并发缓冲：日志服务、监控上报*
异步场景
之前的场景，有很多步骤都是在一个流程里全部做完，比如下单系统，下单付钱，流程走完。但是,
A产品经理，搞个【优惠券】系统，流程多100ms去扣减优惠券；
B产品经理，搞个【积分】系统，流程多200ms去增减积分；
C产品经理，搞个【短信】系统，流程多100ms去发短信。
4、常用消息队列
RabbitMQ：结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。
Kafka：Apache子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性
ActiveMQ：Apache子项目，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。需要安装：Java JDK，ActiveMQ安装包，可以运行在Java语言所支持的平台之上
ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景。扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。
RocketMQ：阿里公司的开源产品，用 Java 语言实现，需要安装：Java JDK，git，Maven，RocketMQ安装包，可以运行在Java语言所支持的平台之上
MetaQ：阿里公司的开源产品，
MSMQ：
5、为什么要用消息队列
123
6、消息的持久化
1
2
3
7、消息的同步和异步收发
123
8、消息的事务支持
123
9、消息队列之常用协议
AMQP：即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,
MQTT协议：
STOMP协议：
XMPP协议：
10、使用消息队列带来的一些问题
系统可用性降低： 系统可用性在某种程度上降低，在加入MQ之前，你不用考虑消息丢失或者说MQ挂掉等等的情况，但是，引入MQ之后你就需要去考虑了！
系统复杂性提高： 加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！
一致性问题： 我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了!
11、
扫一扫
516
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
添加红包
