1. 为什么使用消息队列?

解耦: 解耦数据的处理过程。

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

扩展性:因为消息队列解耦了处理过程。 所以增大消息入队和处理的频率是很容易的。 只要另外增加处理过程即可。 不需要改变代码,不需要调节参数。

峰值处理能力:

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

可恢复性:

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

顺序保证:

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

异步通信:

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

缓冲:(不懂)在任何重要的系统中,都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。

用于数据流:(不懂)

在一个分布式系统里,要得到一个关于用户操作会用多长时间及其原因的总体印象,是个巨大的挑战。消息系列通过消息被处理的频率,来方便的辅助确定那些表现不佳的处理过程或领域,这些地方的数据流都不够优化。

2.为什么使用kafka

支持多个生产者

不管客户端使用单个主题还是多个主题。所以它很适合用来从多个前端系统收集数据, 并以统一的格式对外提供数据。

 

多个消费者

除了支持多个生产者外, kafka支持多个消费者从一个单独的消息流上读取数据。而且消费者之间互不影响。 这与其他队列系统不同,其他队列系统的消息一旦被一个客户端读取,其他客户端无法再读取它,另外,多个消费者可以组成一个群组,他们共享一个消息流,并保证整个群组对每个给定的消息只处理一次。

基于磁盘的数据存储

Kafka 不仅支持多个消费者,还允许消费者非实时地读取消息,这要归功于 Kafka 的数据

保留特性。消息被提交到磁盘,根据设置的保留规则进行保存。每个主题可以设置单独的

保留规则,以便满足不同消费者的需求,各个主题可以保留不同数量的消息。消费者可能

会因为处理速度慢或突发的流量高峰导致无陆及时读取消息,而持久化数据可以保证数据

不会丢失。消费者可以在进行应用程序维护时离线一小段时间,而无需担心消息丢失或堵

塞在生产者端。 消费者可以被关闭,但消息会继续保留在 Kafka 里。消费者可以从上次中

断的地方继续处理消息。

伸缩性

为了能够轻松处理大量数据, Kafka 从一开始就被设计成一个具有灵活伸缩性的系统。用

户在开发阶段可以先使用单个 broker,再扩展到包含 3 个 broker 的小型开发集群,然后随着数据盐不断增长,部署到生产环境的集群可能包含上百个 broker。对在线集群进行扩展丝毫不影响整体系统的可用性。也就是说, 一个包含多个 broker 的集群,即使个别 broker失效,仍然可以持续地为客户提供服务。要提高集群的容错能力,需要配置较高的复制系数

高性能

上面提到的所有特性,让 Kafka 成为了一个高性能的发布与订阅消息系统。通过横向扩展

生产者、消费者和 broker, Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时,

它还能保证亚秒级的消息延迟。

3.相关概念介绍

3.1分区

Kaflca 通过分区来实现数据冗余和伸缩性。

区可以分布在不同的服务器上,也就是说, 个主题可以横跨多个服务器,以此来提供比
个服务器更强大的性能。

kafka的特点应用场景搭建过程

我们通常会使用流这个词来描述 Kaflca 这类系统的数据

3.2生产者

一般情况下,一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均衡地分布到
主题的所有分区上,而并不关心特定消息会被写到哪个分区。不过,在某些情况下,生产
者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的,分区器为键生成一个散列值,并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器,根据不同的业务规则将消息映射到分

3.3消费者

消费者订个或多个主题,并按照消息生成的顺序读取它们。消费者通过检查消息的偏移盘来区
分已经读取过的消息。 偏移量是另种元数据,它是个不断递增的整数值,在创建消息时, Kafka 会把它添加到消息里。在给定的分区里,每个悄息的偏移量都是唯的。消费者把每个分区最后读取的悄息偏移量保存在 Zookeeper Kafka 上,如果悄费者关闭或重启,它的读取状态不会丢失。

 

3.4消费者的群组关系

