学习中产生的问题
问题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();
}
}
});
}
测试时:
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中配置持久化适配器和数据连接池
<persistenceAdapter>
<jdbcPersistenceAdapter directory="${activemq.base}/data" dataSource="#derby-ds"/>
</persistenceAdapter>
<bean id="derby-ds" class="org.apache.commons.dbcp2.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/activemq"/>
<property name="username" value="root"/>
<property name="password" value="root"/>
<property name="poolPreparedStatements" value="true"/>
</bean>
3.测试流程
先启动消费方订阅消息后关闭服务,然后启动生产方发送消息,在消费方再次运行时,就可以看到了生产方刚才发送的消息,代表消息持久化成功!
只要生产方发送了消息,那么数据库就会产生记录,不论消费方是否先启服务