国内最专业的IT技术学习网

UI设计

当前位置:主页 > UI设计 >

常用消息中间件17个维度全方位对比

发布时间:2019/09/18标签:   队列    点击量:

原标题:常用消息中间件17个维度全方位对比
本文先容了Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 个方面综合对照作为新闻行列应用时的差别。一 材料文档Kafka:中。有kafka作者本人写的书,网上材料也有一些。rabbitmq:多。有一些不错的书,网上材料多。zeromq:少。没有特地写zeromq的书,网上的材料多是一些代码的完成和简略先容。rocketmq:少。没有特地写rocketmq的书,网上的材料良莠不齐,民间文档很简练,然而对技巧细节没有过量的描写。activemq:多。没有特地写activemq的书,网上材料多。二 开辟言语Kafka:Scala rabbitmq:Erlang zeromq:c rocketmq:java activemq:java三 支撑的协定Kafka:本人界说的一套…(基于TCP) rabbitmq:AMQP zeromq:TCP、UDP rocketmq:本人界说的一套… activemq:OpenWire、STOMP、REST、XMPP、AMQP四 新闻存储Kafka:内存、磁盘、数据库。支撑大批沉积。kafka的最小存储单位是分区,一个topic包括多个分区,kafka创立主题时,这些分区会被调配在多个效劳器上,平日一个broker一台效劳器。分区领袖会平均地散布在差别的效劳器上,分区正本也会平均的散布在差别的效劳器上,确保负载平衡和高可用性,当新的broker参加集群的时间,局部正本会被挪动到新的broker上。依据设置文件中的名目清单,kafka会把新的分辨别配给名目清单里分区数起码的名目。默许情形下,分区器应用轮询算法把新闻平衡地散布在统一个主题的差别分区中,关于发送时指定了key的情形,会依据key的hashcode取模后的值存到对应的分区中。rabbitmq:内存、磁盘。支撑大批沉积。rabbitmq的新闻分为长久化的新闻和非长久化新闻,不论是长久化的新闻仍是非长久化的新闻都能够写入到磁盘。长久化的新闻在达到行列时就写入到磁盘,而且假如能够,长久化的新闻也会在内存中保留一份备份,如许能够进步必定的机能,当内存吃紧的时间会从内存中肃清。非长久化的新闻个别只存在于内存中,在内存吃紧的时间会被换入到磁盘中,以节约内存。引入镜像行列机制,可将主要行列“复制”到集群中的其余broker上,保障这些行列的新闻不会丧失。设置镜像的行列,都包括一个主节点master和多个从节点slave,假如master生效,参加时光最长的slave会被晋升为新的master,除发送新闻外的全部举措都向master发送,而后由master将下令履行成果播送给各个slave,rabbitmq会让master平均地散布在差别的效劳器上,而统一个行列的slave也会平均地散布在差别的效劳器上,保障负载平衡和高可用性。zeromq:新闻发送真个内存或许磁盘中。不支撑长久化。rocketmq:磁盘。支撑大批沉积。commitLog文件寄存现实的新闻数据,每个commitLog下限是1G,满了以后会主动新建一个commitLog文件保留数据。ConsumeQueue行列只寄存offset、size、tagcode,十分小,散布在多个broker上。ConsumeQueue相称于CommitLog的索引文件,花费者花费时会从consumeQueue中查找新闻在commitLog中的offset,再去commitLog中查找元数据。ConsumeQueue存储格局的特征,保障了写进程的次序写盘(写CommitLog文件),大批数据IO都在次序写统一个commitLog,满1G了再写新的。加上rocketmq是累计4K才强迫从PageCache中刷到磁盘(缓存),以是高并发写机能凸起。activemq:内存、磁盘、数据库。支撑大批沉积。五 新闻事件Kafka:支撑rabbitmq:支撑。客户端将信道设置为事件形式,只要当新闻被rabbitMq接受,事件才干提交胜利,不然在捕捉异样落后行回滚。应用事件会使得机能有所降落 zeromq:不支撑 rocketmq:支撑 activemq:支撑六 负载平衡Kafka:支撑负载平衡。一个broker平日就是一台效劳器节点。关于统一个Topic的差别分区,Kafka会努力将这些分辨别布到差别的Broker效劳器上,zookeeper保留了broker、主题和分区的元数据信息。分区领袖会处置来自客户真个出产恳求,kafka分区领袖会被调配到差别的broker效劳器上,让差别的broker效劳器独特分管义务。每一个broker都缓存了元数据信息,客户端能够从恣意一个broker猎取元数据信息并缓存起来,依据元数据信息晓得要往那里发送恳求。kafka的花费者组定阅统一个topic,会尽能够地使得每一个花费者调配到雷同数目的分区,摊派负载。当花费者参加或许加入花费者组的时间,还会触发再平衡,为每一个花费者从新调配分区,摊派负载。kafka的负载平衡大局部是主动实现的,分区的创立也是kafka实现的,暗藏了许多细节,幸免了烦琐的设置和工资忽视形成的负载成绩。发送端由topic和key来决议新闻发往哪个分区,假如key为null,那末会应用轮询算法将新闻平衡地发送到统一个topic的差别分区中。假如key不为null,那末会依据key的hashcode取模盘算出要发往的分区。rabbitmq:对负载平衡的支撑欠好。新闻被送达到哪个行列是由交流器和key决议的,交流器、路由键、行列都须要手动创立。rabbitmq客户端发送新闻要和broker树立衔接,须要当时晓得broker上有哪些交流器,有哪些行列。平日要申明要发送的目的行列,假如没有目的行列,会在broker上创立一个行列,假如有,就甚么都不处置,接着往这个行列发送新闻。假定大局部沉重义务的行列都创立在统一个broker上,那末这个broker的负载就会过大。(能够在上线前事后创立行列,无需申明要发送的行列,然而发送时不会实验创立行列,能够呈现找不到行列的成绩,rabbitmq的备份交流器会把找不到行列的新闻保留到一个特地的行列中,以便当前查问应用)应用镜像行列机制树立rabbitmq集群能够处理这个成绩,构成master-slave的架构,master节点会平均散布在差别的效劳器上,让每一台效劳器摊派负载。slave节点只是担任转发,在master生效时会抉择参加时光最长的slave成为master。当新节点参加镜像行列的时间,行列中的新闻不会同步到新的slave中,除非挪用同步下令,然而挪用下令后,行列会堵塞,不能在出产情况中挪用同步下令。当rabbitmq行列领有多个花费者的时间,行列收到的新闻将以轮询的散发方法发送给花费者。每条新闻只会发送给定阅列内外的一个花费者,不会反复。这类方法十分合适扩大,并且是特地为并发顺序计划的。假如某些花费者的义务比拟沉重,那末能够设置basicQos限度信道上花费者能坚持的最大未确认新闻的数目,在到达下限时,rabbitmq不再向这个花费者发送任何新闻。关于rabbitmq而言,客户端与集群树立的TCP衔接不是与集群中全部的节点树立衔接,而是选择此中一个节点树立衔接。然而rabbitmq集群能够借助HAProxy、LVS技巧,或许在客户端应用算法完成负载平衡,引入负载平衡以后,各个客户真个衔接能够摊派到集群的各个节点当中。客户端平衡算法: 轮询法。按次序前往下一个效劳器的衔接地点。 加权轮询法。给设置高、负载低的呆板设置更高的权重,让其处置更多的恳求;而设置低、负载高的呆板,给其调配较低的权重,下降其体系负载。 随机法。随机拔取一个效劳器的衔接地点。 加权随机法。依照几率随机拔取衔接地点。 源地点哈希法。经过哈希函数盘算失掉的一个数值,用该数值对效劳器列表的巨细停止取模运算。 最小衔接数法。静态抉择以后衔接数起码的一台效劳器的衔接地点。zeromq:去核心化,不支撑负载平衡。自身只是一个多线程收集库。rocketmq:支撑负载平衡。一个broker平日是一个效劳器节点,broker分为master和slave,master和slave存储的数据一样,slave从master同步数据。nameserver与每个集群成员坚持心跳,保留着Topic-Broker路由信息,统一个topic的行列会散布在差别的效劳器上。发送新闻经过轮询行列的方法发送,每个行列接受均匀的新闻量。发送新闻指定topic、tags、keys,无奈指定送达到哪个行列(没故意义,集群花费和播送花费跟新闻寄存在哪个行列没无关系)。tags选填,相似于 Gmail 为每封邮件设置的标签,便利效劳器过滤应用。现在只支 持每个新闻设置一个 tag,以是也能够类比为 Notify 的 MessageType 观点。keys选填,代表这条新闻的营业要害词,效劳器会依据 keys 创立哈希索引,设置后, 能够在 Console 体系依据 Topic、Keys 来查问新闻,因为是哈希索引,请尽能够 保障 key 独一,比方定单号,商品 Id 等。rocketmq的负载平衡战略划定:Consumer数目应当小于即是Queue数目,假如Consumer超越Queue数目,那末过剩的Consumer 将不能花费新闻。这一点和kafka是分歧的,rocketmq会尽能够地为每一个Consumer调配雷同数目的行列,摊派负载。activemq:支撑负载平衡。能够基于zookeeper完成负载平衡。七 集群方法Kafka:自然的‘Leader-Slave’无状况集群,每台效劳器既是Master也是Slave。分区领袖平均地散布在差别的kafka效劳器上,分区正本也平均地散布在差别的kafka效劳器上,以是每一台kafka效劳器既含有分区领袖,同时又含有分区正本,每一台kafka效劳器是某一台kafka效劳器的Slave,同时也是某一台kafka效劳器的leader。kafka的集群依靠于zookeeper,zookeeper支撑热扩大,全部的broker、花费者、分区都能够静态参加移除,而无需封闭效劳,与不依附zookeeper集群的mq比拟,这是最大的上风。rabbitmq:支撑简略集群,'复制'形式,对高等集群形式支撑欠好。rabbitmq的每一个节点,不论是繁多节点体系或许是集群中的一局部,要末是内存节点,要末是磁盘节点,集群中最少要有一个是磁盘节点。在rabbitmq集群中创立行列,集群只会在单个节点创立行列过程和完全的行列信息(元数据、状况、内容),而不是在全部节点上创立。引入镜像行列,能够幸免单点毛病,确保效劳的可用性,然而须要工资地为某些主要的行列设置镜像。zeromq:去核心化,不支撑集群。rocketmq:罕用 多对'Master-Slave' 形式,开源版本需手动切换Slave酿成MasterName Server是一个简直无状况节点,可集群安排,节点之间无任何信息同步。Broker安排绝对庞杂,Broker分为Master与Slave,一个Master能够对应多个Slave,然而一个Slave只能对应一个Master,Master与Slave的对应关联经过指定雷同的BrokerName,差别的BrokerId来界说,BrokerId为0表现Master,非0表现Slave。Master也能够安排多个。每个Broker与Name Server集群中的全部节点树立长衔接,准时注册Topic信息到全部Name Server。Producer与Name Server集群中的此中一个节点(随机抉择)树立长衔接,按期从Name Server取Topic路由信息,并向供给Topic效劳的Master树立长衔接,且准时向Master发送心跳。Producer完整无状况,可集群安排。Consumer与Name Server集群中的此中一个节点(随机抉择)树立长衔接,按期从Name Server取Topic路由信息,并向供给Topic效劳的Master、Slave树立长衔接,且准时向Master、Slave发送心跳。Consumer既能够从Master定阅新闻,也能够从Slave定阅新闻,定阅规矩由Broker设置决议。客户端先找到NameServer, 而后经过NameServer再找到 Broker。一个topic有多个行列,这些行列会平均地散布在差别的broker效劳器上。rocketmq行列的观点和kafka的分区观点是基础分歧的,kafka统一个topic的分区尽能够地散布在差别的broker上,分区正本也会散布在差别的broker上。rocketmq集群的slave会从master拉取数据备份,master散布在差别的broker上。activemq:支撑简略集群形式,比方'主-备',对高等集群形式支撑欠好。八 治理界面 Kafka:个别 rabbitmq:好 zeromq:无 rocketmq:无 activemq:个别九 可用性 Kafka:十分高(散布式) rabbitmq:高(主从) zeromq:高 rocketmq:十分高(散布式) activemq:高(主从)十 新闻反复 Kafka:支撑at least once、at most once rabbitmq:支撑at least once、at most once zeromq:只要重传机制,然而没有长久化,新闻丢了重传也没有效。既不是at least once、也不是at most once、更不是exactly only once rocketmq:支撑at least once activemq:支撑at least once十一 吞吐量TPSKafka:极大 Kafka按批次发送新闻和花费新闻。发送端将多个小新闻兼并,批量发向Broker,花费端每次掏出一个批次的新闻批量处置。 rabbitmq:比拟大 zeromq:极大 rocketmq:大rocketMQ接受端能够批量花费新闻,能够设置每次花费的新闻数,然而发送端不是批量发送。activemq:比拟大十二 定阅情势和新闻散发Kafka:基于topic以及依照topic停止正则婚配的公布定阅形式。【发送】发送端由topic和key来决议新闻发往哪个分区,假如key为null,那末会应用轮询算法将新闻平衡地发送到统一个topic的差别分区中。假如key不为null,那末会依据key的hashcode取模盘算出要发往的分区。【接受】1)consumer向群组和谐器broker发送心跳来保持他们和群组的附属关联以及他们对分区的全部权关联,全部权关联一旦被调配就不会转变除非产生再平衡(比方有一个consumer参加或许分开consumer group),consumer只会从对应的分区读撤消息。2)kafka限度consumer个数要少于分区个数,每个新闻只会被统一个 Consumer Group的一个consumer花费(非播送)。3)kafka的 Consumer Group定阅统一个topic,会尽能够地使得每一个consumer调配到雷同数目的分区,差别 Consumer Group定阅统一个主题彼此自力,统一个新闻会被差别的 Consumer Group处置。rabbitmq:供给了4种:direct, topic ,Headers和fanout。【发送】先要申明一个行列,这个行列会被创立或许曾经被创立,行列是基础存储单位。由exchange和key决议新闻存储在哪个行列。direct>发送到和bindingKey完整婚配的行列。topic>路由key是含有"."的字符串,会发送到含有“*”、“#”停止含混婚配的bingKey对应的行列。fanout>与key有关,会发送到全部和exchange绑定的行列headers>与key有关,新闻内容的headers属性(一个键值对)和绑定键值对完整婚配时,会发送到此行列。此方法机能低个别不必【接受】rabbitmq的行列是基础存储单位,不再被分区或许分片,关于咱们曾经创立了的行列,花费端要指定从哪一个行列接受新闻。当rabbitmq行列领有多个花费者的时间,行列收到的新闻将以轮询的散发方法发送给花费者。每条新闻只会发送给定阅列内外的一个花费者,不会反复。这类方法十分合适扩大,并且是特地为并发顺序计划的。假如某些花费者的义务比拟沉重,那末能够设置basicQos限度信道上花费者能坚持的最大未确认新闻的数目,在到达下限时,rabbitmq不再向这个花费者发送任何新闻。zeromq:点对点(p2p)rocketmq:基于topic/messageTag以及依照新闻范例、属性停止正则婚配的公布定阅形式。【发送】发送新闻经过轮询行列的方法发送,每个行列接受均匀的新闻量。发送新闻指定topic、tags、keys,无奈指定送达到哪个行列(没故意义,集群花费和播送花费跟新闻寄存在哪个行列没无关系)。tags选填,相似于 Gmail 为每封邮件设置的标签,便利效劳器过滤应用。现在只支 持每个新闻设置一个 tag,以是也能够类比为 Notify 的 MessageType 观点。keys选填,代表这条新闻的营业要害词,效劳器会依据 keys 创立哈希索引,设置后, 能够在 Console 体系依据 Topic、Keys 来查问新闻,因为是哈希索引,请尽能够 保障 key 独一,比方定单号,商品 Id 等。【接受】1)播送花费。一条新闻被多个Consumer花费,即便Consumer属于统一个ConsumerGroup,新闻也会被ConsumerGroup中的每个Consumer都花费一次。2)集群花费。一个 Consumer Group中的Consumer实例均匀摊派花费新闻。比方某个Topic有 9 条新闻,此中一个Consumer Group有3个实例,那末每个实例只花费此中的 3 条新闻。即每一个行列都把新闻轮番散发给每个consumer。activemq:点对点(p2p)、播送(公布-定阅)点对点形式,每个新闻只要1个花费者;公布/定阅形式,每个新闻能够有多个花费者。【发送】点对点形式:先要指定一个行列,这个行列会被创立或许曾经被创立。公布/定阅形式:先要指定一个topic,这个topic会被创立或许曾经被创立。【接受】点对点形式:关于曾经创立了的行列,花费端要指定从哪一个行列接受新闻。公布/定阅形式:关于曾经创立了的topic,花费端要指定定阅哪一个topic的新闻。十三 次序新闻Kafka:支撑。设置出产者的max.in.flight.requests.per.connection为1,能够保障新闻是依照发送次序写入效劳器的,即便产生了重试。kafka保障统一个分区里的新闻是有序的,然而这类有序分两种情形1)key为null,新闻一一被写入差别主机的分区中,然而关于每个分区依旧是有序的2)key不为null , 新闻被写入到统一个分区,这个分区的新闻都是有序。 rabbitmq:不支撑 zeromq:不支撑 rocketmq:支撑 activemq:不支撑十四 新闻确认Kafka:支撑。1)发送方确认机制ack=0,不论新闻能否胜利写入分区ack=1,新闻胜利写入领袖分区后,前往胜利ack=all,新闻胜利写入全部分区后,前往胜利。2)接受方确认机制主动或许手动提交分区偏移量,晚期版本的kafka偏移量是提交给Zookeeper的,如许使得zookeeper的压力比拟大,更新版本的kafka的偏移量是提交给kafka效劳器的,不再依靠于zookeeper群组,集群的机能愈加稳固。rabbitmq:支撑。1)发送方确认机制,新闻被送达到全部婚配的行列后,前往胜利。假如新闻和行列是可长久化的,那末在写入磁盘后,前往胜利。支撑批量确认和异步确认。2)接受方确认机制,设置autoAck为false,须要显式确认,设置autoAck为true,主动确认。当autoAck为false的时间,rabbitmq行列会分红两局部,一局部是等候送达给consumer的新闻,一局部是曾经送达然而充公到确认的新闻。假如始终没有收到确认信号,而且consumer曾经断开衔接,rabbitmq会部署这个新闻从新进入行列,送达给本来的花费者或许下一个花费者。未确认的新闻不会有过时时光,假如始终没有确认,而且没有断开衔接,rabbitmq会始终等候,rabbitmq同意一条新闻处置的时光能够良久良久。 zeromq:支撑 rocketmq:支撑 activemq:支撑十五 新闻回溯 Kafka:支撑指定分区offset地位的回溯 rabbitmq:不支撑 zeromq:不支撑 rocketmq:支撑指准时间点的回溯 activemq:不支撑十六 新闻重试Kafka:不支撑,然而能够完成。kafka支撑指定分区offset地位的回溯,能够完成新闻重试。rabbitmq:不支撑,然而能够应用新闻确认机制完成。rabbitmq接受方确认机制,设置autoAck为false。当autoAck为false的时间,rabbitmq行列会分红两局部,一局部是等候送达给consumer的新闻,一局部是曾经送达然而充公到确认的新闻。假如始终没有收到确认信号,而且consumer曾经断开衔接,rabbitmq会部署这个新闻从新进入行列,送达给本来的花费者或许下一个花费者。zeromq:不支撑rocketmq:支撑。新闻花费失利的大局部场景下,马上重试99%都市失利,以是rocketmq的战略是在花费失利时准时重试,每次时光距离雷同。1、发送真个 send 方式自身支撑外部重试,重试逻辑以下:a)最多重试3次;b)假如发送失利,则轮转到下一个broker;c)这个方式的总耗时不超越sendMsgTimeout 设置的值,默许 10s,超越时光不在重试。2、接受端。Consumer 花费新闻失利后,要供给一种重试机制,令新闻再花费一次。Consumer 花费新闻失利平日能够分为以下两种情形:因为新闻自身的起因,比方反序列化失利,新闻数据自身无奈处置(比方话费充值,以后新闻的手机号被登记,无奈充值)等。准时重试机制,比方过 10s 秒后再重试。因为依靠的卑鄙利用效劳弗成用,比方 db 衔接弗成用,外体系收集弗成达等。即便跳过以后失利的新闻,花费其余新闻一样也会报错。这类情形能够 sleep 30s,再花费下一条新闻,加重 Broker 重试新闻的压力。activemq:不支撑十七 并发度Kafka:高一个线程一个花费者,kafka限度花费者的个数要小于即是分区数,假如要进步并行度,能够在花费者中再开启多线程,或许增添consumer实例数目。rabbitmq:极高自身是用Erlang言语写的,并发机能高。可在花费者中开启多线程,最罕用的做法是一个channel对应一个花费者,每一个线程操纵一个channel,多个线程复用connection的tcp衔接,增加机能开支。当rabbitmq行列领有多个花费者的时间,行列收到的新闻将以轮询的散发方法发送给花费者。每条新闻只会发送给定阅列内外的一个花费者,不会反复。这类方法十分合适扩大,并且是特地为并发顺序计划的。假如某些花费者的义务比拟沉重,那末能够设置basicQos限度信道上花费者能坚持的最大未确认新闻的数目,在到达下限时,rabbitmq不再向这个花费者发送任何新闻。zeromq:高rocketmq:高1、rocketmq限度花费者的个数少于即是行列数,然而能够在花费者中再开启多线程,这一点和kafka是分歧的,进步并行度的方式雷同。修正花费并行度方式a) 统一个 ConsumerGroup 下,经过增添 Consumer 实例数目来进步并行度,超越定阅行列数的 Consumer实例有效。b) 进步单个 Consumer 的花费并行线程,经过修正参数consumeThreadMin、consumeThreadMax2、统一个收集衔接connection,客户端多个线程能够同时发送恳求,衔接会被复用,增加机能开支。activemq:高单个ActiveMQ的接受和花费新闻的速率在1万笔/秒(长久化 个别为1-2万, 非长久化 2 万以上),在出产情况中安排10个Activemq就能到达10万笔/秒以上的机能,安排越多的activemq broker 在MQ上latency也就越低,体系吞吐量也就越高。版权声名:本文来自知乎,更多相干答复:http://t.cn/RVDWcfe,版权归原创者全部。除非无奈确认,咱们都市表明作者及出处,若有侵权烦请告诉,咱们会马上删除并表现歉意,感谢。【编纂推举】怎样应用ASP.Net Core中的前提旁边件?一个每天用新闻行列的人,不晓得为啥用 MQ,这就有点为难一文读懂MQ新闻行列新闻旁边件这么多,究竟应当怎样选型?应用Kafka设置牢靠的高机能散布式新闻通报基本架构【义务编纂:武晓燕 TEL:(010)68476606】 点赞 0

版权信息Copyright © 银河官网 版权所有    ICP备案编号:鲁ICP备09013610号