云消息队列

结合使用RocketMQ开源自建集群的痛点，以及阿里云商业实例的优势，分析迁移上云的必要性； 对比常见的消息迁移方案，解析阿里云迁移上云方案如何保障用户以较低成本完成业务无缝迁移； 演示阿里云迁移上云方案的整体流程，上手完成从开源自建集群迁移到阿里云商业实例的完整过程。

本文章为创建专用网络VPC操作指引。

当消费者消费消息失败时， RocketMQ 会按照最大重试次数重新投递该消息进行故障恢复。在集群模式下，消费的业务逻辑代码会返回消费失败状态，或者抛出异常，如果一条消息消费失败，则会按照设置的最大重试次数重试，之后该消息会被丢弃。

对于一个指定的 Topic，同一 MessageGroup 的消息按照严格的先进先出（FIFO）原则进行发布和消费，即先发布的消息先消费，后发布的消息后消费，服务端严格按照发送顺序进行存储、消费。

在分布式系统调用场景中存在这样一个通用问题，即在执行一个核心业务逻辑的同时，还需要调用多个下游做业务处理，而且要求多个下游业务和当前核心业务必须同时成功或者同时失败，进而避免部分成功和失败的不一致情况出现。简单来说，消息队列中的“事务”，主要解决的是消息生产者和消费者的数据一致性问题。

消息堆积是指由于消费者的消费能力有限，未能在短时间内将所有消息正确消费掉，此时在服务端保存着未被消费的消息的状态。在 RocketMQ 中，消息堆积可以通过 Metrics 指标来衡量，这些指标可直接反映队列中消息的处理速率和堆积情况。

定时消息是生产者将一条消息发送到消息队列后并不期望这条消息马上会被消费者消费到，而是期望到了指定的时间，消费者才可以消费到。

在多种消息类型中，普通消息是最简单也最为重要。普通消息是 RocketMQ 的基本消息类型，提供高吞吐、扩展、低延迟、异步的通信能力。