系统组件之间或者应用之间耦 合较紧，消费者出现任何问题 （升级停服、宕机、不可用等 ），都会影响生产者的业务。 系统可用性和效率较低。

突发的海量消息压力，消费者无法实 时高效的处理消息时，容易产生雪崩 效应。没有消息持久化机制，系统发 生故障会丢失消息。

消息存在本地内存中，单机的 处理能力和内存容量都是有限 的，不具备可扩展性，同时系 统组件高度耦合，扩展难度大。

Erlang编写， 重量级，路由(Routing)，负载均衡(Load balance)或者 数据持久化。

轻量级，非持久性的队列，必须学习它的80页的手册。

scala语言开发，轻量级、高吞吐，快速持久化，客户端需要自己测试和开发。

耦合系统中，消费者出现任何问题（ 升级停服、宕机、不可用等），都会 影响生产者的业务。使用CMQ提供的松耦合服务，生产 者无需了解消费者，消费者无需关心 生产者，系统很方便地做到异步化。

对于突发流量，数据可先堆 积在CMQ server，消费者按 照实际能力来消费，防止雪 崩效应和消息丢失。

数据生产一次并堆积到CMQ server，不同消费场景可多次复 用。例如订单数据生产一次，逻 辑、业务、计费、监控、统计模 块都可以消费。

客户端生产的消息在broker 刷盘成功后会返回确认消息告知生产消息成功。如果在一定时间之内客户端没有收到确认信息需要重试来确保消息发送成功。

消费者拉取消息时会指定当前消息的隐藏时间，在隐藏时间内消费者比较显式的对消息进行确认删除， 如果超过隐藏时间没有主动删除， 此条消息将重新对外可见，可以继续消费。

消息服务每条消息在返回给用户写成功之时就确保数据已被复制3份写到不同物理机上，并且后台数据复制机制保证任何一台物理机故障时其上的数据能够快速迁移，时刻保证用户数据3份副本可用，可靠性达99.999999%；采用Raft一致性算法，保证数据强一致性。

消息回溯（rewind）接口为Queue属性，修改后，所有消费者都遵循最新的rewind时间轴进行消费。 1、回溯的时间点，只允许指定消息已删除，但处于消息可回溯周期之内的时间点。 2、rewind支持修改，也只能重新选择，消息可回溯区间内的时间点。 3、指定后，所有消费者，将从指定的时间点（在可回溯范围内），开始消费，一直消费到当前时间。 4、当指定了早于可回溯范围的时间点进行回溯时，会报错，接口会自动指定『最近的可回溯时间点』。

死信队列称为Dead letter Exchange。主要满足2种场景下的诉求： 1、便于定位问题：如可设定，某条消息，被多次消费后，却未被删除。这种情况下往往是该消息未被正确的消费。可能存在问题需要回溯定位。 可设置最大消费次数。超额后，该消息会被淘汰到指定的死信队列。便于后续问题发现。 2、优先级队列：还可以用作优先级处理，如摩拜单车等o2o客户，对访问时延、实时性要求非常高。如单车开锁逻辑，当MQ中堆积了1亿 条消息时，会优先处理最新生产的部分消息，老的消息淘汰到死信队列，当消费者有能力时。再处理 （往往老的消息，比如用户扫码开车 ，在等待时已流失了，老的消息的价值会偏小。建议优先处理最新的消息）。

事务消息。主要满足以下场景的诉求：由于传统的处理方式无法解决消息生成者本地事务处理成功与消息发送成功两者的一致性问题，因此事务消息就诞生了，它实现了消息生成 者本地事务与消息发送的原子性，保证了消息生成者本地事务处理成功与消息发送成功的最终一致性问题。用户实现类似 X/Open XA 的分布事务功能，通过CMQ事务消息能达到分布式事务的最终一致。