zookeeper+kafka消息队列群集部署

前言

        消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为:当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候。

一、消息队列

1:什么是消息队列

        消息(Message)是指在应用间传送的数据。消息可以非常简单,比如只包含文本字符串,也可以更复杂,可能包含嵌入对象。
        消息队列(Message Queue)是一种应用间的通信方式,消息发送后可以立即返回由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到MQ中而不用管谁来取,消息使用者只管从MQ中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。

2:为什么需要消息队列

(1)解耦

        允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。

(2)冗余

        消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。

(3)扩展性

        因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外
增加处理过程即可。

(4)灵活性& 峰值处理能力

        在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。

(5)可恢复性

        系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。

(6)顺序保证

        在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。(Kafka 保证一个 Partition 内的消息的有序性)

(7)缓冲

        有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情

(8)异步通信

        很多时候,用户不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。

二、Kafka基础与入门

1:kafka基本概念

        Kafka 是一种高吞吐量的分布式发布/订阅消息系统,这是官方对 kafka的定义,这样说起来,可能不太好理解,这里简单举个例子:现在是个大数据时代,各种商业、社交、搜索、浏览都会产生大量的数据。那么如何快速收集这些数据,如何实时的分析这些数据,是一个必须要解决的问题,同时,这也形成了一个业务需求模型,即生产者生产(produce)各种数据,消费者(consume)消费(分析、处理)这些数据。那么面对这些需求,如何高效、稳定的完成数据的生产和消费呢?这就需要在生产者与消费者之间,建立一个通信的桥梁,这个桥梁就是消息系统。从微观层面来说,这种业务需求也可理解为不同的系统之间如何传递消息。
        kafka 是 Apache 组织下的一个开源系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于 hadoop 平台的数据分析、低时延的实时系统storm/spark 流式处理引擎等。kafka 现在它已被多家大型公司作为多种类型的数据管道和消息系统使用。

2:kafka 角色术语

kafka 的一些核心概念和角色
(1)Broker:Kafka集群包含一个或多个服务器,每个服务器被称为 broker。
(2)Topic:每条发布到 Kafka 集群的消息都有一个分类,这个类别被称为Topic(主题)。
(3)Producer:指消息的生产者,负责发布消息到kafka broker。
(4)Consumer:指消息的消费者,从kafka broker 拉取数据,并消费这些已发布的消息。(5)Partition:Partition 是物理上的概念,每个Topic 包含一个或多个 Partition,每个 partition 都是一个有序的队列。partition 中的每条消息都会被分配一个有序的id(offset)
(6)Consumer Group:消费者组,可以给每个 Consumer 指定消费组,若不指定消费者组,则属于默认的 group。
(7)Message:消息,通信的基本单位,每个producer 可以向一个 topic 发布一些消息。

3:kafka拓扑架构

        一个典型的 Kafka 集群包含若干 Producer,若干 broker、若干 consumer Group,以及一个 Zookeeper 集群。Kafka通过 Zookeeper 管理集群配置,选举 leader,以及在Consumer Group 发生变化时进行 rebalance。Producer 使用 push 模式将消息发布到broker,Consumer 使用 pu11 模式从 broker 订阅并消费消息。典型架构如下图所示:

        从图中可以看出,典型的消息系统有生产者(Producer),存储系统(broker)和消费者(Consumer)组成,Kafka作为分布式的消息系统支持多个生产者和多个消费者,生产者可以将消息分布到集群中不同节点的不同 Partition 上,消费者也可以消费集群中多个节点上的多个 Partition。在写消息时允许多个生产者写到同一个 Partition 中,但是读消息时一个 Partition 只允许被一个消费组中的一个消费者所消费,而一个消费者可以消费多个 Partition。也就是说同一个消费组下消费者对 Partition 是互斥的,而不同消费组之间是共享的

        kafka 支持消息持久化存储,持久化数据保存在 kafka 的日志文件中,在生产者生产消息后,kafka不会直接把消息传递给消费者,而是先要在 broker 中进行存储,为了减少磁盘写入的次数,broker 会将消息暂时缓存起来,当消息的个数或尺寸、大小达到一定阀值时,再统一写到磁盘上,这样不但提高了 kafka 的执行效率,也减少了磁盘 I0 调用次数

        kafka 中每条消息写到 partition 中,是顺序写入磁盘的,这个很重要,因为在机械盘中如果是随机写入的话,效率将是很低的,但是如果是顺序写入,那么效率却是非常高这种顺序写入磁盘机制是 kafka 高吞吐率的一个很重要的保证。 

4:Topic 和 partition

        Kafka 中的 topic(主题)是以 partition 的形式存放的,每一个 topic 都可以设置它的 partition数量,Partition的数量决定了组成topic的log的数量。推荐partition的数量一定要大于同时运行的 consumer 的数量。另外,建议 partition 的数量要小于等于集群 broker 的数量,这样消息数据就可以均匀的分布在各个 broker 中

        那么Topic 为什么要设置多个 Partition 呢,这是因为 kafka 是基于文件存储的,通过配置多个partition 可以将消息内容分散存储到多个broker 上,这样可以避免文件尺寸达到单机磁盘的上限。同时,将一个 topic切分成任意多个 partitions,可以保证消息存储、消息消费的效率,因为越多的 partitions 可以容纳更多的 consumer,可有效提升Kafka 的吞吐率。因此,将 Topic 切分成多个 partitions 的好处是可以将大量的消息分成多批数据同时写到不同节点上,将写请求分担负载到各个集群节点。

        在存储结构上,每个 partition 在物理上对应一个文件夹,该文件夹下存储这个partition 的所有消息和索引文件。partiton 命名规则为 topic 名称+序号,第一个partiton 序号从日开始,序号最大值为partitions 数量减 1。

        在每个 partition(文件夹)中有多个大小相等的 segment(段)数据文件,每个segment 的大小是相同的,但是每条消息的大小可能不相同,因此 segment<br/>数据文件中消息数量不一定相等。segment 数据文件有两个部分组成,分别为 index file 和 datafile,此两个文件是一一对应,成对出现,后缀”.index“和“.1og”分别表示为 segment索引文件和数据文件。