消费者是消费者群组的部分,也就是说,会有个或多个消费者共同读取个主题 组保证每个分区只能被个消费者使用 。图 1-6 所示的群组中,有 3 消费者同时读取个主题。其中的两个消费者各自读取个分区,另外个消费者读取其他两个分区。消费者与分区之间的映射通常被称为悄费者对分区的所有权关系

kafka的特点应用场景搭建过程

 

3.5broker

一个独立的kafka服务器被称为broker. broker 收来自 生产者的消息,为消息设置偏移
量,并提交消息到磁盘保存。 broker 为消费者提供服务,对读取分区的请求作出响应,返
回已经提交到磁盘上的消息。根据特定的硬件及其性能特征,单个 broker 可以轻松处理数
千个分区以及每秒百万级的消息量。

broker 是集群的组成部分。每个集群都有 broker 同时充当了集群控制器的角色(自动
从集群的活跃成员中选举出来)。控制器负责管理工作,包括将分区分配给 broker 和监控
broker. 在集群中, 个分区从属于 broker, i broker 被称为分区的首领 。一个分
可以分配给多个 broker,这个时候会发生分区复制(见图 1-7 )。这种复制机制为分区提供
了消息冗余,如果有一个 broker 失效,其他 broker 可以接管领导权。不过,相关的消费者
和生产者都要重新连接到新的首领。第 6 章将详细介绍集群的操作,包括分区复制。

保留消息(在定期限内)是 Kafka 个重要特性。 Kafka broker 默认的消息保留策略
是这样的:要么保留段时间(比如 7 天),要么保留到消息达到一定大小的字节数(比
lGB )。当消息数量达到这些上限时,旧消息就会过期井被除,所以在任何时刻,
用消息的总量都不会超过配置参数所指定的大小。主题可以配置自己的保留策略,可以将
悄息保留到不再使用它们为止。例如,用于跟踪用户活动的数据可能需要保留几天,而应
用程序的度量指标可能只需要保留几个小时。可以通过配置把主题当作紧凑型日志, 只有
最后个带有特定键的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适
用,因为人们只关心最后时刻发生的那个变更。

broker的消息复制

kafka的特点应用场景搭建过程

4.环境搭建

总体环境

虚拟机centos 64

jdk usr/java

下载地址

https://pan.baidu.com/s/18IicPYf7W0j-sHBXvfKyyg?errno=0&errmsg=Auth%20Login%20Sucess&&bduss=&ssnerror=0&traceid=

 

zookeeper

usr/local/zookeepercluster/zookeeper1

usr/local/zookeepercluster/zookeeper2

usr/local/zookeepercluster/zookeeper3

下载地址:

https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/

4.1zookeeper集群搭建

构建一个这样的目录/usr/local/zookeepercluster/zookeeper1

cp -r zookeeper1/ zookeeper2

cp -r zookeeper1/ zookeeper3

 

4.1.1配置zookeeper  data/myid

[[email protected] zookeepercluster]# cd zookeeper1

[[email protected] zookeeper1]# mkdir data

[[email protected] zookeeper1]# cd data

[[email protected] data]# echo 1>>myid

2和3也按照这个配置. id分别是2和3

4.1.2配置zoo.cfg

  1. 把zookeeper1下conf目录下的zoo_sample.cfg文件复制一份改名为zoo.cfg

kafka的特点应用场景搭建过程

  1. 修改zoo.cfg的配置

zookeeper1

kafka的特点应用场景搭建过程

zookeeper2

kafka的特点应用场景搭建过程

(2881是投票端口, 3881是选举端口)

 

4.1.3创建快捷启动zookeepercluster/start.sh

./zookeeper1/bin/zkServer.sh start

./zookeeper2/bin/zkServer.sh start

./zookeeper3/bin/zkServer.sh start

 

4.1.4创建快捷关闭shutdown.sh

./zookeeper1/bin/zkServer.sh stop

./zookeeper2/bin/zkServer.sh stop

./zookeeper3/bin/zkServer.sh stop

4.1.5启动集群

[[email protected] zookeepercluster]# ./start.sh

4.1.6查看集群状态

