kafka是否适合在docker中使用?单机集群是否有意义
发布网友
发布时间:2022-04-23 08:12
我来回答
共1个回答
热心网友
时间:2022-04-11 01:26
可部署性
先说明下,这里探讨的是Yarn或者Mesos集群的部署,不涉其上的应用。Yarn除了依赖JDK,对操作系统没有任何依赖,基本上放上去就能
跑。Mesos因为是C/C++开发的,安装部署可能会有库依赖。
这点我不知道大家是否看的重,反正我是看的相当重的。软件就应该是下下来就可以Run。所以12年的时候我就自己开发了一套Java服务框架,开发完之后
运行个main方法就行。让应用包含容器,而不是要把应用丢到Tomcat这些容器,太复杂,不符合直觉。
二次开发
Yarn 对Java/Scala工程师而言,只是个Jar包,类似索引开发包Lucene,你可以把它引入项目,做任何你想要的包装。 这是其一。
其二,Yarn提供了非常多的扩展接口,很多实现都是可插拔。可替换的,在XML配置下,可以很方便的用你的实现替换掉原来的实现,没有太大的侵入性,所以就算是未来Yarn升级,也不会有太大问题。
相比较而言,Mesos更像是一个已经做好的产品,部署了可以直接用,但是对二次开发并不友好。
生态优势
Yarn 诞生于Hadoop这个大数据的“始作俑者”项目,所以在大数据领域具有先天优势。
底层天然就是分布式存储系统HDFS,稳定高效。
其上支撑了Spark、MR等大数据领域的扛顶之座,久经考验。
社区强大,最近发布版本也明显加快,对于长任务的支持也越来越优秀。
长任务支持
谈及长任务(long running
services)的支持,有人认为早先Yarn是为了支持离线短时任务的,所以可能对长任务的支持有限。其实大可不必担心,譬如现在基于其上的
Spark Streaming就是7x24小时运行的,跑起来也没啥问题。一般而言,要支持长任务,需要考虑如下几个点:
Fault tolerance,主要是AM的容错。
Yarn Security,如果开启了安全机制,令牌等的失效时间也是需要注意的。
日志收集到集群。
还有就是资源隔离和优先级。如果资源隔离做的太差,会对长时任务产生影响。
大家感兴趣可以先参考Jira。我看这个Jira 13年就开始了,说明这事很早就被重视起来了。下面我们队提到的几个点做下解释。
Fault tolerance
Yarn 自身高可用。目前Yarn的Master已经实现了HA。
AM容错,我看从2.4版本(看的源码,也可能更早的版本就已经支持)就已经支持 keep containers across
attempt
的选项了。什么意思呢?就是如果AM挂掉了,在Yarn重新启动AM的过程中,所有由AM管理的容器都会被保持而不会被杀掉。除非Yarn多次尝试都没办
法把AM再启动起来(默认两次)。 这说明从底层调度上来看,已经做的很好了。
日志收集到集群
日志收集在2.6版本已经是边运行边收集了。
资源隔离
资源隔离的话,Yarn做的不好,目前有效的是内存,对其他方面一直想做支持,但一直有限。这估计也是很多人最后选择Mesos的缘由。但是现在这
点优势Mesos其实已经荡然无存,因为Docker容器在资源隔离上已经做的足够好。Yarn和Docker一整合,就互补了。
小结
Mesos 和 Yarn 都是非常优秀的调度框架,各有其优缺点,弹性调度,统一的资源管理是未来平台的一个趋势,类似的这种资源管理调度框架必定会大行其道。
一些常见的误解
脱胎于Hadoop,继承了他的光环和生态,然而这也会给其带来一定的困惑,首先就是光环一直被Hadoop给盖住了,而且由于固有的惯性,大家会理所当然的认为Yarn只是Hadoop里的一个组件,有人会想过把Yarn拿出来单独用么?
然而,就像我在之前的一篇课程里,反复强调,Hadoop是一个软件集合,包含分布式存储,资源管理调度,计算框架三个部分。他们之间没有必然的关
系,是可以独立开来的。而Yarn
就是一个资源管理调度引擎,其一开始的设计目标就是为了通用,不仅仅是跑MR。现在基于Yarn之上的服务已经非常多,典型的比如Spark。
这里还有另外一个误区,MR目前基本算是离线批量的代名词,这回让人误以为Yarn也只是适合批量离线任务的调度。其实不然,我在上面已经给出了分析,Yarn 是完全可以保证长任务的稳定可靠的运行的。
如何基于Yarn开发分布式程序
本文不会具体教你如何使用Yarn的API,不过如果你想知道Yarn的API,但是又觉得官方文档太过简略,我这里倒是可以给出两个建议:
代码使用范例可以参看Spark Yarn相关的代码。算的上是一个非常精简的Yarn的adaptor。
买本Yarn相关的书,了解其体系结构也有助于你了解其API的设计。
接下来的内容会探讨以下两个主题:
基于Yarn开发分布式程序需要做的一些准备工作
基于Yarn开发容器调度系统的一些基本思路
基于Yarn开发分布式程序需要做的一些准备工作
肯定不能撸起袖子就开始干。开始动手前,我们需要知道哪些事情呢?
Yarn原生的API太底层,太复杂了
如果你想愉快的开发Yarn的应用,那么对Yarn的API进行一次封装,是很有必要的。
Yarn为了灵活,或者为了能够满足开发者大部分的需求,底层交互的API就显得比较原始了。自然造成开发难度很大。这个也不是我一个人觉得,现在
Apache的Twill,以及Hulu他们开发的时候Adaptor那一层,其实都是为了解决这个问题。那为什么我没有用Twill呢,第一是文档实在
太少,第二是有点复杂,我不需要这么复杂的东西。我觉得,Twill与其开发这么多功能,真的不如好好写写文档。
最好是能开发一个解决一类问题的Framework
Yarn只是一个底层的资源管理和调度引擎。一般你需要基于之上开发一套解决特定问题的Framework。以Spark为例,他是解决分布式计算
相关的一些问题。而以我开发的容器调度程序,其实是为了解决动态部署Web应用的。在他们之上,才是你的应用。比如你要统计日志,你只要在Spark上开
发一个Application 。 比如你想要提供一个推荐系统,那么你只要用容器包装下,就能被容器调度程序调度部署。
所以通常而言,基于Yarn的分布式应用应该符合这么一个层次:
Yarn -> Adapter -> Framework -> Application
Adapter 就是我第一条说的,你自个封装了Yarn的API。 Framework就是解决一类问题的编程框架,Application才是你真正要解决业务的系统。通过这种解耦,各个层次只要关注自己的核心功能点即可。
保证你上层的Framework/Application可以移植
Spark是个典型,他可以跑在Mesos上,也可以跑在Yarn上,还可以跑在自己上面(Standalone),实时上,泡在Yarn上的,以及跑Standalone模式的,都挺多的。这得益于Spark本身不依赖于底层的资源管理调度引擎。
这其实也是我上面说的两条带来的好处,因为有了Adaptor,上层的Framework可以不用绑死在某个资源调度引擎上。而Framework则可以让Applicaiton 无需关注底层调度的事情,只要关注业务即可。
另外,你费尽心机开发的Framework上,你自然是希望它能跑在更多的平台上,已满足更多的人的需求,对吧。
基于Yarn开发容器调度系统的一些基本思路
首先我们需要了解两个概念:
哑应用。所谓哑应用指的是无法和分布式系统直接进行交互,分布式系统也仅仅透过容器能进行生命周期的控制,比如关闭或者开启的应用。典型的比如MySQL、Nginx等这些基础应用。他们一般有自己特有的交互方式,譬如命令行或者socket协议或者HTTP协议。
伴生组件。因为有了哑应用的存在,分布式系统为了能够和这些应用交互,需要有一个代理。而这个代理和被代理的哑应用,具有相同的生命周期。典型
的比如,某个服务被关停后,该事件会被分布式系统获知,分布式系统会将该事件发送给Nginx的伴生组件,伴生组件转化为Nginx能够识别的指令,将停
止的服务从Nginx的ProxyBackend列表中剔除。
在容器调度系统中,如果Yarn的NodeManager直接去管理Docker则需要Yarn本身去做支持,我觉得这是不妥的。Yarn的职责就是做好资源管理,分配,调度即可,并不需要和特定的某个技术耦合,毕竟Yarn是一个通用型的资源调度管理框架。
那基于上面的理论,我们基于Yarn,开发一套框架,这个框架会是典型的 master-slave结构(这是Yarn决定的)。这个框架的 slaves 其实都是Docker 的伴生对象。master 可以通过这些Slave 对容器实现间接的管理。
我们简单描述下他们的流程:
用户提交Application,申请资源;
Yarn启动Framework的master;
Yarn启动Framework的slave;
slave 连接上master,并且发送心跳,从而master知道slave的状况slave启动Docker,slave与被启动的这个docker container 一一对应;
slave定时监控Container;
slave发现container crash,slave自动退出,Yarn获得通知,收回资源;
master发现有节点失败,发出新的节点要求,重新在另外一台服务器上启动slave,重复从2开始的步骤。
这里还有一个问题,如果slave 被正常杀掉,可以通过JVM ShudownHook 顺带把Container也关掉。
但是如果slave被kill -9
或者异常crash掉了,那么就可能导致资源泄露了。目前是这个信息是由master上报给集群管理平台,该平台会定时清理。你也可以存储该信息,譬如放
到Redis或者MySQL中,然后启动后台清理任务即可。
了解了这个思路后,具体实施就变得简单了,就是开发一个基于Yarn的master-slave程序即可,然后slave去管理对应的Docker容器,包括接受新的指令。master提供管理界面展示容器信息,运行状态即可。
当然,你还可以再开发一套Framework B专门和Nginx交互,这样比如上面的系统做了节点变更,通知B的master,然后B的master 通过自己的伴生组件Slave 完成Nginx的更新,从而实现后端服务的自动变更和通知。
kafka是否适合在docker中使用?单机集群是否有意义
可替换的,在XML配置下,可以很方便的用你的实现替换掉原来的实现,没有太大的侵入性,所以就算是未来Yarn升级,也不会有太大问题。相比较而言,Mesos更像是一个已经做好的产品,部署了可以直接用,但是对二次开发并不友好。生态优势Yarn诞生于Hadoop这个大数据的“始作俑者”项目,所以在大数据领域具有先天优势。底层天然...
Kafka 的 Docker 部署
总之,Docker 部署 Kafka 提供了高效、灵活的解决方案,通过合理配置和安全措施的实施,可以实现高性能、高可靠性的 Kafka 集群。
Linux下利用Docker快速部署Kafka服务
首先,理解Kafka的基本概念:生产者(Producer)将数据发布到Topic,Topic再被划分为多个分区(Partition)以优化处理;Zookeeper负责集群协调。接下来,确保基础环境,如Ubuntu 22.04.3 LTS,安装并验证Docker。Kafka依赖Zookeeper,因此先部署Zookeeper,通过Docker镜像轻松拉取并启动。然后安装Kafka,同样通过Dock...
kafka 单机/集群压力测试
1.3 单机版测试kafka性能 因为测试的次数比较多,也没有去找kafka中数据存储设置,所以就使用docker部署单机版的kafka (因为测试的数据比较多,也就多次的删除了容器,重新启动镜像) 新建目录: mkdir /usr/local/kafka_test dockerfile run.sh sources.list 目录结构如下:生成镜像 docker bu...
走近Kafka:大数据领域的不败王者
配置与启动安装方式有多种,推荐使用docker。首先,进入配置文件目录进行必要的修改,然后分别启动Kafka服务器和Zookeeper服务,通过命令行监控启动状态。核心组件解析主题(Topic):逻辑分类,消息按Topic组织,消费时需指定topic。分区(Partition):解决单机性能瓶颈,消息分布到多个分区提高性能。副本(...
Docker中安装kafka && Python操作kafka
Docker中安装kafka 参考: blog.csdn.net/y39301624...直接启动(不建议) 启动过程中遇到各种问题,尝试后问题依然存在,故本人用该方法启动失败 用docker-compose 启动 docker-compose.yml 一定要指定OUTSIDE,否则代码连接kafka,消费者无法消费,没有任何反应 启动脚本 常用命令 Python操作kafka 创建...
kafka-docker上使用+常用指令
其中replication-factor作用是将任意分区复制到broker上,broker是物理概念,部署了一个kafka可认为broker数为1,我本机只有一个kafka所以这里replication-factor超过1会报错。 综上几个概念可以理解为:集群中有多个broker,创建主题时可以指明topic有多个partitions(消息拆分到不同分区进行存储,一个partion只能...
集群软件有哪些
集群软件主要包括:Hadoop、Spark、Kafka、Docker Swarm和Kubernetes。1. Hadoop:Hadoop是一个开源的分布式计算框架,主要用于处理大规模数据。它允许在廉价的硬件集群上进行分布式存储和计算。其核心组件包括HDFS(Hadoop分布式文件系统)和MapReduce。2. Spark:Apache Spark是一个快速的大数据处理引擎,用于处理...
docker启动kafka
docker exec -it zookeeper /bin/sh 这时查看zk节点只有一个zookeeper docker退出当前容器 快捷键:第一次尝试启动容器是用的第一种方式,后面发现在容器外面连接不了kafka,可能是因为生成的kafka地址是容器内地址。所以换了第二种方式启动。{"datas":[{"name":"jianshu","value":"10"}],"ver":...
kafka3.5.1(raft版本 sasl认证)集群docker部署
Kafka 3.5.1 Raft版本与SASL认证的集群Docker部署Kafka分布式消息队列集群在三台主机上分别构建,分别是192.168.59.20、192.168.59.21和192.168.59.22,集群采用先进的Raft模式,不再依赖Zookeeper,以实现更高效和可靠的服务。为了保证数据传输安全,尽管默认采用SASL认证下的非加密传输,但对敏感数据...