根据原文摘录整理
http://m.sohu.com/a/274685501_355140



2011年捐献给 Apache 基金会

2018.07 发布 2.0版本
Kafka 已经不只是分布式消息队列，而是集成了分发、存储和计算的流式数据平台

2018年9月 InfoWorld 最佳开源数据库与数据分析平台奖中，
大数据新秀 Pulsar 首次获奖，在获奖点评中明确提到 Pulsar 旨在取代 Apache Kafka 多年的主宰地位

诞生于 2010 年  LinkedIn 
数据日志收集，需要一个集中式的数据通道，避免点对点的数据传输
MQ的缺点 
消费者挂了，无法及时消费消息时，数据丢失
可扩展性差，无法很好的应对峰谷

简单的设计理念
以 append-only 日志作为核心的数据存储结构
把数据以日志的方式进行组织，所有对于日志的写操作，都提交在日志的最末端，对日志只能顺序读取。

HDD慢，使用顺序读写 
文件系统缓存利用

可扩展性设计 

按topic组织数据   再分区分片 Partition，存储在不同的节点上 
数据的发布和订阅基于 Topic
消费者拉取数据
增加 Partition 和 节点，就可以方便的扩容

0.7 版本，进入 Apache 孵化器
第一个开源的版本 0.7.0  ，最主要的两个特征 压缩和 MirrorMaker，跨集群之间的数据拷贝

按纯字节组织数据
偏移量基于字节
当一个发布者客户端积攒了很多数据，要一次性发布的时候，
所有这些数据会被打包成为一个大的 Wrapper message，它可能会包含很多真正的 Message。

Wrapper message 其实会存储的所有这些 Message 是加在一起的总的数据偏移量

用物理的字节作为偏移量的一个弊端
数据的消费端提交这个偏移量的时候，它就只能提交在这些大的、压缩过的 Wrapper message 的边界上。
消费一个大的 Message 的时候，这个 Message 里面有一百条数据，只有把这一百条数据全部都消费完以后，才能提交准确的偏移量。
偏移量是压缩过后的偏移量，中途停止或者失败的话，无法提交一个中间的偏移量。

2012 年  成为 Apache 顶级项目 ，发布了 0.8.0 高可用性

replication  partition  replica
replica 放置，基本上是一个简单的轮询。
Topic1 的第一个 Partition 被分配到 123，第二个 Partition 被分配到 231 等

有一个 Partition 会成为 Leader，Leader 进行所有读写请求的操作。
客户端客户端读写信息的时候，都是和这个 leader 交互，Leader 负责数据再备份到其他的 replica 上

备份、管理数据的协议

基于简单的协议做数据备份，而备份之间的管理要基于复杂的协议。

ISR 实时备份列表    In-Sync Replicas
所有的备份分为已同步和未同步的备份
已同步的备份指，Leader 所有的 Data 在 replica 里面都有；
未同步的备份，由于可能比较慢，或者备份还不完整，也许有些数据在 Leader 上有，但是在 replica 上没有。

0.8 中通过一个控制器来做到备份的灵活处理

控制器的作用
通过 Zookeeper 来监测每一个服务器是否正常运行
Leader选举
把这个 Leader 上新的数据发布到所有 broker 上

如果所有的服务器都跟 Zookeeper 交互的话， zk压力会很大
控制器起到一个在 Zookeeper 跟其他服务器之间协同的角色

只有控制器需要跟 Zookeeper 之间进行大量的交互，
当它得到了一些新的元数据的更新以后，再把这些数据发布到其他的 broker 上。


流数据传输的集中式通道
centtralized data pipeline 

0.8 版本 更新了消息的数据结构，把数据偏移量改成了按逻辑的，每条信息的数据偏移量就是 1，不管消息有多大。
压缩和解压缩时，需要知道压缩过后的数据里包含了多少小数据，可以通过增加偏移量来增加大数据的偏移量。

一个大的数据，压缩包里面包含了三个小数据，它们本身的偏移量是 012，那么包压缩的偏移量就是 2，也就是最后那个数据所对应的逻辑偏移量。
当下一个消息被发布的时候，再根据已有的偏移量和压缩的数据重新计算偏移量。
要花一些 CPU 来做解压缩、重新压缩、偏移量的计算，

