消息队列 CMQ 版参数差异说明

一、消息生命周期

新版 CMQ 采用了业界通用的消息生命周期模型，即通过“最长未确认时间”(TTL, Time to Live) 来避免产生过量的堆积导致消息队列负载过高（消息堆积容量达到100%以上时会触发不可写入）。

相较于原版 CMQ，新版 CMQ 增设了消息最大未确认时间，范围30秒到12小时，如果消息在发送成功后，超过此时间消息仍然未被确认（ack），则服务端会自动确认该消息。

未确认的消息将持续保存在 MQ 中不会删除，已确认的消息受到消息可回溯时间大小和可回溯磁盘空间的作用（如果消息所在的队列没有打开消息回溯开关，则消息会在确认后直接删除）。

新版 CMQ 取消了消息生命周期的限制。默认不再支持消息长时间在队列中堆积，如有特殊需要可以开启消息回溯并设置可回溯的时间范围，只有开启了消息回溯的消息才允许在消息队列中保存超过12小时，开启后会产生一定的存储费用，具体计费请参考新版 CMQ 计费说明。

注意：从原 CMQ 迁移到新 CMQ 的队列会将消息生命周期继承到消息最大未确认时间，以确保原有业务正常，下次手动调整不得超出30秒 – 12小时范围，调整时请留意客户端相关的处理逻辑。

新版 CMQ 取消了原版 CMQ 关于消息堆积条数的限制，理论上只要存储资源满足，可以无限堆积。但实际从硬件层面出发，我们会给每个队列分配10GB的最大堆积存储资源，并支持你通过该值配置对应的云监控告警。

一般平均1KB大小的消息可以堆积大约1千万条，可以依据此进行简单换算，如发现迁移后此处可能存在堆积超过上限的风险，可以及时通过工单与我们联系。

新版 CMQ 不再支持设置消息大小上限，为不影响业务从原 CMQ 迁移，新增队列统一设定为原 CMQ 的消息大小上限，即1024KB。

注意：从原 CMQ 迁移过来的队列不再支持设置消息大小，如需增加限制，请重新创建队列使用。

参数意义完全相同，但是其作用效果在新版 CMQ 和原 CMQ 上有所不同，新版中该参数推荐设置到3s以下。

在新版 CMQ 中，如果消息接收长轮询等待时间设置的过大，由于底层需要保证“至少一次”的语义，可能导致消息投递的重复率显著增高，从而对于一些未做消息去重的下游业务系统产生较大影响。因此，如果希望减少消息重复的概率，可以尽量设置的小一些，推荐3秒，3秒以下基本不会产生重复投递。

新版 CMQ 增设了未确认消息容量的限制，这样可以保障 MQ 服务端的内存消耗得到控制从而确保稳定性。不可见消息过多一般是客户端未及时 ACK 导致的，该指标有对应的监控图表进行监控，如有明显突增，请尽快检查消费者的确认删除逻辑是否正常运行，如突发性容量不足请尽快提交工单申请。

在旧版 CMQ 迁移后，消息的主要字段变化如下：

主要差异点：

·msgId 升级前由纯数字组成，升级后变成字母加数字组成。

·receiptHandle 升级前由纯数字组成，升级后变成字母数字下划线中划线组成。