kafka原理分析

kafka的产生（为什么会有kafka的诞生）

一般的网站开发是MVC分层开发，从网页前段获取信息，通过中间层控制，再到业务层。一般来说正常的数据传输是可以完成一定任务的，但是存在一些情况，并且随着时代的发展这种情况也会越来越多的地方出现，例如：淘宝的双11以及京东的618购物节，在平常，可能每日订单量保持在平稳的状态，但是到了摸个特定的点，就会出现，一下子从前端传入后端数据量猛增，这是直接写入的话会造成后端服务器的崩溃。为了解决这样类似的问题，就会有消息队列的出现，而kafka正是消息队列的一种，也是目前市面上用的最多的一种。

目前有的消息队列

ActiveMQ、RabbitMQ、RocketMQ、Kafka、Redis

为什么消息队列就可以解决大量传入消息造成服务器崩溃的问题

异步调用

消息队列，就是消息传输的中间件，他可以把短时间内大量传输到服务器的消息，暂时存在消息队列中，然后服务器在慢慢去消息队列中读取消息，这样就不会造成大量数据一起读入而导致的服务器崩掉。实现了原本同步的操作，变成了异步。
例：消息队列正如在家吃饭，消息的产生着是做饭的人，产生的消息是饭，大量的饭菜一下子全部烧好，然后吃，吃不掉冰箱就会把存起来，等待下一次继续吃。冰箱就是一个消息队列。

应用解耦/可扩展性

提供基于数据的接口层

流量削峰

流量晓峰就是说如果一个订单平台，如果像往常一样正常运行可能是不需要使用消息队列，但是一旦到了某个峰值，就会触发消息队列进行工作，把超出服务器负载的消息存入消息队列进行等待。

可恢复性

消息队列中存入的消息，短时间内是不会消失的。一般来说kafka是可以保存168个小时，也就是7天。在这期间内，如果说消费者（也就是消息调用者）如果拿走的消息运行出现异常，丢失了消息，那么还可以从消息队列中再次获取消息

顺序保障

kafka存入消息是有序的，就是按传入先后顺序进行存取。

消息中间件工作模式

点对点模式：一对一，消费者主动拉取数据

发布订阅模式

一对多，数据生产后，推送给所有订阅者

消息中间件中的术语

• Broker：消息服务器，提供核心服务
• Producer：消息生产者
• Consumer：消息消费者
• Topic：主题，发布订阅模式下的消息统一汇集地
• Queue：队列，点对点模式下的消息队列

Apache Kafka

• Kafka是一种高吞吐量的分布式发布-订阅 消息系统，专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计

1. 快速，单Broker每秒几百MB读取
2. 不停机扩展集群
3. 消息副本冗余
4. 实时数据管道
5. 使用Scala编写

Kafka架构

• Broker：Kafka集群中的服务器
• Topic：维护一个主题中的消息，可视为消息分类
• Producer：向Kafka主题发布（生产）消息
• Consumer：订阅（消费）主题并处理消息
  

Kafka Topic

• 主题是已发布消息的类别名称
• 发布和订阅数据必须指定主题
• 主题副本数量不大于Brokers个数
• Partition（只能保证分区内有序）如果要全局有序就需要只有一个分区
• 一个主题包含多个分区，默认按Key Hash分区
• 每个Partition对应一个文件夹<topic_name>-<partition_id>
• 每个Partition被视为一个有序的日志文件（LogSegment）
• Replication策略是基于Partition,而不是Topic
• 每个Partition都有一个Leader，0或多个Followers
  

Kafka Message

header：消息头，固定长度

• offset：唯一确定每条消息在分区内的位置
• CRC32：用crc32校验消息
• “magic”：表示本次发布Kafka服务程序协议版本号
• “attributes”：表示为独立版本、或标识压缩类型、或编码类型

body：消息体

• key：表示消息键，可选
• value bytes payload：表示实际消息数据

Kafka Producer

生产者将消息写入到Broker

• Producer直接发送消息到Broker上的Leader Partition
• Producer客户端自己控制着消息被推送到哪些Partition
  • 指定key通过hash、未指定送轮询、自定义分区算法等
• Batch推送提高效率

Kafka Broker

• Kafka集群中每个Broker都可以响应Producer的请求
• 每个Broker充当Leader和Followers保持负载平衡
  • Leader处理所有读写请求
  • Followers被动复制Leader

Kafka Consumer

消费者通过订阅消费消息

• offset的管理是基于消费组（group.id）的级别
• 每个Partition只能由同一消费组内的一个Consumer来消费
• 每个Consumer可以消费多个分区
• 消费过的数据仍会保留在Kafka中
• 消费者数量一般不超过分区数量

