RabbitMQ

一、学习中产生的问题

问题1.消费者接受不到生产者消息

解:因为是main函数运行生产者和消费者，当多次运行生产者后，随机一个消费者可以接收到消息，

后来发现是多个消费者使用了同样的对列名，也就是在这个生产消费者模式中，存在多个消费者，所以当运行多个相同的消费者，会随机接受消息。多个消费者同时消费一个生产队列

 

RabbitMQ如何在命令行下清除消息队列中的所有数据

首先定位到 rabbitMQ 安装目录的sbin 目录下。然后shift+右键 。调出右键菜单。选择在此处打开命令窗口，打开一个cmd窗口。

输入命令：

rabbitmqctl list_queues

查看所有队列。结果如下：

发现有100多万条数据了。清除的命令是：

rabbitmqctl reset

但是在使用此命令前，要先关闭应用，否则不能清除。关闭应用的命令为：

rabbitmqctl stop_app

执行了这两条命令后再次启动此应用。命令为：

rabbitmqctl start_app

再次执行命令：

rabbitmqctl list_queues

这次可以看到 listing 及 queues都是空的

二、选型和初步认识

场景

    在我们平时的超市中购物也是一样，当我们在结算的时候，并不会一窝蜂一样涌入收银台，而是排队结算。这也是队列机制。

在这业务场景中，我们就可以采用队列的机制来处理，因为同时结算就只能达到这么多。一个接着一个的处理，不能插队。    

RabbitMQ 选型和对比

1.从社区活跃度

按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。 

2.持久化消息比较

ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。

3.综合技术实现

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。

4.高并发

毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。

5.RabbitMQ 和 Kafka的比较

RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上，RabbitMq胜于Kafka（理论上）。

另外，Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。

还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。

三、ActiveMQ是什么

       消息队列中间件是分布式系统中的重要组件，主要解决异步消息，应用解耦，流量削峰等问题，从而达到高可用，高性能的架构，使用较多的有ActiveMQ、RabbitMQ、Kafka等

异步消息

传统项目中用户注册功能，需要发送注册邮件和短信。

做法为：将注册消息写入数据库，发送注册邮件，再发送注册短信，以上三个任务完成，返回给客户端

引入了消息队列：

先将注册信息写入数据库，启动一个消息队列，写入消息，邮件和短信系统会异步读取消息，发送邮件和短信，耗时更短

应用解耦

应用场景：当用户下单时，订单系统需要通知库存系统，传统的做法是，订单系统调用库存系统的接口。

缺点：假如库存系统无法访问，则订单减库存失败，从而导致下单失败

订单系统和库存系统耦合度太高

引入消息队列后：

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户，下单成功

库存系统:订单下单的消息，获取下单的信息，进行库存操作

假如在下单时库存无法正常使用，也不影响下单，因为下单后，消息已经写入到消息队列后就不在关心后续操作，实现了订单系统和库存系统的解耦，而库存系统在恢复使用时，会从消息队列中取数进行库存操作。

流量削峰

场景：一般用于秒杀或者抢购活动中

可以控制活动的人数，缓解短时间内的高流量压垮应用

当用户的请求被服务器接收后，首先写入消息队列，假如消息队列长度超过最大的数量，比如抢购只有100台，已经有100个用户抢到了，那么就抛给其他用户失败的请求，抢购业务根据消息队列中的信息，再做后续处理。

虽然过来了很多请求，但是只处理了消息队列中的请求，达到了高可用

JMS(Java Message Service)

1、P2P(point to point)点对点模式

P2P模式包含三个角色：消息队列，发送者，接受者

每个消息都被发送到一个特点的队列，接受者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

P2P的特点：

1.每个消息只有一个消费者。(即一旦被消费，消息就不在消息队列中)

2.发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送消息之后，不管接收者有没有正在运行，它不会影响消息被发送到队列。

3.接收者在成功接收消息之后需向队列应答成功。

如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式

2、发布订阅模式

包含三个角色：主题，发布者，订阅者。

多个发布者将消息发送到Topic，系统将消息传递给多个订阅者。

Pub/Sub的特点

1.每个消息可以有多个消费者。

2.发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者，它必须创建一个订阅之后，才能消费发布者的消息

3.为了消费消息，订阅者必须保持运行的状态。

为了缓和这样的严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅，这样，即使订阅者没有被激活(运行)，它也能接收到发布者的消息。

如果希望发送的消息可以被多个消费者处理的话，那么可以采用发布者/消费者模型。

类似于看直播，得先订阅，后接收，也可能接收的时候都结束了

zookeeper+activeMQ集群（zookeeper安装）

