消息中间件之RocketMQ(三)

常见问题

1.重复消费

• 产生的原因是发送消息时采用了多数分布式消息中间件产品提供的最少一次(at least once)的投递保障，对于这个问题最常见的解决方案,就是消息消费端实现业务幂等，只要保持幂等性，不管来多少条重复消息，最后处理的结果都是一样的
• 保障策略有at most once 最多消费一次， at least once 最少消费一次， exactly once 刚好一次，RocketMQ不支持exactly once只有一次的模式，因为要在分布式系统下实现发送不重复并且消费不重复，将会产生非常大的开销，RocketMQ为了追求高性能并没有支持此特性
  其实该问题的本质时网络调用存在不确定性，即既不成功也不失败的第三种状态，所以才会产生消息重复的问题

2.为什么RocketMQ不用ZooKeeper而要自己实现一个NameServer来注册?

为什么要RocketMQ自己实现注册中心，而不是用Zookeeper，Nacos？

3.Consumer分组有什么用? Producer分组的作用?

• Producer Group
• 生产者组(ProducerGroup)是一类生产者地集合，这类生产者通常发送一类消息并且发送逻辑一致，所以将这些生产者分组在一起,从部署结构上看，生产者通过生产者组的名字来标识自己是一个集群
• 事务消息回查机制，可以使用到,同一个生产者组的生产消息逻辑是相同的，所以当事务消息向Broker提交本地事务不成功时，有可能是在执行完本地事务之后宕机的，那么Broker只需要向同一个Producer Group中的任意一个Producer调用事务回查就可以获取到本地事务的执行结果
• Consumer Group
• 消费者组(ConsumerGroup)是一类消费者的组合，这类消费者通常消费同一类消息并且消费逻辑一致，所以将这些消费者分组在一起，消费者组于生产者组类似，都是将相同角色的消费者分组在一起并命名的。分组是一个很精妙的概念设计，RocketMQ正是通过这种分组机制，实现了天然的消息负载均衡。
  消费消息时，通过消费者组实现了将消息分发到多个消费者服务器实例，比如某个主题由9条消息，其中,一个消费者组由3个实例(3个进程或者3台机器),那么每个实例将均摊3条消息，也就意味着我们可以很方便地通过增加机器来实现水平扩容

4.哪些环节会有丢消息的可能

这4个环节都有丢消息的可能

5.RocketMQ消息零丢失方案

1.生产者使用事务消息机制保证消息零丢失

1.1.1.为什么要发送这个half消息?有什么用

这个Half消息时在订单系统进行下单操作前发送，并且对下游服务的消费者是不可见的。
那这个消息的作用更多的体现在确认RocketMQ的服务是否正常。相当于嗅探下RocketMQ
服务是否正常，并且通知RocketMQ,我马上就要发一个很重要的消息了，你做好准备