> 文章列表 > rocketmq面试

rocketmq面试

rocketmq面试

## MQ ##
作用:流量消峰,应用解耦,消息缓存成员:
Producer:消息的发送者;举例:发信者
Consumer:消息接收者;举例:收信者
Broker:暂存和传输消息;举例:邮局
NameServer:管理Broker;举例:各个邮局的管理机构
Topic:区分消息的种类;一个发送者可以发送消息给一个或者多个Topic;一个消息的接收者可以订阅一个或者多个Topic消息
Message Queue:相当于是Topic的分区;有多个消息队列(导致分区有序),用于并行发送和接收消息生产者: DefaultMQProducer->设置地址->开启->发送->关闭
消费者: DefaultMQPushConsumer->设置地址->设置监听->开启消息类型:单向消息: producer.sendOneway(message)同步消息: 常规发送,全局有序producer.send(message, new MessageQueueSelector()),分区顺序producer.send(message)异步消息: producer.send(message, new SendCallback()),异步发送注意不能关闭发送端太早,否则没发送出去会报错延时消息: 给msg设置即可message.setDelayTimeLevel(3),等级是mq自己定义的,3是30秒事务消息: 发送端确保下消息发送成功,使用TransactionMQProducer,设置事务监听器TransactionListener,使用producer.sendMessageInTransaction(message,null)发送消息;事务监听器:TransactionListener,设置事务的处理方式,提交,回滚,中间状态public interface TransactionListener {//正常事务,进行各种消息判断,正常情况下,mq在收到消息,会给发送端做回复,确保消息正常发送LocalTransactionState executeLocalTransaction(Message var1, Object var2);//事务补偿:在生产端发送给mq后没有收到mq的回复,然后需要做的操作LocalTransactionState checkLocalTransaction(MessageExt var1);}消费模式,设置subscribe("topic","表达式"):负载均衡那消费:mq将消息轮询到各个消费端,默认的模式广播消费:各个消费者处理的消息是相同的顺序消息: rocketmq会将接受的消息轮询到不同的队列,会造成各个队列的有序,但是并不能保证先发先消费,只是相对有序全局有序:全局按照消息的发送顺序处理消息,某个消息消费不了会一直被阻塞发送端: 发送消息时候确保相同消息在相同队列,通过MessageQueueSelector()对象,指定相同消息发送到mq队列的指定列表消费端: 注册单线程监听器consumer.registerMessageListener(new MessageListenerOrderly()),加锁强制某个线程只对某个队列消息式进行消费,也就是单线程处理某个队列producer.send(message, new MessageQueueSelector() {@Overridepublic MessageQueue select(List<MessageQueue> list, Message message, Object o) {//全部放在第一个队列,实际使用时候是根据不同的消息放在不同的队列,确保有序return list.get(1);}},null);分区有序: mq将收到的消息存在不同的队列,只能保证在相同的队列中的消息按序消费发送端: 常规发送消费端: 注册MessageListenerConcurrently,多线程模式进行消费消息持久化:存数据库:数据库的读写慢,造成发送端的消息瓶颈刷盘:存本地磁盘磁盘随机写:cpu决定,内存的空间有其他数据不连续,读写慢顺序写: 读写快,rocketmq为实现顺序写,会提前占内一块连续存,当自己有数据时,进行写入同步刷盘:一个消息一次写如不会丢失消息,写如操作会耗时异步刷盘:积攒消息后写如,宕机会丢失消息死信: 消费端处理消息出现问题,没有给mq做出回复,若是顺序消息直接就阻塞,若是普通消息会重试,当重试次数上限该消息会被加入死信队列处理方式: 根据消息id消费即可重复消费:
原因:生产端和mq的问题: 生产端给mq发送没有收到mq的回复,mq或者生产端网络抖动,生产端重发,造成消息重复消费端和mq的问题: 消费端将消息消费了,但是没有给mq回复,mq将消息重试
消费幂:保证同样一个消息只消费一次,这个mq做不到,只能在消费端做,我们做业务时候根据业务的id做判断,相同的业务只做一次即可,数据库写操作先查是否已经做过相同的操作,没有在做对应业务操作mq的负载均衡: mq内部已经对消费端和生产端实现轮询等均衡策略mq集群:单master多master多master,多slave主从复制:同步复制:一个消息复制一次异步复制:积攒复制方式:配置一下配置文件,主从通讯不是通过日志,是直接读取发送的事务消息:发送消息(half消息)。服务端响应消息写入结果。根据发送结果执行本地事务(如果写入失败,此时half消息对业务不可见,本地逻辑不执行)。根据本地事务状态执行Commit或者Rollback(Commit操作生成消息索引,消息对消费者可见)