一、消息引擎系统
Apache Kafka 是一款开源的消息引擎系统
1. 作用
维基百科定义消息引擎系统是一组规范。
- 消息引擎传输的对象是消息
- 如何传输消息属于消息引擎设计的一部分
kafka 消息的编码格式为：二进制的字节序列
2. 传输方法
- 点对点模型：系统 A 发送的消息只能被系统 B 接受，其他任何系统都不能读取 A 发送的消息
- 发布订阅模型：有一个主题（Topic）的概念，该模型有发送方和接收方。发送方被称为发布者，接收方被称为订阅者。和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个
为什么我们的系统 A 不能直接把消息发送给系统 B？
削峰填谷：缓冲上下游瞬间突发流量，使其更加的平滑。
对于发送能力比较强的上游系统，如果没有消息引擎的保护，脆弱的下游系统可能会直接被压垮，导致整个链路服务“雪崩”。
解耦：发送方和接收方松耦合，减少了系统间不必要的交互
二、Kafka术语
1. 常见术语
主题（Topic）：发布订阅的对象，可以为每一个业务、每个应用甚至每类数据都创建专属的主题。
客户端（Clients）
- 生产者（Producer）：生产者不断的向一个主题或多个主题发送消息。
- 消费者（Consumer）：消费者也能够订阅多个主题的消息。
服务端：
- Broker：一个 kafka 集群由多个 Broker 构成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。将其分散运行在不同的机器，防止机器宕机，导致服务不可用。
Replication：将相同的数据拷贝到多台机器上，这些相同的数据被称为副本。副本分为 Leader 副本和 Follower 副本，Leader 副本可以进行读写操作，Follower 副本不进行读写操作，只对 Leader 副本发送请求，
- 同步数据。
- Partition：将每个主题分为多个分区。
- offset：生产者和消费者的消息位移记录。
副本和分区的关系：
- 每个分区下可以配置若 N 个副本，只能有一个 Leader 副本和 N-1 个 Follower 副本
2. Kafka 的三层消息架构
- 第一层是主题层，每个主题可以配置 M 个分区
- 第二层是分区层，每个分区的N个副本只能有一个充当领导者，对外提供服务；其余 N - 1 个副本是追随者副本，提供数据同步。
- 第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始。
- 客户端程序只能和分区的领导者副本进行交互
3. kakfa Broker 持久化数据
kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。
因为只能追加写入，避免了随机IO操作，改为性能较好的顺序I/O写操作，这也是实现 Kafka 高吞吐特性的一个重要手段。
kafka 会定期的删除消息以回收磁盘，通过 日志段（Log Segment）机制。一个日志被细分成多个日志段，消息写入到最新的日志段中，写满之后会自动分出一个新的日志段。
4. 消费组
多个消费者实例共同组成一个组来消费一组主题，多个消费者同时消费一组主题，提升消费端的吞吐量。
因为我们的消费者组每个消费者会自动分配相应的分区数量，当某个消费者挂掉之后，我们的 Kafka 会自动将这个实例负责的分区转移给其他的消费者。这个操作被称为：重平衡（Rebalance）
三、Kafka只是消息引擎系统吗
kafka 是消息引擎系统，也是一个分布式流处理平台（Distributed Streaming Platform）
kafka 名字的来源
因为 kafka 系统的写性能比较高，所以找了个作家的名字来命名似乎是一个好主意。大学期间上了很多的文学课，非常喜欢 Franz Kafka 这个作家。
kafka 在设计之初提供三方面的特性
- 提供一套 API 实现生产者消费者
- 降低网络传输和磁盘存储开销
- 实现高伸缩性架构
Kafka 作为流处理平台的话，与其他大数据流式计算框架相比，优势在哪呢？
端到端的正确性：Tyler 大神曾经说过，流处理最终替代它的兄弟批处理需要具体两点核心优势：要实现正确性和提供能够推导时间的工具。实现正确性是流处理能够匹敌批处理的基石。我们的 Spark 或 Flink 从 Kafka 读取消息进行有状态的数据计算，最终再写回 Kafka，你只能保证在 Spark 或 Flink 内部，这条消息对于状态的影响只有一次。但是计算结果可能多次写入 Kafka，因为他们不能控制 Kafka 的语义处理。
- 相反，如果我们所有的数据流转和计算都在 Kafka 内部完成，就可以实现端到端的精确一次处理语义。
- 对于流式计算的定位：官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。意味着我们的 Kafka 没有办法实现集群调度、开箱即用，需要自己选择合适的工具帮助 Kafka 实现这些功能。有些小企业不需要搭建重量级的平台，就可以直接使用 Kafka 来应对。这也是 Kafka 不正面硬钢其他流计算框架的一个方法。
四、kafka 的种类
我们知道，Linux 有不同的种类，如：CentOS、RedHat、Ubuntu等，他们都是 Linux 系统，因为不同的公司发布的 Linux 系统不同，继而被称为不同的名字。
kafka 也是一样，有不同的种类：
- Apache Kafka：最正宗的 Kafka
- Confluent Kafka：商业化 Kafka 工具开发
- Cloudera/Hortonworks Kafka：集成了目前主流的大数据框架，能够帮助用户实现从分布式存储、集群调度、流处理到机器学习、实时数据库等全方位的数据处理。
特点比较
- 1.Apache Kafka：开发人数最多、版本迭代最快的 Kafka。他缺失了一些监控框架或工具，我们可以使用第三方的框架来进行弥补。如果你仅仅需要一个消息引擎系统亦或是简单的流处理应用场景，同时需要对系统有较大把控度，那么我推荐你使用 Apache Kafka。
- 2.Confluent Kafka：含有跨数据中心备份和集群监控。如果你需要用到 Kafka 的一些高级特性，那么推荐你使用 Confluent Kafka。
- 3.CDH/HDP Kafka：大数据云公司提供的 Kafka，内嵌 Apache Kafka。优势在于操作简单，节省运维成本；缺陷在于把控度低，演进速度较慢。
五、Kafka 的版本号
我们去官网可以发现，Kafka 的版本号表现形式为：2.1.1
前面的 2 表示大版本号，中间的 1 表示小版本号，最后的 1 表示修订版本号。
kafka 的版本演进
- 0.7版本：提供最基础的消息队列功能
- 0.8版本：引入副本机制，Kafka 真正意义上成为了分布式高可靠的消息队列解决方案。
- 0.9版本：增加了基础的安全认证/权限功能
- 0.10版本：引入 Kafka Streams。从这个版本起，Kafka 正式升级成分布式流处理平台。
- 0.11版本：提供幂等性和事务
- 1.0和2.0版本：kafka Steams 的各种改进。
