Kakfa简介
Apache Kafka 是一款开源的消息引擎系统。
试问一条消息如何做到信息表达业务语义而无歧义，同时它还要能最大限度地提供可重用性以及通用性？一个比较容易想到的是使用已有的一些成熟解决方案，比如使用 CSV、XML 亦或是 JSON；又或者你可能熟知国外大厂开源的一些序列化框架，比如 Google 的 Protocol Buffer 或 Facebook 的 Thrift。这些都是很酷的办法。那么现在我告诉你 Kafka 的选择：它使用的是纯二进制的字节序列。当然消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。
消息引擎系统还要设定具体的传输协议，即我用什么方法把消息传输出去。常见的有两种方法：点对点模型：也叫消息队列模型。如果拿上面那个“民间版”的定义来说，那么系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取 A 发送的消息。日常生活的例子比如电话客服就属于这种模型：同一个客户呼入电话只能被一位客服人员处理，第二个客服人员不能为该客户服务。发布 / 订阅模型：与上面不同的是，它有一个主题（Topic）的概念，你可以理解成逻辑语义相近的消息容器。该模型也有发送方和接收方，只不过提法不同。发送方也称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布 / 订阅模型。比较酷的是 Kafka 同时支持这两种消息引擎模型，专栏后面我会分享 Kafka 是如何做到这一点的。
为什么系统 A 不能直接发送消息给系统 B，中间还要隔一个消息引擎呢？答案就是“削峰填谷”。这四个字简直比消息引擎本身还要有名气。
术语
在 Kafka 中，发布订阅的对象是主题（Topic），你可以为每个业务、每个应用甚至是每类数据都创建专属的主题。向主题发布消息的客户端应用程序称为生产者（Producer），生产者程序通常持续不断地向一个或多个主题发送消息，而订阅这些主题消息的客户端应用程序就被称为消费者（Consumer）。和生产者类似，消费者也能够同时订阅多个主题的消息。我们把生产者和消费者统称为客户端（Clients）。你可以同时运行多个生产者和消费者实例，这些实例会不断地向 Kafka 集群中的多个主题生产和消费消息。有客户端自然也就有服务器端。Kafka 的服务器端由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上，这样如果集群中某一台机器宕机，即使在它上面运行的所有 Broker 进程都挂掉了，其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一。
副本的工作机制也很简单：生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息。至于追随者副本，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。
这里再重点说说消费者。在专栏的第一期中我提到过两种消息模型，即点对点模型（Peer to Peer，P2P）和发布订阅模型。这里面的点对点指的是同一条消息只能被下游的一个消费者消费，其他消费者则不能染指。在 Kafka 中实现这种 P2P 模型的方法就是引入了消费者组（Consumer Group）。所谓的消费者组，指的是多个消费者实例共同组成一个组来消费一组主题。这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它。为什么要引入消费者组呢？主要是为了提升消费者端的吞吐量。多个消费者实例同时消费，加速整个消费端的吞吐量（TPS）。我会在专栏的后面详细介绍消费者组机制，所以现在你只需要了解消费者组是做什么的即可。另外这里的消费者实例可以是运行消费者应用的进程，也可以是一个线程，它们都称为一个消费者实例（Consumer Instance）。
每个消费者在消费消息的过程中必然需要有个字段记录它当前消费到了分区的哪个位置上，这个字段就是消费者位移（Consumer Offset）。注意，这和上面所说的位移完全不是一个概念。上面的“位移”表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就是固定的了。而消费者位移则不同，它可能是随时变化的，毕竟它是消费者消费进度的指示器嘛。另外每个消费者有着自己的消费者位移，因此一定要区分这两类位移的区别。我个人把消息在分区中的位移称为分区位移，而把消费者端的位移称为消费者位移。
kafka基本使用
线上集群部署方案
操作系统：I/O 模型与 Kafka 的关系又是什么呢？实际上 Kafka 客户端底层使用了 Java 的 selector，selector 在 Linux 上的实现机制是 epoll，而在 Windows 平台上的实现机制是 select。因此在这一点上将 Kafka 部署在 Linux 上是有优势的，因为能够获得更高效的 I/O 性能。
在 Linux 部署 Kafka 能够享受到零拷贝技术所带来的快速数据传输特性。零拷贝（Zero Copy）技术，就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速的数据传输。
追求性价比的公司可以不搭建 RAID，使用普通磁盘组成存储空间即可。使用机械磁盘完全能够胜任 Kafka 线上环境。
kafka 架构
09 | 生产者消息分区机制原理剖析
10 | 生产者压缩算法面面观
11 | 无消息丢失配置怎么实现？
12 | 客户端都有哪些不常见但是很高级的功能？
13 | Java生产者是如何管理TCP连接的？
14 | 幂等生产者和事务生产者是一回事吗？
15 | 消费者组到底是什么？
16 | 揭开神秘的“位移主题”面纱
17 | 消费者组重平衡能避免吗？
18 | Kafka中位移提交那些事儿
19 | CommitFailedException异常怎么处理？
20 | 多线程开发消费者实例
21 | Java 消费者是如何管理TCP连接的?
22 | 消费者组消费进度监控都怎么实现？
23 | Kafka副本机制详解
24 | 请求是怎么被处理的？
25 | 消费者组重平衡全流程解析
26 | 你一定不能错过的Kafka控制器
27 | 关于高水位和Leader Epoch的讨论
通过 Leader Epoch 机制，Kafka 完美地规避了这种数据丢失场景。
kafka 重点内容
- 常见的一致性保障有三类：至多一次（At most once）语义：消息或事件对应用状态的影响最多只有一次。至少一次（At least once）语义：消息或事件对应用状态的影响最少一次。精确一次（Exactly once）语义：消息或事件对应用状态的影响有且只有一次。
kafka实战
简单入门：https://www.cnblogs.com/javabg/p/9592193.html
建议
胡夕老师建议
- 持续精进自己的 Java 功底。比如，你可以去 Java 官网上，把 Java 语言规范和 JVM 规范熟读一遍。很多人都不太重视语言规范文档，但实际上，Java 中关于线程和同步的知识，在 Java 语言规范中都有相关的阐释。
- 提升自己的 Java 多线程开发以及 I/O 开发能力。很多大数据框架底层都大量使用 Java 多线程能力以及 NIO 帮助实现自身功能。就拿 Kafka 来说，多线程自不必说，Kafka 可是大量使用 NIO 实现网络通信的。所以，这部分的知识是你必须要熟练掌握的。
- 掌握 JVM 调优和 GC。我推荐你去读一读“Java Performance”这本书。虽然目前 GC 收集器大部分演进到了 G1 时代，但书中大部分的调优内容依然是适用的。调优 Kafka 的 JVM，也要依赖这部分知识给予我们指导。
学者的建议
- 在学习过程中，追求大而全并不好，我们只需要掌握实际生产环境中最常用的那么十几个参数，保障消息传输稳定、快速、不丢失就可以了。很多很深奥的内容，如果精力和时间允许的话，再去深究，要以终为始，不能钻牛角尖。