消息队列是一种在应用程序之间传递消息的通信机制。它是一种典型的生产者-消费者模型,其中生产者负责生成消息并将其发送到队列中,而消费者则从队列中获取消息并进行处理。消息队列的主要目的是解耦生产者和消费者,使它们可以独立地进行工作,从而提高系统的可扩展性、可靠性和灵活性。它可以用于以下几个方面:
解耦系统组件:通过引入消息队列,系统中的不同组件可以通过消息进行通信,而无需直接依赖于彼此的实现细节。这样可以使系统更加灵活,降低组件之间的耦合度
异步处理:消息队列可以使生产者和消费者之间的通信变为异步的,生产者无需等待消费者处理消息就可以继续执行其他任务。这可以提高系统的响应速度和吞吐量
削峰填谷:消息队列可以作为一个缓冲区,帮助平衡生产者和消费者之间的速度差异。当生产者产生的消息量超过消费者处理的能力时,消息队列可以暂时存储消息,防止系统因消息堆积而崩溃
可靠性传输:消息队列通常提供可靠性传输的机制,确保消息在传输过程中不会丢失或损坏。这对于需要确保数据完整性和可靠性的系统非常重要
实现分布式系统:消息队列可以用于构建分布式系统,通过在不同节点之间传递消息来实现协作和通信。这对于构建大规模、高可用性的分布式系统非常有用
常见的消息队列:
ActiveMQ、RabbitMQ、RocketMQ、Kafka是常用的消息队列中间件,能够实现异步消息的发送和接收
区别:
总体来说,这些消息队列中间件各有特点,选择适合自己需求的消息队列是根据具体应用场景和需求来决定的。
生产者代码:
package com.rabbitmq.one;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.concurrent.TimeoutException;
/**
* 生产者:发消息
*/
public class Produce {
public static final String QUEUE_NAME="hello";
public static void main(String[] args) throws IOException, TimeoutException {
//创建工厂
ConnectionFactory factory = new ConnectionFactory();
//工厂IP连接rabbitmq
factory.setHost("118.31.6.132");
//用户名
factory.setUsername("admin");
//密码
factory.setPassword("123");
//创建连接
Connection connection = factory.newConnection();
//获取信道
Channel channel = connection.createChannel();
/*
*生成一个队列
* 1.队列名称
* 2.队列里面的信息是否持久化(磁盘)默认情况时在内存
* 3.该队列是否只供一个消费者进行消费 是否消费共享 true是允许
* 4.是否自动删除 最后一个消费者断开连接之后 该队列是否自动删除 true自动删除 false不自动删除
* 5.其他参数 延迟消息等
*/
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
//发消息
String message = "hello world";
/**
* 发送一个消息
* 1.发送到那个交换机
* 2.路由的KEY值是哪个 本次是队列的名称
* 3.其他参数信息
* 4.发送消息的消息体
*/
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
System.out.println("消息发送完毕!");
}
}
消费者代码:
package com.rabbitmq.one;
import com.rabbitmq.client.*;
import java.io.IOException;
import java.util.Collections;
import java.util.concurrent.TimeoutException;
/**
* 消费者
*/
public class Consume {
//队列名称
public static final String QUEUE_NAME = "hello";
//接受消息
public static void main(String[] args) throws IOException, TimeoutException {
//创建连接工厂
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("118.31.6.132");
factory.setUsername("admin");
factory.setPassword("123");
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
//声明 接受消息
DeliverCallback deliverCallback = (consumerTag,message)->{
System.out.println(new String(message.getBody()));
};
//取消消息的回调
CancelCallback cancelCallback = consumerTag->{
System.out.println("消息消费被中断");
};
/**
* 消费者信息
* 1.消费哪个队列
* 2.消费成功之后是否要自动应答 true自动应答 false手动应答
* 3.消费者微车才能更改消费的回调
* 4.消费者取消消费回调
*/
channel.basicConsume(QUEUE_NAME,true, deliverCallback,cancelCallback);
}
}
RabbitMQ、Kafka和RocketMQ是三种不同的消息队列中间件,它们在设计理念、特性和适用场景上有所不同:
RabbitMQ:
Kafka:
RocketMQ:
总的来说,RabbitMQ侧重于可靠性、灵活性和易用性,适用于大多数企业应用场景;Kafka侧重于处理大规模数据流、实时流处理和事件驱动架构;RocketMQ侧重于高吞吐量、低延迟和高可靠性的消息通信。选择合适的消息队列中间件取决于具体的需求和应用场景
RabbitMQ主要提供了以下几种消息类型:
这些类型的选择取决于你的具体需求,例如,你是否需要一个消息被多个消费者接收,或者你是否需要根据某种条件来过滤消息等等
RabbitMQ主要由以下几个重要组件组成:
这些组件共同工作,使得RabbitMQ能够提供强大的消息队列功能
RabbitMQ通过以下几种方式来保证消息的可靠性:
开启事务或者开启confirm模式:这两种方式都可以保证消息不丢失。事务模式会在消息发送过程中加锁,确保消息的可靠性,但是性能较低。而confirm模式则是在消息发送后,Broker会给生产者一个确认应答,告知消息已经正确到达,这种方式性能较高
开启RabbitMQ持久化:RabbitMQ提供了持久化功能,包括交换机、队列、消息的持久化。这样即使RabbitMQ服务重启,消息也不会丢失
关闭RabbitMQ自动ack,改成手动确认:这样可以防止消费者在处理消息过程中出现异常导致消息丢失的情况。当消费者收到消息并处理完成后,会给Broker发送一个ack应答,Broker收到应答后才会删除这条消息。如果Broker没有收到应答,那么这条消息会被重新投递给其他消费者
RabbitMQ可以保证消息的顺序性,主要通过以下方式实现:
创建多个队列:每个消费者固定消费一个队列的消息,这样就可以保证每个消费者处理的消息是有序的
生产者发送消息时,同一个订单号的消息发送到同一个队列中:由于同一个队列的消息是一定会保证有序的,那么同一个订单号的消息就只会被一个消费者顺序消费
这样,RabbitMQ就可以保证消息的顺序性了。但需要注意的是,这种方式需要在生产者端进行一定的控制,以确保同一个订单号的消息被发送到同一个队列中。同时,消费者端也需要进行相应的处理,以确保消息的顺序消费
RabbitMQ可以通过以下方式来保证幂等性:
每个消息用一个唯一标识来区分:消费前先判断标识有没有被消费过,若已消费则不再消费
利用数据库的乐观锁机制:执行更新操作前先去数据库查询version,然后执行更新语句,以version作为条件
使用Redis的命令:Redis中的set命令天然支持幂等,消息消费时,只需要用set命令来判断消息是否被消费过即可
全局唯一ID + Redis:生产者在发送消息时,为每条消息设置一个全局唯一的messageId,消费者拿到消息后,使用setnx命令,将messageId作为key放到redis中:setnx (messageId,1),若返回1,说明之前没有消费过,正常消费;若返回0,说明这条消息之前已消费过,抛弃
以上就是RabbitMQ保证幂等性的主要方式。但需要注意的是,这种方式需要在生产者端进行一定的控制,以确保同一个订单号的消息被发送到同一个队列中。同时,消费者端也需要进行相应的处理,以确保消息的顺序消费
死信,顾名思义就是无法被消费的消息,字面意思可以这样理解,一般来说,producer将消息投递到broker或者直接到queue里了,consumer从queue取出消息进行消费,但某些时候由于特定的原因导致queue中的某些消息无法被消费,这样的消息如果没有后续的处理,就变成了死信,有死信,自然就有了死信队列
消息变成死信有以下几种情况:
死信的产生既然不可避免,那么就需要从实际的业务角度和场景出发,对这些死信进行后续的处理,常见的处理方式大致有下面几种:
综合来看,更常用的做法是第三种,即通过死信队列,将产生的死信通过程序的配置路由到指定的死信队列,然后应用监听死信队列,对接收到的死信做后续的处理。
延迟队列是一种特殊的消息队列,进入该队列的消息会被延迟消费。也就是说,消息一旦入队了之后并不会立即被消费者消费,而是需要等待一段时间后才能被消费。延迟队列的使用场景非常广泛,以下是一些常见的例子
以上就是延迟队列的基本概念以及一些常见的使用场景。在实际开发过程中,根据具体的业务需求,延迟队列可以有更多的应用场景
RabbitMQ实现延迟队列主要有两种方式:
利用RabbitMQ的TTL(Time To Live)特性和死信队列:消息在TTL设置的时间内没有被消费,则会成为“死信”并进入死信队列。具体步骤如下:
queue_normal
queue_dead
queue_normal
设置参数x-dead-letter-exchange
和x-dead-letter-routing-key
,值分别为queue_dead
的交换器和路由键queue_normal
中的消息变为“死信”时,这些消息会被自动路由到queue_dead
使用RabbitMQ的插件 rabbitmq_delayed_message_exchange
:这是一个官方提供的插件,可以直接用来实现延迟队列。具体步骤如下:
rabbitmq_delayed_message_exchange
插件x-delay
属性,该属性表示消息延迟的时间x-delay
设置的时间后被投递到消费者以上就是RabbitMQ实现延迟队列的主要方式。需要注意的是,这两种方式都需要在生产者端进行一定的控制,以确保消息的延迟投递。同时,消费者端也需要进行相应的处理,以确保消息的顺序消费
RabbitMQ保证高可用主要通过以下几种方式:
集群部署:RabbitMQ可以通过搭建集群来提高其高可用性。集群中的每个节点都可以处理消息,如果某个节点出现故障,其他节点仍然可以继续处理消息
镜像队列:RabbitMQ提供了镜像队列的功能,可以将队列的数据同步到多个节点,这样即使某个节点出现故障,其他节点上的镜像队列仍然可以提供服务
持久化:RabbitMQ提供了持久化机制,可以将交换器、队列、消息进行持久化,这样即使RabbitMQ服务重启,消息也不会丢失
消息确认机制:RabbitMQ提供了消息确认机制,包括生产者的confirm机制和消费者的ack机制,可以确保消息在网络环境不稳定的情况下也能正确地被发送和接收
同城双活部署架构:RabbitMQ集群采用同城双活部署架构,依靠MQ-SDK和MQ-NameServer提供的集群寻址、故障快速切换等能力保障集群的可用性
以上就是RabbitMQ保证高可用的主要方式。需要注意的是,这些方式需要在RabbitMQ的配置和使用中进行适当的设置和操作
Kafka的高速运行主要归功于以下几种优化方式:
顺序写入:Kafka中每个分区是一个有序的,不可变的消息序列,新的消息不断追加到partition的末尾,这就是顺序写。顺序写入可以提高磁盘I/O的性能,因为磁盘最喜欢顺序I/O
零拷贝技术:Kafka在读取的时候使用了零拷贝技术,降低对文件的拷贝次数,一定程度上提升了速度
大量使用页缓存:Kafka充分利用了操作系统的页缓存来提高I/O效率。页缓存是操作系统对数据文件的读写提供的一种缓冲技术,目的是为了减少I/O操作的次数
利用Partition实现并行处理:每个Topic都包含一个或多个Partition,不同Partition可位于不同节点,因此可以充分利用集群优势,实现机器间的并行处理
以上就是Kafka能够快速运行的主要原因。需要注意的是,这些优化方式需要在Kafka的配置和使用中进行适当的设置和操作
Kafka的选举流程主要是以下几步:
创建Leader父节点:在Zookeeper中创建一个名为/kafka的持久节点
各客户端竞争Leader:各客户端在/kafka下创建Leader节点,如/kafka/leader,这个节点被设置为ephemeral_sequential类型,表示这是一个临时的顺序节点
获取所有子节点并比较:客户端通过getChildren方法获取/kakfa/下所有子节点,然后比较其注册的节点的id和所有子节点中的id,如果其id在所有子节点中最小,则当前客户端竞选Leader成功
处理Leader故障:如果Leader由于某些原因(如网络故障或者异常退出)与Zookeeper断开连接,那么其他broker通过watch收到控制器变更的通知,就会去尝试创建临时节点/controller,如果有一个Broker创建成功,那么其他broker就会收到创建异常通知,也就意味着集群中已经有了控制器,其他Broker只需创建watch对象即可
防止控制器脑裂:为了解决Controller脑裂问题,ZooKeeper中还有一个与Controller有关的持久节点/controller_epoch,存放的是一个整形值的epoch number(纪元编号,也称为隔离令牌),集群中每选举一次控制器,就会通过Zookeeper创建一个数值更大的epoch number,如果有broker收到比这个epoch数值小的数据,就会忽略消息