[[email protected] zookeepercluster]# zookeeper1/bin/zkServer.sh status

显示结果

JMX enabled by default

Using config: /usr/local/zookeepercluster/zookeeper1/bin/../conf/zoo.cfg

Mode: follower

 

4.1.7zookeeper的日志配置

 附:Zookeeper默认会将控制台信息输出到启动路径下的zookeeper.out中,显然在生产环境中我们不能允许Zookeeper这样做,通过如下方法,可以让Zookeeper输出按尺寸切分的日志文件:

    修改conf/log4j.properties文件,将

    zookeeper.root.logger=INFO, CONSOLE

    改为

    zookeeper.root.logger=INFO, ROLLINGFILE

    修改bin/zkEnv.sh文件,将

    ZOO_LOG4J_PROP="INFO,CONSOLE"

    改为

    ZOO_LOG4J_PROP="INFO,ROLLINGFILE"

    然后重启zookeeper,就ok了

 附:Zookeeper默认会将控制台信息输出到启动路径下的zookeeper.out中,显然在生产环境中我们不能允许Zookeeper这样做,通过如下方法,可以让Zookeeper输出按尺寸切分的日志文件:

    修改conf/log4j.properties文件,将

    zookeeper.root.logger=INFO, CONSOLE

    改为

    zookeeper.root.logger=INFO, ROLLINGFILE

    修改bin/zkEnv.sh文件,将

    ZOO_LOG4J_PROP="INFO,CONSOLE"

    改为

    ZOO_LOG4J_PROP="INFO,ROLLINGFILE"

    然后重启zookeeper,就ok了

 

4.2kafka安装

下载地址

http://archive.apache.org/dist/kafka/0.9.0.1/

如下目录

usr/local/kafkacluster/kafka1

usr/local/kafkacluster/kafka2

4.2.1编辑配置文件

vi  kafka1/config/server.properties

主要修改以下内容(ip改成localhost也行)

broker.id=0

listeners=PLAINTEXT://:9092

port=9092

host.name=192.168.0.107

advertised.host.name=192.168.0.107

advertised.port=9092

zookeeper.connect=localhost:2181

4.2.2启动节点1

[[email protected] kafkacluster]# kafka1/bin/kafka-server-start.sh -daemon kafka1/config/server.properties

4.2.3测试创建topic

[[email protected] kafkacluster]# kafka1/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

 

[[email protected] bin]# ./kafka-topics.sh --create --zookeeper localhost:2181,localhost:2182,localhost:2183 --replication-factor 1 --partitions 1 --topic lytest

4.2.4测试topic

[[email protected] kafkacluster]# kafka1/bin/kafka-topics.sh --describe --zookeeper localhost:2181,localhost:2182,localhost:2183

 

4.2.5测试生产者

kafka1/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test   

[[email protected] kafkacluster]# kafka1/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic testhome

Test Message 1

Test Message 2

^C[[email protected] kafkacluster]#

4.2.6测试消费者

kafka1/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning 

[[email protected] kafkacluster]# kafka1/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic testhome --from-beginning

Test Message 1

Test Message 2

^CProcessed a total of 2 messages

4.2.7kafka关闭

kafka1/bin/kafka-server-stop.sh

4.2.8完整的创建topic,测试生产,测试消费

[[email protected] kafkacluster]# kafka1/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic ly

Created topic "ly".

[[email protected] kafkacluster]# kafka1/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic ly

this a message

^C[[email protected] kafkacluster]# kafka1/bin/kafka-console-consumer.sh --zookeeper localst:2181 --topic ly --from-beginning

this a message

未完待续>>>>

 

相关文章:

  • 2021-04-13
  • 2021-11-17
  • 2021-06-11
  • 2022-02-09
  • 2021-11-20
  • 2021-11-21
猜你喜欢
  • 2022-02-09
  • 2022-02-09
  • 2021-05-11
  • 2021-06-27
  • 2021-12-01
  • 2021-11-19
  • 2021-08-04
相关资源
相似解决方案