实现原理

使用Zookeeper实现的Master-Slave实现方式，是对ActiveMQ进行高可用的一种有效的解决方案。高可用的原理：使用Zookeeper集群注册所有的ActiveMQ Broker。只有其中的一个Broker可以对外提供服务（也就是Master节点），其他Broker处于待机状态，被视为Slave。如果Master因故障而不能提供服务，则利用Zookeeper的内部选举机制从Slave中选举出一个Broker充当Master节点，继续对外提供服务。通过zookeeper+activeMQ实行的集群，可以有效的排除单点故障引起的服务中断。

Topic消息失败重发

当消息的接收方，没有成功消费消息，这时候需要重发消息 从而使消息的接收方消费消息，保证事务的完整性和数据一致性。

JMS的消息确认机制

在Session接口中定义的几个常量

AUTO_ACKONWLEDGE=1 自动确认：当接收方接收到消息时，给消息中间件确认

CLIENT_ACKOWLEDGE=2 客户端手动确认：当客户端成功接收并消费后，需要手动调用一个方法进行确认

DUPS_OK_ACKONWLEDGE=3 自动批量确认

SESSION_TRANSACTED=0 事务提交并确认

代码实现

消息消费端在创建Session对象时需要指定应答模式为客户端手动应答，当消息这获取到消息并成功处理后，需要调用message.acknowledge()方法进行应答，通知Broker消费成功。如果处理过程中出现异常，需要调用session.recover()通知Broker重复消息，默认最多重复6次。

//消息的发送方--生产者 @Test public void test1() throws JMSException{ //创建连接工厂对象 ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://127.0.0.1:61616"); //创建链接对象 Connection connection = connectionFactory.createConnection(); //链接MQ服务 connection.start(); //获取session对象并设置自动应答 Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); //通过session对象创建Topic Topic topic = session.createTopic("wcjTopic"); //通过session对象创建消息的发送者 MessageProducer producer = session.createProducer(topic); //通过session创建消息对象 TextMessage message = session.createTextMessage("ping..."); //发送消息 producer.send(message); //关闭相关资源 producer.close(); session.close(); connection.close(); } //消息的接收方--消费者 @Test public void test2() throws JMSException{ //创建连接工厂对象 ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://127.0.0.1:61616"); //创建链接对象 Connection connection = connectionFactory.createConnection(); //链接MQ服务 connection.start(); //获取session对象并设置自动应答 final Session session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE); //通过session对象创建Topic Topic topic = session.createTopic("wcjTopic"); //通过session对象创建消息的消费者 MessageConsumer consumer = session.createConsumer(topic); //指定消息监听器(如果存在并订阅了消息，就会自动执行) consumer.setMessageListener(new MessageListener() { //当监听的topic中存在消息，方法自动执行 @Override public void onMessage(Message message) { TextMessage textMessage = (TextMessage) message; try { if("ping".equals(textMessage.getText())){ System.out.println("消费者接收到了消息："+textMessage); //客户端手动应答 message.acknowledge(); }else{ System.out.println("消息处理失败了"); //失败重发 最多再次重发6次 session.recover(); //模拟消息失败 int i = 1/0; } } catch (JMSException e) { e.printStackTrace(); } } }); while(true){ } } 测试时： 1.先启动window的activeMq环境，否则连接不上 2.再启动接收方 3.最后启动发送方

消息的持久化订阅

没有持久化的话，当消费方没有启动的时候，生成方发生的消息，消费方是接收不到的

持久化到文件

1.在active.xml文件中配置持久化适配器(这个是默认就配好的)

2. 生产者发送消息时

设置持久化到文件

producer.send(message, DeliveryMode.PERSISTENT, 1, 1000*60*60*24);

3.消费者订阅时

//设置客户端id 用于区分不同id

connection.setClientID("id1");

//通过session对象创建消息的消费者 进行持久化订阅

MessageConsumer consumer = session.createDurableSubscriber(topic, "客户端订阅者");

4.测试流程

先启动消费方订阅消息后关闭服务，然后启动生产方发送消息，在消费方再次运行时，就可以看到了生产方刚才发送的消息，代表消息持久化成功！

持久化到Mysql数据库

1.将mysql数据库的驱动复制到activeMQ的lib目录中下

2.在activemq.xml中配置持久化适配器和数据连接池

3.测试流程

先启动消费方订阅消息后关闭服务，然后启动生产方发送消息，在消费方再次运行时，就可以看到了生产方刚才发送的消息，代表消息持久化成功！

只要生产方发送了消息，那么数据库就会产生记录，不论消费方是否先启服务