暂存#xff08;存储#xff09;队列#xff08;有序#xff1a;先进先出

从目前互联网应用中使用消息队列的场景来看#xff0c;…消息队列

消息队列它主要用来暂存生产者生产的消息供后续其他消费者来消费。

暂存存储队列有序先进先出

多个生产者可以向同一个消息队列发送消息一个消息只能被一个消费者消费在被消费成功后这条消息会被移除。

如果消费者处理消息失败了那么这条消息会重新被消费。

发布/订阅模式

单个消息可以被多个订阅者并发的获取和处理。

多个生产者可以将多个消息写到同一个

Topic

语言开发的一个开源的消息代理。

能够支持多个客户机或服务器。

计算机集群等属性支持

ActiveMQ

是实现了高级消息队列协议AMQP的开源消息代理软件亦称面向消息的中间件。

RabbitMQ

Erlang

所有主要的编程语言均有与代理接口通讯的客户端库。

RabbitMQ

KafkaApache

该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

Kafka

是一个分布式的、分区的、多复本的日志提交服务。

它通过一种独一无二的设计提供了一个消息系统的功能。

RocketMQApache

是一个分布式消息和流媒体平台具有低延迟、强一致、高性能和可靠性、万亿级容量和灵活的可扩展性。

它有借鉴

Kafka

软件基金会顶级项目是下一代云原生分布式消息流平台集消息、存储、轻量化函数式计算为一体采用计算与存储分离架构设计。

特性ActiveMQRabbitMQRocketMQKafkaPulsar推出时间

Mozilla

LicenseApacheApacheYahoo/Apache/顶级特点erlang语言发开性能一般出现比较早有一定的用户基数各个环节分布式扩展设计主从HA,多种消费模式性能很

好高吞吐量、持久化数据存储、分布式系统易于扩展性能极好灵活、多租户、云原生架构、跨地域复制性能超极好单机吞吐量万级吞吐量比RocketMQ和Kafka要低了一个数量级万级吞吐量比RocketMQ和Kafka要低了一个数量级10万级RocketMQ

MQ10万级别吞吐量高是kafka最大的优点100万高吞吐支持强一致支持主题数千级百万级千级topic

topic

数量不要过多否则需要增加更多机器资源Pulsar采用存算分离的架构数据采用bookeeper存储上层broker是无状态代理两层可以对扩容因此topic个数对吞吐量不会产生显著的影响。

可无缝扩展到超过百万个

topic事务支持支持支持支持支持消息顺序性有序有序有序分区有序有序消息重复至少一次至少一次至少一次最多一次至少一次最多一次时效性ms级微秒级RabbitMQ的一大优点ms级ms级ms级可用性高基于主从架构实现高基于主从架构实现非常高分布式架构非常高分布式架构一个数据多个副本少数机器宕机不会丢失数据不会导致不可用非常高分布式架构broker层是无状态代理动态扩容数据存储层bookkeeper采用segment-oriented存储机制无写入不可用风向消息可靠性有较低的概率丢失数据有较低的概率丢失数据经过参数优化配置消息可以做到0丢失。

消息都是持久化的先写入系统

PAGECACHE然后刷盘可以保证内存与磁盘都有一份数据经过参数优化配置理论上消息可以做到0丢失经过参数配置后可以做到0丢失消息回溯不支持不支持支持按时间回溯支持按offset回溯功能支持MQ领域的功能极其完备基于erlang开发所以并发能力很强性能极其好延时很低MQ功能较为完善还是分布式的扩展性好功能较为简单主要支持简单的MQ功能在大数据领域的实时计算以及日志采集被大规模使用是事实上的标准云原生时代的新一代消息中间件社区活跃、支持多租户、强一致、跨域部署等诸多特性伸缩性一般高伸缩性灵活的分布式横向扩展部署架构整体架构和

kafka

很像高伸缩性每个主题topic包含多个分区partition主题中的分区可以分布在不同的主机broker中Pulsar

BookKeeper因此伸缩性更灵活管理界面普通普通完善普通完善持久化可以持久化到内存、文件、数据库持久化不好可以持久化到内存、文件消息可以持久化到磁盘磁盘磁盘消息路由支持不支持不支持支持语言支持支持多语言Java优先支持几乎所有最受欢迎的编程语言JavaCC

CRubyPerlPythonPHP等支持Java、C但C不成熟支持多语言Java优先

Java、C、C

跟Kafka不同的是Pulsar的消息存储模型采用了分层的方式。

第一层是Topic用来存储Producer追加的messagesTopic下面是ledger层保存了分片(Segment)分片里面保存更小粒度的ertriesentries存储一条条的Message。

Ledger中的最后一个分片是最新写入的分片如上图Segment-2。

Segment-2之前的所有分片已完成封装这些分片的数据是不会再发生变化的。

这样增加或删除一个BookKeeper节点或者迁移长期存储节点都不会发生一致性问题。

Apache

单个应用程序的订阅模式由排序和消费可扩展性需求决定。

以下为这四种订阅模式及相关的排序保证。

独占Exclusive同一个topic只能有一个消费者订阅如果多个消费者订阅就会出错。

Exclusive模式为默认订阅模式。

consumer

上的消息。

同一个topic可以有多个消费者订阅但是只能有一个消费者消费其他订阅

的消费者作为故障转移的消费者只有当前消费者出了故障才可以进行消费当前的topic。

如下图

共享Shared订阅模式支持将

队列应用场景。

同一个topic可以由多个消费者订阅和消费。

消息通过round

robin轮询机制分发给不同的消费者并且每个消息仅会被分发给一个消费者。

当消费者断开发送给它的没有被消费的消息还会被重新分发给其它存活的消费者。

如下图

键共享Key_Shared订阅模式结合了其他订阅模式的优点支持将

consumer

的数量扩展至超过分区的数量也支持键级别的强序列保证。

消息和消费者都会绑定一个key消息只会发送给绑定同一个key的消费者。

如果有新消费者建立连接或者有消费者断开连接就需要更新一些消息的key。

Kafka

机器数量经验公式2*峰值生产速度副本数/1001峰值速度比如flume读取日志文件往kafka里写数据的峰值速度得问公司上游业务团队获得副本数topic的副本数一般是2个3个

Topic数量本身无限制但Topic的分区数之和有上限当达到上限后会导致用户无法继续创建Topic。

Broker

Kafka采用分区(Partition)的方式来保存topic每个topic都会在不同的broker保存多个分区副本其中只有一个副本的分区是leader分区供消费者使用。

若干个broker作为follower。

所有的数据读写都通过leader所在的服务器进行并且leader在不同broker之间复制数据。

如果某个broker宕机了这个broker上的leader分区失效需要在其他broker上重新进行选举。

模型图如下

Kafka的消费模型是采用消费者组的模式每一个分区只能给消费者组中的一个消费者消费。

Leader

Broker