导语：上一章我们聊到了：什么是消息队列，为什么要用消息队列，有那些消息队列？下来我们聊聊什么样的消息队列适合我们公司。
在技术领域，从来都没有最好的工具，只有最合适自己公司的工具。
接下来会从工具的优缺点、使用场景、规模、高可用，性能，综合分析来选用适合自己公司的消息队列。
一、RabbitMQ、RocketMQ、和CMQ，CKafka和Apache Kafka的对比：
特性 | CKafka | Apache Kafka | RabbitMQ | RocketMQ | TDMQ-CMQ |
|---|---|---|---|---|---|
优点 | 吞吐量非常大；扩展性非常灵活；运维成本极低 | 吞吐量大 | 可靠性高 | 可靠性高 | 可靠性非常高；金融等强一致性场景 |
缺点 | 极端情况可能丢失消息 | 可能丢失消息；扩展性不够灵活；依赖组件多，运维量大；安全防护功能有限，隔离和兼容性差 | 性能较差扩展不灵活 | HA 切换需要手动支持，不能自动化 | 为保证强一致性，吞吐量一般 |
开发语言 | Scala | Scala | Erlang | Java | C |
可扩展性 | 非常灵活、易于扩展，发送消息只需指明 VIP 地址，Broker 的变化对于收发消息都透明 | 不够灵活，发送消息需指明 Broker 地址，接收消息需 ZooKeeper 协调调度 | 不够灵活，发送消息需要指明 Broker 地址 | 较灵活，发送方、接收方和 Name Server 连接 | 灵活、平滑、水平扩展，逻辑上单个 Queue可跨多个集群提供服务 |
吞吐量 | 非常大 | 较大 | 一般 | 一般 | 一般 |
常规性能 | 百万级QPS | 百万级QPS | 十万级QPS | 十万级QPS | 十万级QPS |
2C 4GB压测 | 读写22万QPS | 读写20万QPS | 读写10万QPS | 读写10万QPS | 读写12万QPS |
同步算法 | ISR（Replica） | ISR（Replica） | GM | 同步双写 | Raft |
可用性 | 可用性很高，主从自动切换，腾讯云消息服务承诺可用性99.95% | 可用性高，主从自动切换，但由于异步刷盘和复制，切换后可能会丢消息 | 主备自动切换，用 mirror queue 支持m/s，master 提供服务，slave 仅备份 | 不支持主从自动切换，master 不可用时 slave 只读不写 | 可用性很高，Broker 中存在2节点即可提供高可用服务 |
消费方式 | 拉取方式 | 拉取方式 | 拉取和推送方式 | 拉取和推送方式 | 拉取和推送方式 |
消息可靠性 | 可靠性较高；可通过三副本方式提升可靠性，集群容灾性能好，故障情况极少发生 | 可靠性低；Broker 只有异步刷盘机制并主备只有异步复制，可能会导致丢失部分消息 | 可靠性高；发送消息时，指定消息为持久化就会写入到磁盘 | 可靠性高；Broker 同步双写，主备都写成功才返回成功 | 可靠性极高；保证消息不丢失同步刷盘，数据持久性99.999999% |
数据校验 | CRC | CRC | 无 | CRC | Checksum |
消息回溯 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
安全防护 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
监控告警 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
服务支持 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
二、用CVM自建的Kafka集群和腾讯云上的CKafka进行对比
1， 用CVM自建的Kafka集群
- 3台 zookeeper集群用来存储元数据、管理kafka集群，三台kafka的Broker主机：4c8g300G（内网带宽2Gbps）305.46元一个月*6台= 1832.76元
- 自建需要运维对kafka集群和zookeeper集群比较精通，
- 扩容很复杂
2， Ckafka
- 峰值带宽40MBS/s、300G磁盘容量、25主题，60个分区：269元一个月
- 腾讯专家级团队运维CKafka集群，自已无需运维
- 扩容不影响业务
3， 以下还介绍了消息队列 CKafka 相比于自建开源 Apache Kafka 所具备的其他优势：
关键点 | 解释 | 对比 |
|---|---|---|
低成本 | 按照客户预估的流量峰值和磁盘容量来计费，十分灵活。 | 对比CVM自建的成本更低，且无需部署环境。 |
安全可靠 | 做了账号级别的资源隔离，VPC网络隔离，以及应用层的白名单机制（topic维度），保障数据安全。 | 开源kafka没有该能力。 |
兼容开源，迁移成本低，支持上下游生态 | 完美兼容0.9和0.10的开源kafka API，客户自建kafka的迁移到Ckafka, 仅需要更改broker ip即可，门槛低；对第三方插件的支持十分友好。 | 竞品kafka迁移成本较高，对周边生态的支持较差，需要客户对业务进行改造。 |
无缝扩容、超高性能 | 当集群的流量和磁盘容量超过告警阈值，后端会及时扩容设备，对客户端无感知。（支持升级配置的能力） 生产性能比开源kafka高50%。 | 对比开源kafka，扩容繁琐，易出现单点故障。此外性能收到设备配置的限制，无法得到保障。 |
无需部署和运维 | 完善的监控告警系统和运维工单系统，Ckafka研发专家随时答疑解惑，迅速解决客户问题，省心省力。 | 自建的运维和部署十分繁琐，出了问题难以定位。 |
支持私有化部署 | 支持金融、政企客户的私有化部署，保障客户私密数据。同时支持客户IDC机房接入公有云kafka的混合模式。 | 可维护性高，性能强于自建Kafka |
三、CKafak和TDMQ-CMQ各有千秋，适用不同的场景。
Ckafka和CMQ都作为消息中间件都支持集群部署、高吞吐量、强一致等特性，那这两款产品最主要的区别是什么，分别更适合哪些场景使用？
- CMQ：自研，同步刷盘，金融级别可靠，多用于电商订单，支付，金融
- CKafka：开源，异步刷盘，大数据分析，日志压缩收集，监控聚合分析，实时数据处理，多用于大数据场景，游戏、电商行为分析、商超监控分析、实时打点数据分析、用户行为离线分析、实时决策、发券、黑产发现、智能推荐等。
1、CKafka
CKafka（Cloud Kafka）是一个分布式的、高吞吐量、高可扩展性的消息系统，100% 兼容开源 Kafka API（0.9版本）。
Ckafka 基于发布/订阅模式，通过消息解耦，使生产者和消费者异步交互，无需彼此等待。
Ckafka 具有数据压缩、同时支持离线和实时数据处理等优点，适用于日志压缩收集、监控数据聚合等场景。
在这些地方，Ckafka非常好用
- 实时处理网站活动（PV，搜索，用户其他活动等）
- 完美的“日志收集中心”
- 大数据入口和连接器
2、TDMQ-CMQ
消息队列 CMQ 版（TDMQ for CMQ，简称 TDMQ CMQ 版）是一种分布式消息队列服务，它具有可靠的、基于消息的异步通信机制，能够将分布式部署的不同应用（或同一应用的不同组件）中的信息传递，存储在可靠有效的消息队列中，防止消息丢失。TDMQ CMQ 版支持多进程同时读写，收发消息互不干扰，无需各应用或组件始终处于运行状态。
TDMQ CMQ 版支持队列模型和主题模型，可用于各类异步通知、远程调用和主题消息分发等场景，常用于订单处理、耗时时间长的事件回调、各运营系统的日志流水等实际业务，同时支持百万级消息堆积数量，保证消息不丢失。
