Kafka架构
它的架构包括以下组件：
话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。
生产者（Producer）：是能够发布消息到话题的任何对象。
服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。
消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。
Kafka存储策略
1） kafka以topic来进行消息管理，每个topic包含多个partition，每个partition对应一个逻辑log，有多个segment组成。
2）每个segment中存储多条消息，消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。
3）每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。
4）发布者发到某个topic的消息会被均匀的分布到多个partition上（或根据用户指定的路由规则进行分布），broker收到发布消息往对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。(因为每条消息都被append到该partition中，是顺序写磁盘，因此效率非常高)
Kafka数据保留策略
1）N天前的删除。
2）保留最近的多少Size数据。
Kafka broker(服务代理)
Kafka broker是无状态的。这意味着消费者必须维护已消费的状态信息。这些信息由消费者自己维护，导致了从代理删除消息变得很棘手，因为代理并不知道消费者是否已经使用了该消息。
Kafka创新性地解决了这个问题，它将一个简单的基于时间的SLA应用于保留策略。当消息在代理中超过一定时间后，将会被自动删除。这种创新设计有很大的好处，消费者可以故意倒回到老的偏移量再次消费数据。这违反了队列的常见约定，但被证明是许多消费者的基本特征。
复制（Replication）
1）一个partition的复制个数（replication factor）包括这个partition的leader本身。
2）所有对partition的读和写都通过leader。
3）Followers通过pull获取leader上log（message和offset）
4）如果一个follower挂掉、卡住或者同步太慢，leader会把这个follower从”in sync replicas“（ISR）列表中删除。
5）当所有的”in sync replicas“的follower把一个消息写入到自己的log中时，这个消息才被认为是”committed“的。
6）如果针对某个partition的所有复制节点都挂了，Kafka默认选择最先复活的那个节点作为leader（这个节点不一定在ISR里）。
Leader选举
Kafka在Zookeeper中为每一个partition动态的维护了一个ISR，这个ISR里的所有replica都跟上了leader，只有ISR里的成员才能有被选为leader的可能（unclean.leader.election.enable=false）。
在这种模式下，对于f+1个副本，一个Kafka topic能在保证不丢失已经commit消息的前提下容忍f个副本的失败。
The Producer(生产者)
发送确认
通过request.required.acks来设置，选择是否等待消息commit（是否等待所有的”in sync replicas“都成功复制了数据）
Producer可以通过acks参数指定最少需要多少个Replica确认收到该消息才视为该消息发送成功。acks的默认值是1，即Leader收到该消息后立即告诉Producer收到该消息，此时如果在ISR中的消息复制完该消息前Leader宕机，那该条消息会丢失。
ps: 推荐的做法是将acks设置为all或者-1，只有ISR中的所有Replica都收到该数据（也即该消息被Commit），Leader才会告诉Producer该消息发送成功，保证不会有数据丢失。
负载均衡
1）producer可以自定义发送到哪个partition的路由规则。默认路由规则：hash(key)%numPartitions，如果key为null则随机选择一个partition。
2）自定义路由：如果key是一个user id，可以把同一个user的消息发送到同一个partition，这时consumer就可以从同一个partition读取同一个user的消息。
异步批量发送
批量发送：配置不多于固定消息数目一起发送并且等待时间小于一个固定延迟的数据。
The Consumer(消费者)
Push vs Pull
consumer控制消息的读取。producer push data to broker，consumer pull data from broker。
优缺点：
- consumer pull的优点：consumer自己控制消息的读取速度和数量。
- consumer pull的缺点：如果broker没有数据，则可能要pull多次忙等待，Kafka可以配置consumer long pull一直等到有数据。
- consumer push的缺点：客户端处理不过来并没做限流导致cpu吃紧。
Consumer Position
大部分消息系统由broker记录哪些消息被消费了，但Kafka不是。Kafka由consumer控制消息的消费，consumer甚至可以回到一个old offset的位置再次消费消息。
Consumer group
每一个consumer实例都属于一个consumer group。
每一条消息只会被同一个consumer group里的一个consumer实例消费。
不同consumer group可以同时消费同一条消息。
Consumer Rebalance(负载均衡)
消息Deliver guarantee
Message Delivery Semantics三种：
-
At most once消息可能会丢，但绝不会重复传输 -
At least one消息绝不会丢，但可能会重复传输 -
Exactly once每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。
Producer：
- 有个”acks“配置可以控制接收的leader的在什么情况下就回应producer消息写入成功。(消息不会丢)
Consumer：
- 读取消息，写log，处理消息。如果处理消息失败，log已经写入，则无法再次处理失败的消息，对应”At most once“。
- 读取消息，处理消息，写log。如果消息处理成功，写log失败，则消息会被处理两次，对应”At least once“。
- 读取消息，同时处理消息并把result和log同时写入。这样保证result和log同时更新或同时失败，对应”Exactly once“。
Kafka默认保证at-least-once delivery，容许用户实现at-most-once语义，exactly-once的实现取决于目的存储系统，kafka提供了读取offset，实现也没有问题。
Distribution
Consumer Offset Tracking
1）High-level consumer记录每个partition所消费的maximum offset，并定期commit到offset manager（broker）。
2）Simple consumer需要手动管理offset。现在的Simple consumer Java API只支持commit offset到zookeeper。
Consumers and Consumer Groups
1）consumer注册到zookeeper
2）属于同一个group的consumer（group id一样）平均分配partition，每个partition只会被一个consumer消费。
3）当broker或同一个group的其他consumer的状态发生变化的时候，consumer rebalance就会发生。
Zookeeper协调控制
1）管理broker与consumer的动态加入与离开。
2）触发负载均衡，当broker或consumer加入或离开时会触发负载均衡算法，使得一个consumer group内的多个consumer的订阅负载平衡。
3）维护消费关系及每个partition的消费信息。
日志压缩（Log Compaction）
1）针对一个topic的partition，压缩使得Kafka至少知道每个key对应的最后一个值。
2）压缩不会重排序消息。
3）消息的offset是不会变的。
4）消息的offset是顺序的。
5）压缩发送和接收能降低网络负载。
6）以压缩后的形式持久化到磁盘。
