0 知识体系
客户端
Producer
Consumer
4、Consumer offset 提交及 partition 分配
服务端
GroupCoordinator
LogManager
1、日志管理
4、副本同步机制
ReplicaManager
Controller
1 Kafka作用
Kafka是一个分布式的基于发布/订阅的消息系统，有着强大的消息处理能力，相比与其他消息系统相比，具有以下特性：
-
快速数据持久化，实现了O(1)时间复杂度的数据持久化能力。
-
高吞吐，能在普通的服务器上达到10W每秒的吞吐速率。
-
高可靠，消息持久化以及副本系统的机制保证了消息的可靠性，消息可以多次消费。
-
高扩展，与其他分布式系统一样，所有组件均支持分布式、自动实现负载均衡，可以快速便捷的扩容系统。
-
离线与实时处理能力并存，提供了在线与离线的消息处理能力。
正是因其具有这些的优秀特性而广泛用于应用解耦、异步消息、流量削峰等场景，比如消息中间件、日志聚合、流处理等等。
1.1 应用解耦
场景：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据？如果 C 系统现在不需要了呢？那这样 A 系统负责人几乎会崩溃…
在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！
如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。
画外音：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。
1.2 异步消息
场景：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。
一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。
如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了！
1.3 流量削峰
每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。
一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。
2 kafka整体架构
2.1 核心概念
Kafka中有一些重要的概念，后面会详细解析每个概念的作用及深入原理：
-
Producer： 消息生产者，向 Kafka Broker 发消息的客户端。
-
Consumer：消息消费者，从 Kafka Broker 取消息的客户端。
-
Consumer Group：消费者组（CG），消费者组内每个消费者负责消费不同分区的数据，提高消费能力。一个分区只能由组内一个消费者消费，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
-
Broker：一台 Kafka 机器就是一个 Broker。一个集群由多个 Broker 组成。一个 Broker 可以容纳多个 Topic。
-
Topic：可以理解为一个队列，Topic 将消息分类，生产者和消费者面向的是同一个 Topic。
-
Partition：为了实现扩展性，提高并发能力，一个非常大的 Topic 可以分布到多个 Broker （即服务器）上，一个 Topic 可以分为多个 Partition，每个 Partition 是一个 有序的队列。
-
Replica：副本，为实现备份的功能，保证集群中的某个节点发生故障时，该节点上的 Partition 数据不丢失，且 Kafka 仍然能够继续工作，Kafka 提供了副本机制，一个 Topic 的每个分区都有若干个副本，一个 Leader 和若干个 Follower。
-
Leader：每个分区多个副本的“主”副本，生产者发送数据的对象，以及消费者消费数据的对象，都是 Leader。
-
Follower：每个分区多个副本的“从”副本，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 还会成为新的 Leader。
-
Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。
-
Zookeeper：Kafka 集群能够正常工作，需要依赖于 Zookeeper，Zookeeper 帮助 Kafka 存储和管理集群信息。
2.2 工作流程
kafka的总体数据流如下：
kafka对外使用topic的概念，生产者往topic里写消息，消费者从topic中读消息。为了做到水平扩展，一个topic实际是由多个partition组成的，遇到瓶颈时，可通过增加partition的数量来进行横向扩容，单个parition内是保证消息有序。每新写一条消息，kafka就是在对应的文件append写，所以性能非常高。broker、topics、partitions的一些元信息用zk来存，监控和路由也都会用到zk。图中有两个topic：topic 0有两个partition，topic 1有一个partition，三副本备份。可以看到consumer gourp 1中的consumer 2没有分到partition处理，这是有可能出现的。
3 Kaka高性能探究
3.1 顺序写入
3.2 内存页
3.3 零拷贝
详细参考：Kafka为什么这么快
204
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
