Kafka与ActiveMQ区别
Kafka 是LinkedIn 开发的一个高性能、分布式的消息系统,广泛用于日志收集、流式数据处理、在线和离线消息分发等场景。虽然不是作为传统的MQ来设计,在大部分情况,Kafaka 也可以代替原先ActiveMQ 等传统的消息系统。
Kafka 将消息流按Topic 组织,保存消息的服务器称为Broker,消费者可以订阅一个或者多个Topic。为了均衡负载,一个Topic 的消息又可以划分到多个分区(Partition),分区越多,Kafka并行能力和吞吐量越高。
Kafka 集群需要zookeeper 支持来实现集群,最新的kafka 发行包中已经包含了zookeeper,部署的时候可以在一台服务器上同时启动一个zookeeper Server 和 一个Kafka Server,也可以使用已有的其他zookeeper集群。
和传统的MQ不同,消费者需要自己保留一个offset,从kafka 获取消息时,只拉去当前offset 以后的消息。Kafka 的scala/java 版的client 已经实现了这部分的逻辑,将offset 保存到zookeeper 上。每个消费者可以选择一个id,同样id 的消费者对于同一条消息只会收到一次。一个Topic 的消费者如果都使用相同的id,就是传统的 Queue;如果每个消费者都使用不同的id, 就是传统的pub-sub.
如果在MQ的场景下,将Kafka 和 ActiveMQ 相比:
Kafka 的优点
分布式可高可扩展。Kafka 集群可以透明的扩展,增加新的服务器进集群。
高性能。Kafka 的性能大大超过传统的ActiveMQ、RabbitMQ等MQ 实现,尤其是Kafka 还支持batch 操作。下图是linkedin 的消费者性能压测结果:
容错。Kafka每个Partition的数据都会复制到几台服务器上。当某个Broker故障失效时,ZooKeeper服务将通知生产者和消费者,生产者和消费者转而使用其它Broker。
Kafka 的不利
重复消息。Kafka 只保证每个消息至少会送达一次,虽然几率很小,但一条消息有可能会被送达多次。
消息乱序。虽然一个Partition 内部的消息是保证有序的,但是如果一个Topic 有多个Partition,Partition 之间的消息送达不保证有序。
复杂性。Kafka需要zookeeper 集群的支持,Topic通常需要人工来创建,部署和维护较一般消息队列成本更高
=-=======================================================================
00
今天让我们来谈谈身份高贵,举止优雅的消息中间件,主要还是浅谈,消息中间件这块水太深。大体上我们结合互联网业务做一些探讨,从互联网主要关心的消息安全性,服务器的稳定性容错性以及吞吐量三方面来讲。
由于这块产品非常多,我只挑选两个我使用过的产品结合使用经验做一些研究,他们是ActiveMQ和Kafka,前者完全实现了JMS的规范,后者看上去有一些“野路子”,并没有纠结于JMS规范,剑走偏锋的设计了另一套吞吐非常高的分布式发布-订阅消息系统,目前非常流行。接下来我们结合三个点(消息安全性,服务器的稳定性容错性以及吞吐量)来分别谈谈这两个消息中间件。今天我们谈Kafka,ActiveMQ的文章在此。
01 性能怪兽Kafka
Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache定级项目。”Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.”,官网首页的一句话高度概括其职责。Kafka并没有遵守JMS规范,他只用文件系统来管理消息的生命周期。Kafka的设计目标是:
(1)以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间复杂度的访问性能。
(2)高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
(3)支持Kafka Server间的消息分区,及分布式消费,同时保证每个Partition内的消息顺序传输。
(4)同时支持离线数据处理和实时数据处理。
(5)Scale out:支持在线水平扩展。
所以,不像AMQ,Kafka从设计开始极为高可用为目的,天然HA。broker支持集群,消息亦支持负载均衡,还有副本机制。同样,Kafka也是使用Zookeeper管理集群节点信息,包括consumer的消费信息也是保存在zk中,下面我们分话题来谈:
1)消息的安全性
Kafka集群中的Leader负责某一topic的某一partition的消息的读写,理论上consumer和producer只与该Leader节点打交道,一个集群里的某一broker即是Leader的同时也可以担当某一partition的follower,即Replica。Kafka分配Replica的算法如下:
(1)将所有Broker(假设共n个Broker)和待分配的Partition排序
(2)将第i个Partition分配到第(i mod n)个Broker上
(3)将第i个Partition的第j个Replica分配到第((i + j) mode n)个Broker上
同时,Kafka与Replica既非同步也不是严格意义上的异步。一个典型的Kafka发送-消费消息的过程如下:首先首先Producer消息发送给某Topic的某Partition的Leader,Leader先是将消息写入本地Log,同时follower(如果落后过多将会被踢出出Replica列表)从Leader上pull消息,并且在未写入log的同时即向Leader发送ACK的反馈,所以对于某一条已经算作commit的消息来讲,在某一时刻,其存在于Leader的log中,以及Replica的内存中。这可以算作一个危险的情况(听起来吓人),因为如果此时集群挂了这条消息就算丢失了,但结合producer的属性(request.required.acks=2 当所有follower都收到消息后返回ack)可以保证在绝大多数情况下消息的安全性。当消息算作commit的时候才会暴露给consumer,并保证at-least-once的投递原则。
2)服务的稳定容错性
前面提到过,Kafka天然支持HA,整个leader/follower机制通过zookeeper调度,它在所有broker中选出一个controller,所有Partition的Leader选举都由controller决定,同时controller也负责增删Topic以及Replica的重新分配。如果Leader挂了,集群将在ISR(in-sync replicas)中选出新的Leader,选举基本原则是:新的Leader必须拥有原来的Leader commit过的所有消息。假如所有的follower都挂了,Kafka会选择第一个“活”过来的Replica(不一定是ISR中的)作为Leader,因为如果此时等待ISR中的Replica是有风险的,假如所有的ISR都无法“活”,那此partition将会变成不可用。
3) 吞吐量
Leader节点负责某一topic(可以分成多个partition)的某一partition的消息的读写,任何发布到此partition的消息都会被直接追加到log文件的尾部,因为每条消息都被append到该partition中,是顺序写磁盘,因此效率非常高(经验证,顺序写磁盘效率比随机写内存还要高,这是Kafka高吞吐率的一个很重要的保证),同时通过合理的partition,消息可以均匀的分布在不同的partition里面。Kafka基于时间或者partition的大小来删除消息,同时broker是无状态的,consumer的消费状态(offset)是由consumer自己控制的(每一个consumer实例只会消费某一个或多个特定partition的数据,而某个partition的数据只会被某一个特定的consumer实例所消费),也不需要broker通过锁机制去控制消息的消费,所以吞吐量惊人,这也是Kafka吸引人的地方。
最后说下由于zookeeper引起的脑裂(Split Brain)问题:每个consumer分别单独通过Zookeeper判断哪些partition down了,那么不同consumer从Zookeeper“看”到的view就可能不一样,这就会造成错误的reblance尝试。而且有可能所有的consumer都认为rebalance已经完成了,但实际上可能并非如此。
Kafka与ActiveMQ区别的更多相关文章
- Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,消息队列有什么优点和缺点
面试题 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka.ActiveMQ.RabbitMQ.RocketMQ 都有什么区别,以及适合哪些场景? 面试官心理分析 其实面试官主要是想看看: ...
- Kafka、ActiveMQ、RabbitMQ、RocketMQ 区别以及高可用原理
为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么? 面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务 ...
- 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么优点和缺点?
面试题 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka.ActiveMQ.RabbitMQ.RocketMQ 都有什么区别,以及适合哪些场景? 面试官心理分析 其实面试官主要是想看看: ...
- 消息队列的作用以及kafka和activemq的对比
背景分析 消息队列这个类型的组件一直是非常重要的组件,当经过两家企业后我就很坚信这个结论了.队列这种东西,最广泛的作用还是在于解耦,宽泛一点的说,它可以将不同部门的工作内容进行有效的整合,基于一个约定 ...
- 【消息队列】从各方面比较下kafka、activemq、rabbitmq、rocketmq之间的区别
一.单机吞吐量ActiveMQ:万级,吞吐量比RocketMQ和Kafka要低了一个数量级RabbitMQ:万级,吞吐量比RocketMQ和Kafka要低了一个数量级RocketMQ:10万级,Roc ...
- Kafka、ActiveMQ、RabbitMQ、RocketMQ区别
1.区别: Kafka和RocketMQ的区别: 1.两者对于消息的单机吞吐量.时效性.可用性.消息可靠性都差不多,其中时效性就是消息延迟都在ms级,kafka吞吐量会更大. 2.功能支持方面:Kaf ...
- 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景?
https://blog.csdn.net/Iperishing/article/details/86674084
- 2020-05-25:MQ应用场景、Kafka和rabbit区别?kafka为什么支撑高并发? 来自
福哥答案2020-05-25: 应用场景:解耦.异步.削峰.区别如下:特性 ActiveMQ RabbitMQ RocketMQ Kafka单机吞吐量 万级,比 RocketMQ.Kafka 低一个数 ...
- rocketMq和kafka的架构区别
概述 其实一直想写一篇rocketMq和kafka在架构设计上的差别,但是一直有个问题没搞明白所以迟迟没动手,今天无意中听人点播了一下似乎明白了这个问题,所以就有了这篇对比. 这篇博文主要讲清楚kaf ...
随机推荐
- IdentityServer4使用OpenIdConnect实现单点登录
接上一篇:IdentityServer4实现OAuth2.0四种模式之授权码模式 前面写的四种OAuth2.0实现模式只涉及到IdentityServer4的OAuth2.0特性,并没有涉及到OenI ...
- 数据结构与算法(周测7-拓扑排序和AOV网络)
判断题 1.AOE图的关键路径就是最长的路径 T F 2.AOE图的权值最大的边(活动)一定是关键活动. T F 两条边相加可能比最大的边还要大. 3.在AOE ...
- windows下git创建本地分支并建立对应远程分支
在对应项目目录下打开命令提示符 git branch -a 查看所有本地和远程分支 git checkout -b [newBranch] 建立本地分支newBranch git p ...
- Oracle 检索数据(查询数据、select语句)
用户对表或视图最常进行的操作就是检索数据,检索数据可以通过 select 语句来实现,该语句由多个子句组成,通过这些子句完成筛选.投影和连接等各种数据操作,最终得到想要的结果. 语法: select ...
- UI5-技术篇-Hybrid App-3-Fiori 百度地图应用
上一次在Jsbin中测试了百度地图应用:UI5-技术篇-Hybrid App-3-jsbin百度地图 ,主要思路:1.加载百度API 2.自定义控件 3.div标签加载地图,本文主要将相关实施过程 ...
- 【转】高性能网络编程1----accept建立连接
最近在部门内做了个高性能网络编程的培训,近日整理了下PPT,欲写成一系列文章从应用角度谈谈它. 编写服务器时,许多程序员习惯于使用高层次的组件.中间件(例如OO(面向对象)层层封装过的开源组件),相比 ...
- Linux命令——taskset
参考:Linux taskset Command Tutorial for Beginners (with Examples) 简介 taskset命令用于设置进程(或 线程)的处理器亲和性(Proc ...
- Python语言之requests库
发送请求.传递URL参数.定制headers.接受数据,处理数据等 在Java中用httpclient jar包,在Python中用requests库,即使没有事先下载,在Pycharm开发工具中,出 ...
- rest-assured-doc接口自动化测试,数据驱动测试平台
原文:https://github.com/rest-assured/rest-assured/wiki/Usage 本文github地址:https://github.com/RookieTeste ...
- 初学Django基础01 建立工程,目录结构,常用配置,上下文管理,模板渲染
django是python的web重量级框架,发展已经有10年多了,对应下面版本 Django 版本 Python 版本 1.8 2.7, 3.2 , 3.3, 3.4, 3.5 1.9, 1.10 ...