Kafka基础定义
kafka是什么？为什么要用Kafka（消息队列）？Kafka传输消息的格式是什么？Kafka的消息传输模型 Kafka常见支持的客户端语言Kafka核心术语
主题（Topic）客户端（Clients）生产者（Producer）消费者（Consumer）服务器端（Broker）Kafka集群备份机制（Replication）——高可用方案分区机制（Partition）——扩展（可伸缩）方案分区位移（Offset）消息日志（Log）日志段（Log Segment）消费者组（Consumer Group）消费者实例（Consumer Instance）“重平衡”（Rebalance）消费者位移（Consumer Offset） Kafka版本选择原则
Kafka基础定义 kafka是什么？消息队列？分布式消息中间件？
Kafka是“消息引擎系统”。
消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。
Kafka是“分布式流式处理平台”。
Kafka设计之初的三方面基本特性：
- 提供一套 API 实现生产者和消费者；降低网络传输和磁盘存储开销；实现高伸缩性架构。
削峰填谷：缓冲上下游瞬时突发流量，能够有效地对抗上游的流量冲击。
发送方和接收方松耦合：在一定程度上简化了应用的开发，减少了系统间不必要的交互。
Kafka传输消息的格式是纯二进制的字节序列。发送端在发送消息前，都要将消息序列化成二进制的字节序列；接收端在收到消息后，都要将二进制消息反序列化成消息数据。
Kafka的消息传输模型点对点模型：日常生活的例子比如电话客服就属于这种模型：同一个客户呼入电话只能被一位客服人员处理，第二个客服人员不能为该客户服务。
发布 / 订阅模型：它有一个主题（Topic）的概念，你可以理解成逻辑语义相近的消息容器。该模型也有发送方和接收方，只不过提法不同。发送方也称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布 / 订阅模型。
Java语言客户端：Kafka的Java 客户端；
C++语言客户端：libkafka。
客户端发布订阅的对象。可以为每个业务、每个应用甚至是每类数据都创建专属的主题。注意：主题不是队列名，更像是消息的分组，不完全具备队列特征。
客户端（Clients）生产者和消费者统称为客户端。
生产者（Producer）向主题发布消息的客户端应用程序。可以向一个或多个主题发送消息。
消费者（Consumer）订阅这些主题消息的客户端应用程序。可以同时订阅多个主题的消息。
服务器端（Broker）接收和处理客户端发送过来的请求，对消息进行持久化。
Kafka集群一个 Kafka 集群由多个Broker（Kafka服务器端）组成。
备份机制（Replication）——高可用方案思路：把相同的数据拷贝到多台分散运行的Broker节点上。
相同的数据拷贝在 Kafka 中被称为副本（Replica）。
Kafka 定义了“领导者副本”、“追随者副本”两类副本：
领导者副本（Leader Replica）：对外提供服务，与客户端程序进行交互；
追随者副本（Follower Replica）：被动地追随领导者副本，不能与外界进行交互。
备份工作机制：
- 生产者（Producer）总是向领导者副本写消息；消费者（Consumer）总是从领导者副本读消息；追随者副本向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。
思路：把数据分割成多份保存在不同的Broker上。
Kafka 中的分区机制指的是将每个主题划分成多个分区，每个分区是一组有序的消息日志。Kafka的设计中相同TOPIC下多个分区无法保证全局的消息顺序。如果一定要实现全局的消息顺序，只能让顺序敏感的消息存储在同一个分区。分区号从0开始。
通过分区回头看副本机制：
- 实际上，副本是在“分区”层面定义的；每个分区下可以配置若干个副本；其中只能有1个领导者副本和N-1个追随者副本。
每条消息在分区中的位置信息由一个叫位移的数据来表征。
分区位移总是从 0 开始，依次递增。
消息日志是Kafka Broker 的消息持久化机制；
Kafka使用消息日志来实际保存数据；
一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。这个机制，避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，是Kafka 高吞吐量特性的一个重要手段。
目标：解决大日志文件和日志淘汰的问题，辅助磁盘回收；
当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来；
Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。
目标：提升消费者端的吞吐量。
解决思路：通过多个消费者实例同时消费，加速整个消费端的吞吐量（TPS）。
多个消费者实例共同组成一个组来消费一组主题。
这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它。
消费者组里面的所有消费者实例“瓜分”订阅主题的数据。
“重平衡”（Rebalance）假设组内某个实例挂掉了，Kafka 能够自动检测到，然后把这个 Failed 实例之前负责的分区转移给其他活着的消费者。这个过程就是 Kafka 中大名鼎鼎的“重平衡”（Rebalance）。
⚠️ 容易出问题，“BUG之源”，单partition下没有这个问题。
消费者消费进度的指示器，每个消费者有自己的消费者位移。
Kafka版本选择原则- 原则上应选择Kafka 1.0.0 以上版本，消息通道能力相对稳定；想使用Kafka流平台能力的至少选择 2.0.0 版本。原因是：Kafka 1.0.0到Kafka 2.0.0版本在流平台能力层面的变更和非兼容性的升级；不要一味追求最新版本，不要成为最新版本的“小白鼠”。
相关内容：
Kafka学习笔记（二）Kafka操作实践
Kafka学习笔记（三）Kafka基础设施评估及服务器端配置
