新版 CMQ 与原 CMQ 参数差异说明
新版 CMQ 在数据流（消息收发）SDK 的用法和语法上与原 CMQ 一致，但有些参数与特性会和原 CMQ 有一定的差异。这些差异新版 CMQ 会通过特殊设置这些参数来保证在您迁移之后不会改变原有的生产消费逻辑，但如果是新建的队列或主题则尽可能参考新 CMQ 的逻辑进行设置。
消息生命周期
新版 CMQ 采用了业界通用的消息生命周期模型，即通过“最长未确认时间”(TTL, Time to Live) 来避免产生过量的堆积导致消息队列负载过高（消息堆积容量达到100%以上时会触发不可写入）。
相较于原版 CMQ，新版 CMQ 增设了消息最大未确认时间，范围30秒到12小时，如果消息在发送成功后，超过此时间消息仍然未被确认（ack），则服务端会自动确认该消息。
未确认的消息将持续保存在 MQ 中不会删除，已确认的消息受到消息可回溯时间大小和可回溯磁盘空间的作用（如果消息所在的队列没有打开消息回溯开关，则消息会在确认后直接删除）。
新版 CMQ 取消了消息生命周期的限制。默认不再支持消息长时间在队列中堆积，如有特殊需要可以开启消息回溯并设置可回溯的时间范围，只有开启了消息回溯的消息才允许在消息队列中保存超过12小时，开启后会产生一定的存储费用，具体计费请参考新版 CMQ 计费说明。
说明
从原 CMQ 迁移到新 CMQ 的队列会将消息生命周期继承到消息最大未确认时间，以确保原有业务正常，下次手动调整不得超出30秒 - 12小时范围，调整时请留意客户端相关的处理逻辑。
消息堆积上限
新版 CMQ 取消了原版 CMQ 关于消息堆积条数的限制，理论上只要存储资源满足，可以无限堆积。但实际从硬件层面出发，我们会给每个队列分配10GB的最大堆积存储资源，并支持您通过该值配置对应的云监控告警。
消息大小
新版 CMQ 不再支持设置消息大小上限，为不影响业务从原 CMQ 迁移，新增队列统一设定为原 CMQ 的消息大小上限，即1024KB。
说明
从原 CMQ 迁移过来的队列不再支持设置消息大小，如需增加限制，请重新创建队列使用。
消息接收长轮询等待时间
参数意义完全相同，但是其作用效果在新版 CMQ 和原 CMQ 上有所不同，新版中该参数推荐设置到3s以下。
在新版 CMQ 中，如果消息接收长轮询等待时间设置的过大，由于底层需要保证“至少一次”的语义，可能导致消息投递的重复率显著增高，从而对于一些未做消息去重的下游业务系统产生较大影响。因此，如果希望减少消息重复的概率，可以尽量设置的小一些，推荐3秒，3秒以下基本不会产生重复投递。
未确认消息容量
新版 CMQ 增设了未确认消息容量的限制，这样可以保障 MQ 服务端的内存消耗得到控制从而确保稳定性。不可见消息过多一般是客户端未及时 ACK 导致的，该指标有对应的监控图表进行监控，如有明显突增，请尽快检查消费者的确认删除逻辑是否正常运行，如突发性容量不足请尽快 提交工单 申请。
消息字段差异说明
在旧版 CMQ 迁移后，消息的主要字段变化如下：
参数 | 类型 | 升级前样例 | 升级后样例 |
msgId | String | 190990635761933 | 1EBCFC0F00446767C1FC4F9D23E5AB1C |
receiptHandle | String | 687663623513305190 | 0_1692158549574_30000_6_0_rmqbroker-gz-cmq-tencent-1_0_0 |
msgBody | String | i am topic message | i am topic message |
enqueueTime | Long | 1692155398 | 1692155398 |
nextVisibleTime | Long | 1692158424 | 1692158424 |
firstDequeueTime | Long | 1692158394 | 1692158394 |
dequeueCount | Int | 1 | 1 |
requestId | String | 69132918877847580 | 1107461132886449801 |
主要差异点：
msgId 升级前由纯数字组成，升级后变成字母加数字组成。
receiptHandle 升级前由纯数字组成，升级后变成字母数字下划线中划线组成。