1、为什么要使用消息中间件
解耦 、异步、削峰
解耦:随着业务增长,模块之间耦合增加不利于维护开发。
异步:异步可以提高代码执行效率。
削峰:并发量大的时候,所有的请求直接怼到数据库,造成数据库连接异常。可以先放到队列中执行。
2、使用消息中间件有什么问题
系统可用性:刚开始系统用的好好的,然后被你拆分解耦,万一mq挂了,是不是砸蛋了。
系统复杂性增加:牵扯到生产者消费者,要保证生产者能一定生产,消费者一定消费,不可重复消费,消费数据不丢失。
但是哪怕是出现问题也是极少的,也是可以弥补的,该用还是要用的。
3、ActiveMQ,RabbitMQ,RocketMQ,Kafka如何选择
就吞吐量来说ActiveMQ,RabbitMQ是万级,RocketMQ,Kafka是十万级
都支持持久化。
时效性度差不多毫秒级,u秒级
ActiveMQ,RabbitMQ支持主从架构
RocketMQ,Kafka支持分布式(支持集群)可用性更高。
ActiveMQ社区已经不很活跃,更新维护部多,java写的。本身不支持集群,需要zookeeper,不支持分布式
RabbitMQ 是使用erlang,对于java程序员来说不可控实,人家是开源的,比较稳定的支持,活跃度也高;
RocketMQ是阿里的,经历双十一的洗刷,可靠,java写的,文档健全,开源,还可以使用阿里提供的服务,稳定可靠。没有在 mq 核心中去实现JMS 等接口,
大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的。
4、如何保证消息队列的高可用
以rcoketMQ为例,他的集群就有多master 模式、多master多slave异步复制模式、多 master多slave同步双写模式。多master多slave模式部署架构图
producer 与 NameServer集群中的其中一个节点(随机选择)建立长连接,定期从 NameServer 获取 Topic 路由信息,并向提供 Topic 服务的 Broker Master 建立长连接,且定时向 Broker 发送心跳。Producer 只能将消息发送到 Broker master,但是 Consumer 则不一样,它同时和提供 Topic 服务的 Master 和 Slave建立长连接,既可以从 Broker Master 订阅消息,也可以从 Broker Slave 订阅消息。
5、如何保证数据不被重复消费、不会生产失败
RabbitMQ是发送一个ACK确认消息,RocketMQ是返回一个CONSUME_SUCCESS成功标志,kafka实际上有个offset的概念
由于网络传输等等故障,确认信息没有传送到消息队列,导致消息队列不知道自己已经消费过该消息了,再次将该消息分发给其他的消费者。
1、在数据库存放消费的记录,做唯一索引
2、存放在redis里面,那消费者开始消费前,先去redis中查询有没消费记录即可。
生产者也有记录,有个状态status,如果失败的话用定时任务重新跑。还失败发邮件人工处理。
6、如何保证消息的可靠性
每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据
队列主要是持久化,设置deliveryMode
消费者集群不用考虑幂等性
mq集群就需要考虑
rocketMq功能全面,性能稳定,可靠,可按照顺序,拿来就用,推阿里的rocketmq。
什么是JMS?
JMS是java的消息服务,JMS的客户端之间可以通过JMS服务进行异步的消息传输。
消息方式:
点对点通讯,发布订阅
异步通讯无需等待
ActiveMQ消息签收机制:
客戶端成功接收一条消息的标志是一条消息被签收,成功应答。
消息的签收情形分两种:
1、带事务的session
如果session带有事务,并且事务成功提交,则消息被自动签收。如果事务回滚,则消息会被再次传送。
生产者和消费者session.commit();才会提交。
2、不带事务的session
不带事务的session的签收方式,取决于session的配置。
Activemq支持一下三種模式:
Session.AUTO_ACKNOWLEDGE 消息自动签收
Session.CLIENT_ACKNOWLEDGE 客戶端调用acknowledge方法手动签收
textMessage.acknowledge();//手动签收
Session.DUPS_OK_ACKNOWLEDGE 不是必须签收,消息可能会重复发送。在第二次重新传送消息的时候,消息只有在被确认之后,才认为已经被成功地消费了。
ActiveMQ 持久化
producer.setDeliveryMode(2);
@Configuration
public class QueueConfig {
@Value("${queue}")
private String queue;
@Bean
public Queue logQueue() {
return new ActiveMQQueue(queue);
}
@Bean
public JmsTemplate jmsTemplate(ActiveMQConnectionFactory activeMQConnectionFactory, Queue queue) {
JmsTemplate jmsTemplate = new JmsTemplate();
jmsTemplate.setDeliveryMode(2);// 进行持久化配置 1表示非持久化,2表示持久化</span>
jmsTemplate.setConnectionFactory(activeMQConnectionFactory);
jmsTemplate.setDefaultDestination(queue); // 此处可不设置默认,在发送消息时也可设置队列
jmsTemplate.setSessionAcknowledgeMode(4);// 客户端签收模式</span>
return jmsTemplate;
}
// 定义一个消息监听器连接工厂,这里定义的是点对点模式的监听器连接工厂
@Bean(name = "jmsQueueListener")
public DefaultJmsListenerContainerFactory jmsQueueListenerContainerFactory(
ActiveMQConnectionFactory activeMQConnectionFactory) {
DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
factory.setConnectionFactory(activeMQConnectionFactory);
// 设置连接数
factory.setConcurrency("1-10");
// 重连间隔时间
factory.setRecoveryInterval(1000L);
factory.setSessionAcknowledgeMode(4);
return factory;
}
}
jmsMessagingTemplate.convertAndSend(queue, "测试消息队列" + System.currentTimeMillis());
@JmsListener(destination = "${queue}")
public void receive(TextMessage text, Session session) throws JMSException {
try {
System.out.println("生产者第" + (++count) + "次向消费者发送消息..");
// int id = 1 / 0;
String value = text.getText();
System.out.println("消费者收到消息:" + value);
//手动签收
text.acknowledge();
} catch (Exception e) {
// 如果代码发生异常,需要发布版本才可以解决的问题,不要使用重试机制,采用日志记录方式,定时Job进行补偿。
// 如果不需要发布版本解决的问题,可以采用重试机制进行补偿。
// session.recover();// 继续重试
e.printStackTrace();
}
}
类型:
1、 P2P (点对点)
一对一
rocketMq 默认就是集群的
也可以设置广播
2、Pub/Sub (发布与订阅)
使用消息中间注意事项
- 消费者代码不要抛出异常,否则activqmq默认有重试机制。
- 如果代码发生异常,需要发布版本才可以解决的问题,不要使用重试机制,采用日志记录方式,定时Job进行补偿。
- 如果不需要发布版本解决的问题,可以采用重试机制进行补偿。
消费者如果保证消息幂等性,不被重复消费。
产生原因:网络延迟传输中,会造成进行MQ重试中,在重试过程中,可能会造成重复消费。
解决办法:
1.使用全局MessageID 判断消费方使用同一个,解决幂等性。
2.使用JMS可靠消息机制