兼顾性能与可靠性，单 CMQ 实例 QPS 达到5000
数据可靠性与性能无法兼顾

队列数量及队列存储容量可扩展性强
底层系统根据业务规模，自动弹性伸缩，上层业务无感知
高效支持亿级消息收发、推送，堆积，容量不设上线
提供北京、上海地域的多地域服务
队列数量和消息堆积数量有限
每个IDC机房必须重新部署购买设备、部署，非常繁琐

消息服务每条消息在返回给用户写成功之时就确保数据已被复制3份写到不同物理机上，并且后台数据复制机制能够保证任何一台物理机故障时其上的数据能够快速的做迁移，时刻保证用户数据3份 copy 可用，可靠性达99.999999%
引入改良后的Raft一致性算法，保证数据强一致性
业务可用性承诺：99.95%
数据单机或简单主从结构，存在数据单点问题，一旦丢失不可回溯
开源的 replicia 算法，在集群新增、删除服务器节点时，会引发全局的数据重新均衡，引起可用性急剧下降
如 Kafka 使用异步刷盘方式， 异步 Replication，无法保证数据强一致性

多纬度的安全防护和防DDoS攻击服务
每个消息服务提供单独命名空间，客户间数据严格隔离
支持HTTPS访问
支持跨地域的安全消息服务
安全防护功能有限
考虑到公网的网络威胁，常常无法提供跨地域、跨IDC的公网服务

应用需要确保消息的可靠传递，即使发送消息时接收者由于断电、宕机或cpu负载过高等原因不可用，消息也可以在接收者可用时被送达。传统的消息队列把消息储存在内存中，故而不具备这一功能。云平台CMQ分布式消息队列中的消息会被持久化保存，直到接收者成功获取它。

需要在访问量与日俱增、囤积在队列中的消息数日益增长的情况下也能正常运转。传统的消息队列把消息存在本地内存中，单机的处理能力和内存容量都是有限的，不具备可扩展性。云平台CMQ的分布式架构保证了其扩容的简易性，更重要的是扩容对CMQ的使用者是完全透明的。

两个服务在网络不能互通或者应用的路由信息（比如ip和端口）不确定的情况下需要通信。例如，两个云平台上的服务在不知道对方地址的情况下需要进行通信，则可以通过约定队列名，一个向队列发送消息，一个从队列中收取消息而实现。

系统组件之间或者应用之间通信较多，需要组件或者应用自身维护彼此的网络连接，而且通信的内容不仅一种。这时，使用传统的架构会使得系统设计复杂。例如：当有一个中央处理服务需要向多个任务处理服务分派任务时（类似于master-worker模式），master需要维护与所有worker的连接，并判断worker是否开始处理任务从而决策是否需要重新分派任务。同时，worker的任务结果也需要汇报给master。要在一个层面维护这样的系统会导致设计复杂，实现难度和维护成本大。如下图所示，使用云平台CMQ减轻两方的之间耦合性会使系统简洁高效许多。

系统组件之间或者应用之间耦合较紧，尤其对依赖的组件可控性较弱的情况下，希望降低耦合度。比如公司业务CGI收到用户提交的内容，将部分数据存储在自身的系统中，并将处理后的数据转发给其他业务应用（如数据分析系统、数据存储系统等）。传统的解决方案是服务间通过socket建立连接，此时如果接收方的IP或端口改变， 或换了另一个接收方，则需要数据发送者进行修改。使用云平台CMQ，发送者和接收者对彼此信息无感知，耦合度大大降低。