消息中间件--Kafka

最新推荐文章于 2024-09-20 17:45:24 发布

ElenaYu

最新推荐文章于 2024-09-20 17:45:24 发布

阅读量715

点赞数 1

分类专栏： Java 文章标签： Kafka

本文链接：https://blog.csdn.net/yu1014745867/article/details/84766730

版权

Java 专栏收录该内容

31 篇文章 0 订阅

订阅专栏

一、消息中间件

消息

是指软件对象之间进行交互作用和通讯利用的一种方式。
在这里插入图片描述

中间件（Middleware）

中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通讯。是连接两个独立应用程序或独立系统的软件。相连接的系统，即使它们具有不同的接口，但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递。通过中间件，应用程序可以工作于多平台或OS环境。
如图所示，中间件是位于平台（硬件和操作系统）和应用之间的通用服务，这些服务具有标准的程序接口和协议。
在这里插入图片描述

非底层操作系统软件，非业务应用软件，不是直接给最终用户使用的，不能直接给客户带来价值的软件统称为中间件。
根据其应用的不同，中间件分为：

一类是底层中间件，用于支撑单个应用系统或解决一类问题，包括交易中间件(TPM)、应用服务器、消息中间件（MOM）、数据访问中间件(UDA)，远程调用中间件（RPC）等等；
另一类是高层中间件，更多的用于系统整合，包括企业应用集成中间件、工作流中间件、门户中间件等，他们通常会与多个应用系统打交道，在系统中层次较高，并大多基于前一类的底层中间件运行。

消息中间件

关注于数据的发送和接收，利用高效可靠的异步消息传递机制集成分布式系统。
在这里插入图片描述

二、kafka 简介

Kafka目前主要作为一个高吞吐量的、持久性的、分布式发布订阅消息系统使用。
三大特点：

高吞吐量
可以满足每秒百万级别消息的生产和消费——生产消费。
持久性
有一套完善的消息存储机制，确保数据的高效安全的持久化——中间存储。
分布式
基于分布式的扩展和容错机制；Kafka的数据都会复制到几台服务器上。当某一台故障失效时，生产者和消费者转而使用其它的机器——整体健壮性。

Kafka的使用场景

日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr、hive等。
消息系统：解耦和生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
流式处理：比如spark streaming和storm
事件源

Kafka组件

一个MQ需要生产、消费、消息类别、存储等等。
对于kafka而言，kafka服务就像是一个大的水池。不断的生产、存储、消费着各种类别的消息。那么kafka由何组成呢？

Kafka服务：
Topic：主题，Kafka处理的消息的不同分类。每个topic都是有分区的
Broker：消息代理，Kafka集群中的一个kafka服务节点称为一个broker，主要存储消息数据。存在硬盘中。
Partition：Topic物理上的分组，一个topic在broker中被分为1个或者多个partition，分区在创建topic的时候指定。
Message：消息，是通信的基本单位，每个消息都属于一个partition
Kafka服务相关:
Producer：消息和数据的生产者，向Kafka的一个topic发布消息。
Consumer：消息和数据的消费者，定于topic并处理其发布的消息
Zookeeper：协调kafka的正常运行。每个消息（也叫作record记录,也被称为消息）是由一个key，一个value和时间戳构成

基本原理

在这里插入图片描述

一个典型的Kafka集群中包含若干Producer（可以是web前端FET，或者是服务器日志等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干ConsumerGroup，以及一个Zookeeper集群。Kafka通过Zookeeper管理Kafka集群配置：选举Kafka broker的leader，以及在Consumer Group发生变化时进行rebalance，因为consumer消费kafka topic的partition的offsite信息是存在Zookeeper的。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

kafka服务器消息存储策略

谈到kafka的存储，就不得不提到分区，即partitions，创建一个topic时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中。
在这里插入图片描述

在每个分区中，消息以顺序存储，最晚接收的的消息会最后被消费。
在这里插入图片描述

与生产者的交互

在这里插入图片描述
生产者在向kafka集群发送消息的时候，可以通过指定分区来发送到指定的分区中
也可以通过指定均衡策略来将消息发送到不同的分区中
如果不指定，就会采用默认的随机均衡策略，将消息随机的存储到不同的分区中.

与消费者的交互

在这里插入图片描述
在消费者消费消息时，kafka使用offset来记录当前消费的位置
在kafka的设计中，可以有多个不同的group来同时消费同一个topic下的消息，如图，我们有两个不同的group同时消费，他们消费的记录位置offset各不项目，不互相干扰。
对于一个group而言，消费者的数量不应该多余分区的数量，因为在一个group中，每个分区至多只能绑定到一个消费者上，即一个消费者可以消费多个分区，一个分区只能给一个消费者消费
因此，若一个group中的消费者数量大于分区数量的话，多余的消费者将不会收到任何消息。

三、Kafka查看数据

Linux kafka shell脚本

如何查看目前的消费者是否已经读到最新的数据：

/usr/hdp/current/kafka-broker/bin/kafka-console-consumer.sh --bootstrap-server 172.17.20.119:9092,172.17.20.137:9092 --topic AdControlOut20180911 --from-beginning | grep **

kafka-console-consumer.sh kafka消费者控制台 https://blog.csdn.net/feelwing1314/article/details/81047613
bootstrap-server 172.17.20.119:9092,172.17.20.137:9092 服务，集群
topic AdControlOut20180911 主题
from-beginning 从最早的消息开始消费，默认是从最新消息开始消费