Kafaka简介与系统架构

relication/Follower

数据单元

Consumer

Kafaka集群的每一个服务器都叫Broker

每一个分区都拥有副本保证数据的安全Partiton为了数据的读写Replication为了数据的备份，没有读取功能

Topic2

Topic3

1. producer 先从 zookeeper 的 \"/brokers/.../state\" 节点找到该 partition 的leader2. producer 将消息发送给该 leader3. leader 将消息写入本地 log4. followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后commit 的 offset） 并向 producer 发送 ACK

Prducer

支持离线和实时数据处理每秒能达到100k条消息传输Kafka是无序的只有一个partition内顺序读写

消费者就是从Topic读取数据消费者组一组共享一个Topic的偏移量一个消费者组内包含一个或者多个消费者不同的组可以同时消费相同的Topic

Partiton/Leader

ZooKeePer

存储KafaKa的元数据信息帮助进行Leader的选举

生产者，将产生的消息存放到对应的Topic消息根据分区规则存放到不同的Partiton，然后同步到Replication

主题中的数据会被切分为至少一个或多个Partiton类似于Hbase的Region每个分区中数据都是有序的（插入顺序），新增的数据都会分配到队列尾部

可以唯一的标识一条消息一个消息只能被一个组消费一次一个组记录当前Topic消息消费的进度特殊情况下消费者组可以适当调整offset的位置侧面也证明消费的数据不会被立马删除

Consumer Group

架构

KafaKa

Offset

Broker

生产者发送的消息类别称为主题创建流程先创建主题  然后选择Partition和Relication

Consumer Group

高吞吐量的分布式消息订阅系统 可以处理消费者流数据解耦：让生产者与消费者不在有依赖关系 生产者和消费者不用管对方是谁 只需要关注消息在哪里拿可恢复性:即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理缓冲：解决生产消息和消费消息的处理速度不一致灵活性&峰值处理能力：使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃异步通信：消息放在消息队列中 不用立即处理它