5:Producer生产机制

        Producer 是消息和数据的生产者,它发送消息到 broker 时,会根据 Paritition 机制选择将其存储到哪一个 Partition。如果 Partition 机制设置的合理,所有消息都可以均匀分布到不同的 Partition 里,这样就实现了数据的负载均衡。如果一个 Topic 对应一个文件,那这个文件所在的机器 I/0 将会成为这个 Topic 的性能瓶颈,而有了 Partition后,不同的消息可以并行写入不同 broker 的不同 Partition 里,极大的提高了吞吐率。

6:Consumer 消费机制

        Kafka 发布消息通常有两种模式:队列模式(queuing)和发布/订阅模式(publish-subscribe)。在队列模式下,只有一个消费组,而这个消费组有多个消费者,一条消息只能被这个消费组中的一个消费者所消费;而在发布/订阅模式下,可有多个消费组,每个消费组只有一个消费者,同一条消息可被多个消费组消费。Kafka 中的 Producer 和 consumer 采用的是 push、pull 的模式,即 producer 向 broker进行 push 消息,comsumer 从 bork 进行 pu11 消息,push 和 pu1l 对于消息的生产和消费是异步进行的。pu11模式的一个好处是 consumer 可自主控制消费消息的速率,同时

三、单节点部署 kafka

主机:
kafka1:192.168.10.101

 

 

 四、群集部署 kafka

主机
kafka1: 192.168.10.101
kafka2:192.168.10.102
kafka3:192.168.10.103

 

 

  • 26
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
好的,以下是一个基本的在k8s上部署zookeeper + kafka集群的配置教程: 1. 创建一个namespace 首先,我们需要创建一个namespace,用于部署zookeeperkafka集群。可以使用以下命令创建一个名为“zookeeper-kafka”的namespace: ``` kubectl create namespace zookeeper-kafka ``` 2. 部署Zookeeper 接下来,我们需要部署Zookeeper。可以使用以下YAML文件创建一个Zookeeper服务: ``` apiVersion: v1 kind: Service metadata: name: zookeeper spec: selector: app: zookeeper ports: - name: client port: 2181 protocol: TCP - name: follower port: 2888 protocol: TCP - name: leader port: 3888 protocol: TCP --- apiVersion: apps/v1 kind: StatefulSet metadata: name: zookeeper spec: serviceName: zookeeper replicas: 3 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: zookeeper:3.5.8 ports: - name: client containerPort: 2181 - name: follower containerPort: 2888 - name: leader containerPort: 3888 volumeMounts: - name: datadir mountPath: /data env: - name: ZOO_MY_ID valueFrom: fieldRef: fieldPath: metadata.name - name: ZOO_SERVERS value: zookeeper-0.zookeeper:2888:3888,zookeeper-1.zookeeper:2888:3888,zookeeper-2.zookeeper:2888:3888 volumeClaimTemplates: - metadata: name: datadir spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi ``` 这将创建一个3个Pod的Zookeeper StatefulSet,并创建一个名为“zookeeper”的Service,暴露Zookeeper的客户端端口2181,follower端口2888和leader端口3888。 3. 部署Kafka 现在,我们可以部署Kafka。以下是一个Kafka部署的YAML文件示例: ``` apiVersion: v1 kind: Service metadata: name: kafka spec: type: NodePort selector: app: kafka ports: - name: kafka port: 9092 nodePort: 30092 protocol: TCP --- apiVersion: apps/v1 kind: StatefulSet metadata: name: kafka spec: serviceName: kafka replicas: 3 selector: matchLabels: app: kafka template: metadata: labels: app: kafka spec: containers: - name: kafka image: wurstmeister/kafka:2.13-2.7.0 ports: - name: kafka containerPort: 9092 env: - name: KAFKA_BROKER_ID valueFrom: fieldRef: fieldPath: metadata.name - name: KAFKA_ZOOKEEPER_CONNECT value: zookeeper-0.zookeeper:2181,zookeeper-1.zookeeper:2181,zookeeper-2.zookeeper:2181 - name: KAFKA_ADVERTISED_LISTENERS value: PLAINTEXT://$(hostname -f):9092 - name: KAFKA_LISTENERS value: PLAINTEXT://0.0.0.0:9092 - name: KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR value: "3" volumeMounts: - name: datadir mountPath: /data volumeClaimTemplates: - metadata: name: datadir spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi ``` 这将创建一个3个Pod的Kafka StatefulSet和一个名为“kafka”的Service,它将Kafka的9092端口暴露为NodePort 30092。 4. 验证部署 现在,您可以使用以下命令检查ZookeeperKafka是否正在运行: ``` kubectl get pods -n zookeeper-kafka ``` 您应该看到3个Zookeeper和3个Kafka Pod处于“Running”状态。 接下来,您可以使用以下命令检查Kafka是否正在监听端口30092(或您自己选择的端口): ``` kubectl get services -n zookeeper-kafka ``` 您应该看到一个名为“kafka”的service,它将Kafka的9092端口暴露为30092端口。可以使用此端口测试Kafka是否正常运行。 至此,您已经成功地在k8s上部署zookeeper + kafka集群。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

H-J-L

求打赏

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值