测试面试之RocketMq

消息重复消费如何解决？
影响消息正常发送和消费的重要原因是网络的不确定性。
引起重复消费的原因：
ACK：
正常情况下在consumer真正消费完消息后应该发送ack，通知broker该消息已正常消费，从queue中剔除
当ack因为网络原因无法发送到broker，broker会认为词条消息没有被消费，此后会开启消息重投机制把消息再次投递到consumer
消费模式：
在CLUSTERING模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同group的consumer会推送多次
解决方案：
数据库表：
处理消息前，使用消息主键在表中带有约束的字段中insert
Map：
单机时可以使用map ConcurrentHashMap -> putIfAbsent guava cache
Redis：
分布式锁搞起来。
当消费负载均衡consumer和queue不对等的时候会发生什么？
Consumer 和 queue 会优先平均分配，如果 Consumer 少于 queue 的个数，则会存在部分 Consumer 消费多个 queue 的情况，如果 Consumer 等于 queue 的个数，那就是一个 Consumer 消费一个 queue，如果 Consumer 个数大于 queue 的个数，那么会有部分 Consumer 空余出来，白白的浪费了。
RocketMQ Broker中的消息被消费后会立即删除吗？
不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。
4.6版本默认48小时后会删除不再使用的CommitLog文件
检查这个文件最后访问时间
判断是否大于过期时间
指定时间删除，默认凌晨4点
RocketMQ由哪些角色组成，每个角色作用和特点是什么？
Producer：消息的发送者；举例：发信者
Consumer：消息接收者；举例：收信者
Broker：暂存和传输消息；举例：邮局
NameServer：管理Broker；举例：各个邮局的管理机构
Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者 可以订阅一个或者多个Topic消息
Message Queue：相当于是Topic的分区；用于并行发送和接收消息
依托消息中间件如何实现异步？
引入了MQ后，用来的依赖关系转移了，从系统之间的依赖，变成系统都依赖MQ
A调用B，只需要向MQ发送一条消息，A就认为自己的工作完成了。不用像之前调用B一样等着B处理一堆的业务逻辑和数据库操作。
B会从MQ中读取A发送的特定消息，完成自己该做的事情。
这样就实现了A异步调用B
RocketMq 消费的两种模式？
集群消费模式/负载均衡模式（CLUSTERING）：由brocker 对消费者进行分发，起到一个负载均衡的中；9 条消息，3个消费者，每个消费者消费3条数据；
广播消费模式（BROADCASTING）:订阅了此消息的消费者都会进行消费；9条消息，三个消费者，