前言
本文将从多个角度全方位对比目前比较常用的几个MQ：
RocketMQKafkaRabbitMQActiveMQZeroMQ下文单独说明。
表格对比
特性RocketMQKafkaRabbitMQActiveMQ单机吞吐量10 万级，支撑高吞吐10 万级以上，甚至有文献称，可以达到单机百万级TPS。万级，同ActiveMQ万级，相对其他MQ较低。topic 数量对吞吐量的影响topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topictopic从几十到几百个时候，吞吐量会大幅度下降，所以请不要给Kafka设计过多的topic，需要更多的机器资源支撑大规模的 topictopic 数量增多，吞吐量会下降topic 数量增多，吞吐量会下降时效性ms 级延迟在 ms 级以内微秒级，延迟最低RabbitMQ 的一大特点ms 级可用性非常高，分布式架构非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用同 ActiveMQ高，基于主从架构实现高可用消息可靠性经过参数优化配置，可以做到 0 丢失。支持事务同 RocketMQ。支持事务基本不丢有较低的概率丢失数据消息顺序性分区内消息有序分区内消息有序队列的消息有序队列消息有序，topic不保证。消息延时5.0开始支持，定时消息插件支持插件支持支持，Scheduled Message功能支持MQ 功能较为完善，还是分布式的，扩展性好功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用基于 erlang 开发，并发能力很强，性能极好，延时很低MQ 领域的功能极其完备资料文档少。没有专门写rocketmq的书，网上的资料良莠不齐，官方文档很简洁，但是对技术细节没有过多的描述中，有kafka作者自己写的书，网上资料也有一些多。有一些不错的书，网上资料多多。没有专门写activemq的书，网上资料多开发语言javaScala+JavaErlangjava支持协议自定义自定义（基于TCP）AMQPOpenWire、STOMP、REST、XMPP、AMQP消息存储磁盘。支持大量堆积内存、磁盘、数据库。支持大量堆积内存、磁盘。支持少量堆积集群方式常用多对’Master-Slave’ 模式，开源版本需手动切换Slave变成Master天然的‘Leader-Slave’无状态集群，每台服务器既是Master也是Slave支持简单集群，'复制’模式，对高级集群模式支持不好支持简单集群模式，比如’主-备’，对高级集群模式支持不好系统场景电商系统，金融系统，物流系统大数据处理平台（如 Hadoop、Spark） 流处理平台（如 Flink、Storm） 日志收集系统（如 ELK）网站通知系统 任务队列系统 微服务通信系统传统企业应用（如 ERP、CRM） JMS 兼容系统
ZeroMQ
ZeroMQ优缺点
ZeroMQ 的优点：
轻量级和快速：ZeroMQ是一个轻量级的消息中间件，具有高性能和低延迟的特点，适用于需要快速消息传递的场景。灵活的消息模型：ZeroMQ支持多种消息传递模式，如请求-应答、发布-订阅、推送-接收等，可以根据不同需求选择合适的模式。无中心化架构：ZeroMQ没有中心服务器，消息传递是点对点的，这种无中心化的架构使得系统更具弹性和可伸缩性。多语言支持：ZeroMQ提供了多种语言的绑定，如C++, Python, Java等，可以方便地在不同语言的应用中集成ZeroMQ。多平台支持：ZeroMQ可以在多种操作系统上运行，包括Windows、Linux、MacOS等，使得跨平台开发变得更加容易。简单易用：ZeroMQ的API设计简洁明了，使用起来相对容易，可以快速上手并构建复杂的消息传递系统。开源和社区支持：ZeroMQ是开源项目，拥有活跃的社区支持，用户可以通过社区获得帮助、反馈和贡献。
ZeroMQ 的缺点：
复杂性：ZeroMQ 的 API 相对复杂，需要一定的时间来学习和掌握。缺乏持久性：ZeroMQ 不提供消息持久化功能，一旦消息被消费就会丢失。不支持事务：ZeroMQ 不支持分布式事务，因此不适用于需要保证消息原子性、一致性、隔离性和持久性的场景。不支持高可用：ZeroMQ 本身不支持集群，需要使用第三方工具或库来实现。
ZeroMQ应用场景
分布式系统：构建分布式系统，实现不同组件之间的通信和消息传递。实时数据处理：处理来自不同来源的实时数据，如传感器、日志和社交媒体流。游戏开发：实现多人游戏中的玩家通信和数据同步。金融交易系统：构建高吞吐量、低延迟的金融交易系统。物联网：连接和管理物联网设备，实现数据采集和控制。
相关文章
发表评论