2014 年  布了 0.8.2 和 0.9.0
0.9.0  加入了两个非常重要的特性，配额和安全性。

集群变大、使用场景增多 ，
多租户之间的影响就会非常显著，一个人可以影响其他所有用户

限定每一个 user 能够用多大的流量跟 Kafka 交互
超过配额，Kafka broker 会延迟请求，使一个 User 不会影响其他人。

授权、认证、加密

谁能干什么，这个谁就是认证，能干什么就是授权

认证是一个一次性的过程，当一个新的客户端，第一次和服务器端建立连接的时候，会通过 SSL 进行一次认证。
但是授权，读、写、修改或者管理操作的时候，每一次都需要做授权检查。

高性能要点
日志文件顺序读写 
利用文件系统缓存
使用Java 7 新加入的零拷贝机制，原来将数据从磁盘写入网卡需要经过四次拷贝，有了零拷贝机制能够省去其中从用户端到内核端的数据拷贝过程。
  
基于消息 Key 的清理

0.8 版本以前，Kafka 仅以时间或者数据大小来清理，可以配置为数据存四天，过期一天的数据就自动清理掉。

 CPU 上要做压缩、解压缩、加密、解密、备份间的协调等操作，所以对 CPU 的消耗逐渐加大了，但网络带宽一直不变。
 
0.10 版本，更细粒度的时间戳

0.9 版本或者更老的版本里面
对于时间的概念是非常粗粒度的，每一个分片是一个文件，所有 record 仅以这个文件的时间作为基准
当需要依据时间进行回溯时，无法得到非常确切的偏移量。

0.10 版本里，每一个 record 会有一个具体的时间戳
可以基于偏移量进行快速的数据查找，找到所要的时间戳。
更细粒度的 log rolling/log retention

客户端加时间戳 或者 broker加时间戳
append time 一定是顺序的，create time 乱序

Kafka Streams   流处理库
Event-at-a-time Stateful Windowing  Highly scalable  distributed  fault tolerant
从 Topic 里实时地抓取数据，这个数据通过用户所写拓扑结构，把所有的 record 实时进行 transform 之后，最终再写回到 Kafka 里面

Kafka Connect

1.0 Exactly-Once  
非 Exactly-Once 是指由于网络延迟或其他各种原因，导致消息重复发送甚至重复处理。
在 0.11 以及之前的版本 Exactly-Once 实现方式 
At-Least-Once 加上去重，把处理过的 record 记录下来，发现重复处理时就把它扔掉
 
0.11 Exactly-Once实现
发送 幂等性  broker 端自动去重
Transactions 当在一个事务下发布多条信息到多个 topic partition 时，可以使它以原子性的方式被完成
以 Kafka Streams 为例，只要配置一个 config，就可以使 processing 从 At-Least-Once 变成 Exactly-Once。


1.1 版本 运维性提升

Controller shut down

关闭一个 broker 的时候，需要一个很长很复杂的过程，
需要通知所有 broker，完成所有相关操作，并完成相关记录，才能完成整个 shut down 的过程。

在这个过程中，需要发送很多次请求，对元数据进行多次修改，这对于延迟性有很多的要求，使这个过程变得很缓慢

1.0 版本，五个 broker node 的集群，要进行一次 Controller shutdown，
10k partition per brocker 的规模，需要 6 分钟的时间，
而1.1 版本只需要 3 秒钟， Controller failover 的延迟也从 28 秒降到 14 秒。

未来愿景

多数据中心的原生支持
目前 Kafka 的用户都是配置存储 4 到 7 天或者最多一个月的数据，但越来越多的用户想在 Kafka 存储过去更久的流数据，
但是同时不会因为长时效的数据流而导致数据拷贝或者迁移的时候造成大量延迟。这同时也意味着 Kafka 需要有更好的云架构兼容性。

经验教训
0.8 版本里面改了数据格式，但是并没有一个非常好的升级补丁。
性能指标监控

每一个发布的 record，是否最终通过了所有的 Kafka 集群，通过了所有的 Tier，
最终到了消费端，并且到每个 Tier 的时候耗费了多少时间，只有对 Kafka 进行全方位的观测和监测，
才能知道哪里出现了问题，需要在哪里进行优化，需要在哪里进行改进。