java消息队列

一、概述
消息队列（Mwssage queue 先入先出（FIFO））中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构
其中：
1、削峰：所有生产的消息全部放入队列，考虑消费消息的数量，批次处理消息。适合大型数据系统
2、解耦：只考虑生产消息放置情况，不考虑消费情况，适合小型数据系统。

二、消息中间件的组成
1 Broker
消息服务器，作为server提供消息核心服务
2 Producer
消息生产者，业务的发起方，负责生产消息传输给broker，
3 Consumer
消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理
4 Topic
主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播
5 Queue
队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
6 Message
消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输
三、模式分类
1、 PTP点对点：使用queue作为通信载体
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。当没有消费者可用时，这个消息会被保存直到有一个可用的消费者

2、 Pub/Sub发布/订阅：使用topic作为通信载体
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
注：针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。

四、目前使用较多的消息队列
老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等

1、Redis
一个基于Key-Value对的NoSQL数据库，开发维护很活跃。

2、RabbitMQ
开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，非常重量级，更适合于企业级的开发。
同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。多用于进行企业级的ESB整合。

3、ZeroMQ
ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景
ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，具有一个独特的非中间件的模式。
但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失

4、ActiveMQ
ActiveMQ是Apache下的一个子项目，能够以代理人和点对点的技术实现队列，它少量代码就可以高效地实现高级应用场景。

5、RocketMQ

1. 定义
   阿里参照kafka设计思想使用java实现的一套mq，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
2. 具有以下特点：

• ocketMQ 主要用于有序，事务，流计算，消息推送，日志流处理，binlog分发等场景。经过了历次的双11考验，性能，稳定性可可靠性没的说。
• RocketMQ 几乎具备了消息队列应该具备的所有特性和功能。
• java 开发，阅读源代码、扩展、二次开发很方便。
• 对电商领域的响应延迟做了很多优化。在大多数情况下，响应在毫秒级。如果应用很关注响应时间，可以使用RocketMQ。
• 性能比RabbitMQ高一个数量级，每秒处理几十万的消息。

3. 缺点：跟周边系统的整合和兼容不是很好。

6、Kafka/Jafka

1. 定义
   Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅轻量级的消息系统。
   Jafka是Kafka的一个升级版。
2. 特性

• 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
• 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
• 高堆积：支持topic下消费者较长时间离线，消息堆积量大；
• 完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
  支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。

3. 缺点
   .由于是批量发送，所以数据达不到真正的实时
   .对于mqtt协议不支持
   .不支持物联网传感数据直接接入
   .只能支持统一分区内消息有序，无法实现全局消息有序
   .监控不完善，需要安装插件
   .需要配合zookeeper进行元数据管理
   .会丢失数据，并且不支持事务
   .可能会重复消费数据，消息会乱序，可用保证一个固定的partition内部的消息是有序的，但是一个topic有多个partition的话，就不能保证有序了，需要zookeeper的支持，topic一般需要人工创建，部署和维护一般都比mq高

五、在使用的过程中遇到了以下几个问题：
1、数据同步的时候消费者挂掉了
消费者挂掉的原因是因为内存溢出，为什么会内存溢出？
后面发现线停到消费者，然后等待队列里面堆积很多消息之后在启动消费者，发现不一会儿就会出现内存溢出，排查发现是因为没有使用QOS预取，导致了消息一下子全部被拉取到消费者，导致消费者内存溢出。
解决方案：设置QOS的值为300，重新发布消费者，没有出现内存溢出
2、消息丢失了
由于之前消费者挂掉，所有的消息都堆积到了队列里面，队列都已经堆积满了，溢出的消息却无处可去直接被丢弃了
解决方案：增加死信交换器和死信队列，溢出的消息会进入死信队列继续消费，同时也把队列和交换器以及消息做了持久化设置

六、使用消息中间件给系统带来了哪些弊端
1、系统的整体可用性降低了
由于引入了消息中间件，所以不得不去考虑消息中间件会挂掉的可能性，一旦消息中间件挂掉，那么系统就会不可用。
2、系统变得更复杂了
由于引入了一个消息中间件，从系统整体上来说又多了一个需要整合的模块，从开发上来说需要进行消息中间件代码的编写。