登录
  • 欢迎访问悠扬的技术博客,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站😉

消息队列技术选型对比

消息队列 悠扬 65次浏览 已收录 0个评论
组件 RocketMQ RabbitMQ ActiveMQ Kafka Redis ZeroMQ Pulsar支持云原生,发展潜力大
协议 支持Tcp,JMS,openMeesaging 支持AMQP,XMPP,SMTP,STOMP 支持AMQP MQTTJMS协议 支持Tcp接入 没有什么队列协议,支持订阅模式 TCP、UDP、IPC、广播 TCP
性能 10万条/秒 万级 万级 单机写入 TPS 号称在百万条/秒 万级 万级 万亿,计算与存储分离,易扩展
可靠性(消息丢失) 支持异步/同步刷盘;异步/同步Replication支持磁盘 经过消息确认、持久化等手段保证,支持内存,文件 较低概率丢失数据,支持内存,文件,数据库 异步刷盘方式,异步Replication较低概率丢失数据 内存型,提供aof,rdb两种但是还是会丢失 有多种可靠性,请求回应方式https://zguide.zeromq.org/docs/chapter4/ 通过broker分布式存储
时效性 支持push模型,pull模型 支持push模型,pull模型 Push 模式毫秒级 pull 模式支持pull长轮询 pull模式1:M Pull 与 push 模式支持 N:M Pull 与 push 模式支持 N:M
持久化 高性能和低延迟的文件存储同步刷盘 异步刷盘 高性能文件存储 需要外带高性能日志系统,如leveldb 通过磁盘顺序读写与零拷贝机制 aof和rdb两种机制进行持久化,但还是会丢失(pub/sub) 有个缺点就是消息无法持久化Stream。它提供了消息的持久化和主备复制功能 支持,在消息发送端保存https://zguide.zeromq.org/docs/chapter4/#Disconnected-Reliability-Titanic-Pattern 通过broker分布式存储,raft 协议同步数据,也就是过半成功才返回ack给生产者
队列数 单机支持最高5万个队列,性能稳定 5w个队列,单机单线程https://www.cloudamqp.com/blog/part1-rabbitmq-best-practice.html   单机超过64个队列/分区,消息发送性能降低严重 本来是通过自身数据结构存储,看内存    
事务 支持,通过半消息实现(暂存到mqserver,不提供给消费者,生产者的本地事务全完成才给消费者,否则把消息丢弃)https://rocketmq.apache.org/rocketmq/the-design-of-transactional-message/https://help.aliyun.com/document_detail/112010.html?spm=a2c4g.11186623.6.564.49ff2d67ZYvxCl 事务机制有关的方法有三个:txSelect(), txCommit()以及txRollback() 支持 不支持 支持 不支持 支持https://pulsar.apache.org/docs/en/transactions/
死信 支持 支持专门有一个dead letter exchange进行存储 支持 不支持 不支持,需要额外开发 不支持 支持
批量发送 支持,1024条,设定缓存条数,时间进行批量消费 不支持 不支持 支持,带有异步生产者 不支持 支持,订阅模式1:N N:M, 它会进可能发送所有消息http://wiki.zeromq.org/area:faq 支持
消息有序性 严格的消息顺序,在顺序消息场景下,一台Broker宕机后,发送消息会失败,但是不会乱序 保证独立分区消息的顺序 独立消费者、独立队列保证消费有序 保证独立分区内消费的顺序,但一台Broker down机,机会产生消息乱序 Pipelining一个消费者 不支持 支持,通过分区实现,使用 SinglePartition或者RoundRobinPartition模式
延迟推送 支持 可支持,通过TTL设置消息到死信队列中进行消费https://www.cnblogs.com/mfrank/p/11260355.html 支持NMS schedule 不支持 能支持blpop/brpop,需要在消费端实现,但是这样会让消费端阻塞 本身不支持,需要额外实现 支持
广播消息 支持集群消费:当使用集群消费模式时,消息队列RocketMQ版认为任意一条消息只需要被集群内的任意一个消费者处理即可。广播消费:当使用广播消费模式时,消息队列RocketMQ版会将每条消息推送给集群内所有注册过的消费者,保证消息至少被每个消费者消费一次。 支持 支持 不支持 支持 支持,Push-Pull模型实现 支持,其实就是订阅多个消费者,使用push方式
消息过滤 支持 不支持,但可以自行封装。 支持 支持,使用 streams过滤消息 支持,streamed message 不支持 支持
消息查询 根据message id 支持Producer客户端设置Message ID属性,为每条消息设置唯一标识符 只能针对主题,额外用命令过滤查询 不支持 Redis streams支持 不支持 支持,支持sqlhttps://pulsar.apache.org/docs/zh-CN/next/sql-getting-started/
消息回溯 支持,支持按照时间回溯 不支持。RabbitMQ中消息一旦被确认消费就会被标记删除 不支持 支持,offset查找,但确定不了那个消费者,那个生产者生成,消费 不支持 不支持  
消息优先 支持 支持 支持 支持,按offset进行 支持,需要在消费端实现 不支持 支持
消息重发 支持,重试间隔时间顺延 不支持 不支持 支持 不支持 不支持 支持
消息积压(消费不来) 能够持久化 支持 支持 支持topic下消费者较长时间离线,消息堆积量大 支持 不支持  
消息确认 支持 支持 支持 支持 支持,维护两个队列:pending队列和doing表 支持 支持,消费者ack确认,给broker,从而可删除消息体
信息轨道追踪(生产者,消费者,队列的信息状态)https://help.aliyun.com/document_detail/43357.html 可以通过Message ID、Message Key或Topic的时间范围查询相关的消息轨迹,找到消息的实际收发状态,帮助诊断问题 支持 不支持 不支持 不支持 不支持 不支持
API完备性 SDK支持丰富 SDK支持丰富 SDK支持丰富JMS版本多 SDK丰富,大多支持TCP SDK丰富 SDK丰富 SDK丰富
分布式系统高可用 非常高(分布式架构) 集群模式 主从,取决于存储,如果是用kahadb ,需要zookeepr支持 分布式架构Broker、Producer、Consumer都原生自动支持分布式, 集群,哨兵,主从 去中心化,不支持集群 非常可靠,分布式系统
消息分发 round-robin轮询机制,轮询消费者 round-robinprefetchCount,消费者来不及处理,消息会堆积在队列中,新启动的消费者可以马上从队列中取到消息开始工作 轮询(默认)或按照严格顺序 依赖zookeeper自动实现复杂均衡zookeeper管理集群中的broker sonsumer,通过zookeeper的协调机制,producer会记录topic对应的broker,对broker进行轮询或者随机访问broker 轮询机制只能一个topic 一个consumer 接收端负载均衡 支持轮询机制sharding机制
管理界面、监控指标 支持web管理工具丰富支持web和终端命令 支持web和终端命令运维工具丰富 支持,使用一般 支持,终端命令 有丰富的运维指令,需要额外按照非官方的管理工具 ZMQ 协议开放监控内容,需要自己开发https://blog.csdn.net/yaomingyang/article/details/101380723 支持web管理工具丰富支持web和终端命令https://pulsar.apache.org/docs/zh-CN/next/admin-api-overview/
社区支持、文档完备 阿里与apache社区支持 完整 成熟,社区活跃高,现在维护越来越少 完善 完善 完善,而且国际化
权限控制 用户方面:ACL特性服务方面:所有服务组件API级别的鉴权 支持SSL、SASL身份认证和读写权限控制。 用户验证队列增删改授权 支持SSL、SASL身份认证和读写权限控制 单一,只有用户验证 多租户系统设计用户与服务都支持鉴权
热启动实时修改参数不用重启节点,直接reload实时加载 updateBrokerConfig更新 broker信息,不用重启而且能够在nameserv 上进行分发 rabbitmqctl eval大部分参数能够变更如果需要升级整个node需要红绿部署 支持runtimeConfigurationPlugin checkPeriod=”1000″ 支持动态修改Dynamic Update Mode通过zookeeper 同步所有broker 支持 不支持
流量控制   基于Credit-Based算法,是内部被动触发的保护机制,作用于生产者层面。 异步发送如果超过内存阀值,也就是活动窗口 ProducerWindowSize 就会进行阻塞https://activemq.apache.org/producer-flow-control 支持client和user级别,通过主动设置可将流控作用于生产者或消费者。 需要自身实现 不支持 多租户,能够适当低进行磁盘配额、流控制、限流调节
多租户 开源版本没有 支持Virtual Hosts 不支持 没有 不支持 不支持 支持
冷热数据             支持,分层存储,当 backlog 大小到达如10m,也可以精细到topichttps://pulsar.apache.org/docs/en/concepts-tiered-storage/
特点 场景异步解耦秒杀或团队抢购活动(削峰填谷)大规模机器的缓存同步分布式事务的数据一致性https://help.aliyun.com/document_detail/112010.html?spm=a2c4g.11186623.6.564.49ff2d67ZYvxCl Erlang 并发性能好 功能齐全 日志处理 基本上都需要自身实现队列的所有事情基本上 Redis Streams 是比较容易实现消息队列 支持高并发的异步 Socket 框架支持的通讯模型适用于大型集群和分布式计算多线程去锁化定位只是一个多线程网络库场景分布式任务分发,如游戏加机saltstack的底层就使用了ZeroMQ作为通信机制Mongrel2是使用ZeroMQ开发的一个Web服务器 计算与存储分开易水平扩展多租户低延迟多地理集群复制基本上所有队列的特性都包含并且提供高可用的解决方案

版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明消息队列技术选型对比
喜欢 (0)
支付宝[]
分享 (0)
悠扬
关于作者:
10年以上工作经验:4年以上微服务架构设计搭建经验。 曾任岗位:项目经理、架构师。 擅长领域:大数据、数据库,架构设计,资源优化。 获得业绩: 1.实用新型发明专利1个,修改Apache Sharding源码设计实现分库分表程序增强方案。 2.开源项目一个:https://gitee.com/zsiyang/ruoyi-vue-atomikos (加入开源生态圈)。 3.个人技术博客地址:https://www.nxhz1688.com
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址