Kafka
传统定义：分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。是开源的分布式时间流平台，被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用
发布/订阅：消息的发布者不会将消息直接发送给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接受感兴趣的消息
常见的消息队列:Kakfa、ActiveMQ、RabbitMQ
在大数据场景主要常用Kafka。JavaEE开发主要采用ActiveMQ、RabbitMQ、RocketMQ
消息队列主要应用场景：缓冲/消峰、解耦、异步通信
缓冲/消峰：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息处理速度不一致的情况
解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束
异步通信：允许用户吧一个消息放入队列，但并不立即处理它，然后在需要的时候再去处理它们
消息队列的两种模式：点对点模式、发布/订阅模式
点对点模式（不利于处理复杂业务场景）
消费者主动拉取数据，消息收到后清除消息（一个生产者对一个消费者）
发布/订阅模式
- 可以有多个topic主题（浏览、点赞、收藏、评论等）
- 消费者消费数据后，不删除数据
- 每个消费者相互独立，都可以消费到数据
Kafka的基础架构
- 为了方便扩展，并提高吞吐量，一个topic分为多个partition
- 配合分区的设计，提出消费者组的概念，组内每个消费者并行消费
- 一个分区智只能给一个消费者消费，不然不利于管理
- 为提高可用性，为每个分区增加若干副本，类似NameNode HA；副本分为leader和follower，生产消费只针对leader，leader挂follower可以成为leader
- Zookeeper：记录整个集群服务器结点运行状态、记录每个分区的leader相关信息。Kafka2.8.0以后配置可以不采用Zookeeper
Broker：kafka集群包含一个或多个服务器，服务器节点成为broker
Topic：
- 每条发布到kafka集群的消息都有一个类别，这个类别成为topic。
- 物理上不同的Topic的消息是分开存储的。
- 逻辑上一个Topic的消息虽然保存于一个或多个broker上但是用户只需要指定消息的Topic即可生产消费数据并不需要关注数据存于何处
Partition：
- Topic中数据分割一个或者多个partition
- 每个topic至少有一个partition，当生产者生产数据的时候，根据分配策略，选择分区，然后将消息追加到指定的分区末尾
- 每条消息都有一个自增序号标识顺序和消息的偏移量
- Partition中的数据是有序的，不同的分区间的数据丢失了数据的顺序
- 如果topic有多个分区，消费数据时无法保证数据的顺序，严格保证消费顺序的场景下，需要将分区设为1
Leader
每个partition有多个副本，其中有且只有一个作为leader，负责数据读写
Follower（只负责备份）
- Follower跟随Leader，所有写请求都通过Leader，数据变更会广播给所有从节点，从节点和主节点保持数据同步
- 如果主节点失效，重新在从节点选举主节点
- 当从节点挂掉或者同步太慢，主节点会吧从节点从”in sync replicas”(ISR)列表中删除，重新创建从节点
Producer
生产者将消息发布到kafka的Topic中，broker接收到生产者的消息后，将消息追加数据到segment文件中，生产者发送的消息存储到一个partition中，生产者也可以指定数据存储的partition
Consumer
消费者可以从broker中读取数据，消费者可以消费多个Topic中的数据
Consumer group
- 每个消费者属于一个特定的消费者组，可以指定组名，不加则属于默认组
- 将多个消费者集中到一起去处理某一个Topic数据，可以更快的提高数据消费
- 整个消费者组共享一组偏移量（防止数据被重复读取），因为一个Topic多个分区
- 一个消费者组只从broker读取一次数据
Offset偏移量
- 唯一标识一条消息
- 偏移量决定读取消息的位置，不会出现线程安全的问题，消费者通过偏移量来决定下次读取的消息
- 消息被消费之后不会马上删除，这样多个业务可以重复使用kafka的消息
- 可以通过修改偏移量达到重新读取消息的目的，偏移量由用户控制
- 消息最终还是会被删除，生命周期为一周7*24
单播消息
一个消费组里只能有一个消费者消费消息
Kafka快速入门
进入官网下载kafka，连接Linux虚拟机并传入，解压：
tar -zxvf kafka_2.12-3.0.0.tgz -C ~/kafka（解压目标位置）
修改名称：mv kafka_2.12-3.0.0 kafka
唯一标识，不能重复
消息数据存储位置，默认Linux临时文件，会定期清除，所以需要修改
Zookeeper连接，默认本地
运行kafka:
cd ./kafka
./bin/kafka-server-start.sh ./config/server.properties
消息生产和发布
创建一个主题
bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic heima --partitons 2 --replication-factor 1
--zookeeper：指定kakfa连接zookeeper的地址
--topic：指定创建的主题名
--partitions：指定分区的个数，发布消息是发送到主题的分区中
--replication-factor：指定副本因子
--create：创建主题的动作指令
查看所有topic
./bin/kafka-topics.sh --list --bootstrap-server 192.168.235.137:9092
在Topic中生产消息
./bin/kafka-console-producer.sh --topic wangting --broker-list 192.168.235
消费者消费某topic上的消息
./bin/kafka-console-consumer.sh --from-beginning -topic wangting --bootstrap-server 192.168.235.137:9092
Kafka集群
可扩展性：集群的性能不限制于单一服务实体，新的服务实体可以动态的恶添加到集群，从而增强集群的性能
高可用性：集群当其中一个结点发生故障时，这台结点上所运行的应用程序将在另一台结点上自动换管
集群的能力
负载均衡：负载均衡吧人物比较均匀的分布到集群环境下的计算和网络资源，以提高数据吞吐量
错误恢复：如果集群中某一台服务器发生故障无法使用，资源和应用程序可转移到可用的集群结点上。
Broker：每个Broker即kafka服务实例，多个Broker构成kafka集群，生产者发布的消息将保存在Broker中，消费者从Broker中拉取消息进行消费
Zookeeper：通过Zookeeper管理自身集群，如：Broker列表管理、Partition与Broker的关系、Partition与Consumer的关系、Producer与Consumer负载均衡、消费进行Offset记录、消费者注册等。为了达到高可用，zookeeper也必须是集群
1.搭建Zookeeper集群并启动
2.将原来的kafka目录复制多份，日志目录同时也要复制多份，重新开启集群需要将日志目录中的内容全部清空。
3.编辑配置文件：broker.id用于标识区分broker；其他broker的日志目录修改；zookeeper.connect连接ip：要将zookeeper集群的几个服务器都填上去
副本就是为了主题中的分区进行多个备份，副本之间会选举一个leader多个follower。
Isr即可用的结点（可以同步和已同步节点存入isr集合），当Isr有个节点性能较差，则会被踢出集合中，Leader会从Isr中选举出
集群有多个broker，创建主题时可以指明该主题有多少个分区（把消息拆分在不同的分区中存储），可以为分区创建多个副本，不同的副本存入不同的Broker