消费模式

• 队列： 所有消费者在一个消费组内
• 发布/订阅： 所有消费者被分配到不同的消费组

kafka之consumer参数auto.offset.reset

auto.offset.reset： 可理解为kafka consumer读取数据的策略
earliest|latest|none。

earliest： 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费
latest： 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据
none： topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常

Kafka数据流

副本同步

• ISR（In-Sync Replica）

容灾

• Leader Partition

高并发

读写性能

• Consumer Group

负载均衡

kafka应答机制

kafka应答机制就是消息生产者产生数据，向Leader传输时会带有应答机制，不同的应答机制，产生的效果也是不同的。（acks）

• acks = 1 响应一次，当消息生产者Producer向leader发送数据，leader收到数据后会直接向producer发送消息告诉producer已经接受到消息。
• acks = all（-1）：当然也是响应一次。但是他会等所有的followers都将leader接收到的数据复制完成后才会想producer发送消息，表示消息已接收。中间如果出意外，如果leader节点宕机了，那么会选择效率高的接收量大的节点作为新的leader继续传输数据，这时可能其他各个节点的数据不是统一的，没关系新上任的leader会要求其他节点全部与自己当前接收到的数据相同，然后继续接受。
• acks = 0 最方便省事的一种，当然也是最不安全的一种，可能会造成数据丢失，当然真的发生宕机的可能性也是比较小的。

ZooKeeper在Kafka中的作用

Broker注册并监控状态

• /brokers/ids

Topic注册

• /brokers/topics

生产者负载均衡

• 四层负载均衡，根据生产者的 IP 地址和端口来为其确定一个相关联的 Broker。通常，一个生产者只会对应单个 Broker，然后该生产者产生的消息都发往该 Broker。这种方式逻辑简单，每个生产者不需要同其他系统建立额外的TCP 连接，只需要和 Broker 维护单个 TCP 连接即可。但是，其无法做到真正的负载均衡，因为实际系统中的每个生产者产生的消息量及每个 Broker 的消息存储量都是不一样的，如果有些生产者产生的消息远多于其他生产者的话，那么会导致不同的 Broker 接收到的消息总数差异巨大，同时，生产者也无法实时感知到 Broker 的新增和删除。
• 使用 Zookeeper 进行负载均衡，由于每个 Broker 启动时，都会完成Broker 注册过程，生产者会通过该节点的变化来动态地感知到 Broker 服务器列表的变更，这样就可以实现动态的负载均衡机制。

offset维护

• Kafka 早期版本使用 ZooKeeper 为每个消费者存储 offset，由于 ZooKeeper
  写入性能较差，从 0.10 版本后，Kafka 使用自己的内部主题维护 offset。
• 另外 ，早期版本的 kafka 用 ZooKeeper 做 meta 信息存储、Consumer 的消
  费状态、group 的管理以及 offset 的值。考虑到 ZooKeeper 本身的一些因素以及
  整个架构较大概率存在单点问题，0.9 版本之后，逐渐弱化了 ZooKeeper 的作用。
  新的 Consumer 使用了 Kafka 内部的 Group Coordination 协议，也减少了对
  ZooKeeper 的依赖。

kafka如何实现高吞吐（重点）

顺序读写

Kafka 的消息是不断追加到文件中的，这个特性使 Kafka 可以充分利用磁盘的顺序读写性能。
顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写。

零拷贝

在 Linux kernel2.2 之后出现了一种叫做"零拷贝(zero-copy)"系统调用机制，就是跳过“用户
缓冲区”的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”。
零拷贝并不是不需要拷贝，而是减少不必要的拷贝次数。通常是说在 IO 读写过程中。“零
拷贝技术”只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送
到网络中。

分区

Kafka 的队列 topic 被分为了多个区 partition，每个 partition 又分为多个段 segment，所以一
个队列中的消息实际上是保存在 N 多个片段文件中通过分段的方式，每次文件操作都是对
一个小文件的操作，非常轻便，同时也增加了并行处理能力。

批量发送

Kafka 允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去比如可
以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去如 100
条消息就发送，或者每 5 秒发送一次这种策略将大大减少服务端的 I/O 次数。

数据压缩

Kafka 还支持对消息集合进行压缩，Producer 可以通过 GZIP 或 Snappy 格式对消息集合进行
压缩压缩的好处就是减少传输的数据量，减轻对网络传输的压力。

Consumer 的负载均衡

当一个 group 中,有 consumer 加入或者离开时,会触发 partitions 均衡.均衡的最终目的,是提升
topic 的并发消费能力。