对比RabbitMQ、RocketMQ、TDMQ-CMQ、kafka和Ckafka
- 管理员
- 856阅读
- 2022.07.29
导语:上一章我们聊到了:什么是消息队列,为什么要用消息队列,有那些消息队列?下来我们聊聊什么样的消息队列适合我们公司。
在技术领域,从来都没有最好的工具,只有最合适自己公司的工具。
接下来会从工具的优缺点、使用场景、规模、高可用,性能,综合分析来选用适合自己公司的消息队列。
一、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 |
消息回溯 |
支持 |
支持 |
不支持 |
不支持 |
支持 |
安全防护 |
支持 |
不支持 |
不支持 |
不支持 |
支持 |
监控告警 |
支持 |
不支持 |
不支持 |
不支持 |
支持 |
服务支持 |
支持 |
不支持 |
不支持 |
不支持 |
支持 |
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 |
Ckafka和CMQ都作为消息中间件都支持集群部署、高吞吐量、强一致等特性,那这两款产品最主要的区别是什么,分别更适合哪些场景使用?
- CMQ:自研,同步刷盘,金融级别可靠,多用于电商订单,支付,金融
- CKafka:开源,异步刷盘,大数据分析,日志压缩收集,监控聚合分析,实时数据处理,多用于大数据场景,游戏、电商行为分析、商超监控分析、实时打点数据分析、用户行为离线分析、实时决策、发券、黑产发现、智能推荐等。
CKafka(Cloud Kafka)是一个分布式的、高吞吐量、高可扩展性的消息系统,100% 兼容开源 Kafka API(0.9版本)。
Ckafka 基于发布/订阅模式,通过消息解耦,使生产者和消费者异步交互,无需彼此等待。
Ckafka 具有数据压缩、同时支持离线和实时数据处理等优点,适用于日志压缩收集、监控数据聚合等场景。
在这些地方,Ckafka非常好用
- 实时处理网站活动(PV,搜索,用户其他活动等)
- 完美的“日志收集中心”
- 大数据入口和连接器
消息队列 CMQ 版(TDMQ for CMQ,简称 TDMQ CMQ 版)是一种分布式消息队列服务,它具有可靠的、基于消息的异步通信机制,能够将分布式部署的不同应用(或同一应用的不同组件)中的信息传递,存储在可靠有效的消息队列中,防止消息丢失。TDMQ CMQ 版支持多进程同时读写,收发消息互不干扰,无需各应用或组件始终处于运行状态。
TDMQ CMQ 版支持队列模型和主题模型,可用于各类异步通知、远程调用和主题消息分发等场景,常用于订单处理、耗时时间长的事件回调、各运营系统的日志流水等实际业务,同时支持百万级消息堆积数量,保证消息不丢失。