RocketMq随机写
一，概念：
Broker的集群部署有多种：
- 单Master
- 多Master多Slave（同步双写）
- 多Master多Slave（异步双写）
名称服务器： 用来保存Broker相关元信息并给生产者和消费者查找Broker信息。每个Broker在启动时都会到名称服务器中注册，生产者在发送消息前根据主题到名称服务器中获取到Broker的路由信息，消费者也会定时获取主题的路由信息。
消息消费模式：集群消费和广播消费。默认是集群消费。
消息顺序有两种：顺序消费和并行消费。
顺序消费的原理是确保将消息投递到同一个队列中，在队列内部RocketMq保证先进先出。
消息重试概念
生产者端重试：指当生产者向Broker发送消息时，如果由于网络抖动等原因导致消息发送失败，此时可以通过手动设置发送失败重试次数的方式让消息重发一次。
消费者端重试：消费者端的失败一般分为两种情况，一是由于网络等原因导致消息没法从Broker发送到消费者端，这时在RocketMq内部会不断尝试发送这条消息，直到发送成功为止（比如向集群中的一个Broker实例发送失败，就尝试发往另一个Broker实例）；二是消费者端已经正常接收到了消息，但是在执行后续的消息处理逻辑时发生了异常，最终反馈给MQ消费者处理失败，例如所接收到的消息数据可能不符合本身的业务要求，如当前卡号未激活不能执行业务等，这时就需要通过业务代码返回消息消费的不同状态来控制。
消息重复概念
理论上，所有的MQ产品在消息投递时都会面临三种模式，即：至少一次（at least once）、最多一次（at most once）、只有一次（exactly once）。
至少一次：
指如果消息没有接收成功，则可能会重发一直到接收成功为止。
最多一次：
指消息指发送一次，不管发送的结果是成功还是失败都不会重发。
只有一次的语义可以分成两部分解释：
一是在消息发送时不允许发送重发的消息；
二是在消息消费时也不允许消费重发的消息。只有这两个条件都满足时，才能认为是只有一次的。
RocketMq能保证消息至少被投递一次，即支持至少一次模式，但不支持只有一次模式。
消息重复解决方案：
- 消费消息做幂等性（所谓幂等是指同样的入参，即使多次调用某个接口，对系统的影响也是一种的），只要做保持幂等性，不管来多少条重复消息，最后处理的结果都是一样的。
- 保证每条消息都有一个唯一标识，然后用一个消息处理日志表来记录已经处理成功的消息ID，假如新到的消息其ID已在日志表中，则不再处理这条消息。
消息丢失解决方案：
同步刷盘，是指生产者发送的消息都要等到消息数据保存到Broker的磁盘成功后才向生产者返回成功信息。采用这种方式可以避免消息丢失，但是对性能有一定的影响，因为它有很大的磁盘I/O开销。
异步刷盘，是指生产者发送的消息并不需要先保存到磁盘中，而是先缓存起来之后就向生产者返回成功消息，然后再将缓存的数据异步保存到磁盘中。这里有两种情况：一是定期刷盘缓存中的数据；二是如果缓存中的数据达到所设定的阀值就刷盘。异步刷盘在消息数据还没来得及同步到磁盘中时就宕机的情况下回导致少量消息丢失，但这种方式的性能比较高。
以上是 RocketMq随机写 的全部内容， 来源链接： utcz.com/z/518646.html
