一、Kafka-课程介绍
官网地址：Apache KafkaApache Kafka: A Distributed Streaming Platform.
https://kafka.apache.org/
kafka 3.6.1版本，作为经典分布式订阅、发布的消息传输中间件，kafka在实时数据处理、消息队列、流处理等领域具有广泛的应用场景。高性能、高可靠、高吞吐，被数千家公司应用于高性能的数据管道、流分析和数据集成等不同场景，在海量实时数据传输和事件驱动的微服务架构中也被广泛地使用。
学习步骤：
1、kafka集群启动
2、主题创建
3、生产消息
4、存储消息
5、消费消息
大数据场景中，我们将kafka和Flume、Spark和Flink等软件进行集成，那么kafka依然用作数据传输的消息中间件，那Flume就作为producer生产者来生产数据，而我们的Spark和Flink分布式计算引擎就作为consumer消费者来消费数据
三、Kafka-软件介绍
为什么分布式系统之间它需要使用一个软件来完成数据交换的这个过程？那说到我们数据交换啊，在java开发的这个普通场景中，主要指的就是线程和线程之间的数据交换以及呢进程和进程之间的数据交换。我们线程和线程之间是如何做数据交换的，其实呢我们主要是用内存来完成这个操作的。
首先我们的java虚拟机当中，每个线程呢其实是有它独立的这个栈内存空间的，每个线程是独立的，那么这两个我们的线程它们是如何交互的呢？首先它们两块内存是独立的，不过呢java虚拟机还有一块内存是它们共享的，这块内存呢我们称之为堆内存，咱们这个堆内存呢，其实就是我们所有线程共享的，那既然是所有线程共享的，那么是不是就可以将线程的数据发送到这块内存当中呢？这个肯定是没有问题的，那我们另外一个线程啊，其实就可以想办法呢，从这个堆内存当中把数据给我获取过来，因为你是共享的吗？你共享的话，你的数据放进去，我这边应该是可以获取到的，这个应该是没有问题的，那么为了数据的操作方便，java还提供了专门的数据模型Q来作为数据的缓冲区进行数据的传输，就是我们通过一种队列的方式来完成，比较常见的呢就是阻塞队列啊BlockingQueue或者那个双端队列DQ啊等等。其实我们通过内存就可以实现我们数据的传输了，那么根本也不需要额外的第三方软件来完成。（缺点会导致内存不够用了，内存溢出）
接下来再说说进程和进程之间的数据交互，我们在执行java程序的时候，就会启动一个java虚拟机的进程，那这个时候呢如果你想启用第二个进程的话，那它们两个能不能共享内存来完成我们的数据交互呢？其实是不行的，为什么呢？因为我们的java虚拟机啊，它在启动的时候会向操作系统申请内存，意味着两个不同的进程它们申请的内存其实是不一样的，那也就是说每个进程的内存空间是独立的，它们无法共享，因此我们进程之间传递数据呢都是采用网络数据流来进行传输的，比如我们使用java提供的基础的socket、ServerSocket这样的接口来实现网络的数据传输（数据需要重复发送）
缓冲区【消息中间件】
四、Kafka-JMS介绍
Java Message Service【JMS】
P2P模型
PS模型
五、Kafka-组件
六、Kafka-安装与启动
windows安装步骤：
1、解压 kafka_2.12-3.7.0.tgz
2、kafka_2.12-3.7.0目录下新建data目录
3、修改config目录下的zookeeper.properties
dataDir=D:/xxx/kafka_2.12-3.7.0/data/zk
4、在kafka_2.12-3.7.0目录下新建zk.cmd文件
call bin/windows/zookeeper-server-start.bat config/zookeeper.properties
5、双击zk.cmd，启动zookeeper
6、修改config目录下的server.properties
log.dirs=D:/gitee/kafka_2.12-3.7.0/data/kafka
7、在kafka_2.12-3.7.0目录下新建kfk.cmd文件
call bin/windows/kafka-server-start.bat config/server.properties
8、双击kfk.cmd，启动kafka
十三、Kafka-基础架构图形推演
数据只保存在内存中是不安全的，我们需要把数据保存到日志文件中。为什么是日志文件呢？就是因为kafka早期就是做日志数据传输的，所以它的文件就叫做.log
架构
kafka采用生产者消费者的模型，所以它是允许多个生产者来生产数据，同时呢它也允许多个消费者来消费数据
有没有发现什么问题？我们当前的这个Kafka Broker 有很多的生产者和消费者对它进行访问，这个频繁的数据请求访问呢？大概率就会因为吞吐量过大产生IO热点问题，从而导致这个单一的这个节点成为整个分布式系统的性能瓶颈，进行就会降低系统的可用性和稳定性，一旦我们当前的Broker它宕掉了，那我们的数据其实就无法访问了，你连服务都没有了，怎么可能访问数据呢？
横向扩展：增加服务节点，搭建服务器集群，降低单点故障带来的风险（增加多个Broker节点，把Topic划分为多个数据块【添加编号进行区分】，放在多个Broker节点，消费者添加消费者组）
纵向扩展：增加系统的资源配置，比如使用IO效率更好的固态硬盘以及更大的内存、更多的CPU核，还有更快的网络（其实无法从根本上解决问题的，咱们的资源是有限的，一旦单机的吞吐量超过阈值，无论你增加什么样的资源都是无法解决问题的）
)
