一、Kafka 主要用来做什么
作为消息系统：Kafka 具备系统解藕，流量削峰，缓冲，异步通信，扩展性，可恢复性等功能，以及消息顺序性保障和回溯消费
作为存储系统：Kafka 把消息持久化到磁盘，相比较基于内存存储的系统，降低了数据丢失的风险，可以将数据保留策略设置为永久或启用主题的日志压缩功能即可，这里我也没有见到过实际的应用，留在这里暂时作为了解即可
作为流式处理平台：未来需要时再研究
二、Kafka 的基本概念
1 Producer，Broker 和 Consumer
Kafka 体系架构包括若干个 Producer, 若干个 Broker，若干个 Consumer，以及一个 Zookeeper 集群。
Producer 将消息发给 Broker，Broker 负责将收到的消息存储到硬盘，而 Consumer 负责从 Broker 订阅并消费消息。
Zookeeper 主要负责管理 Broker 集群。
我们常说的 Kafka 集群，其实就这其中的若干个 Broker 组成的集群
2 Topic 和 Partition
2.1 理解概念
其实个人感觉这里的理解可以类比 Mysql，Topic 就是这个表的结构，消息就是表里面的每一行数据，Partition 就是分表。
同一个 Topic，Producer 可以发多个消息，这么多个消息都存储在不同的 Partition 上，并且通过 offset 来进行标识（类似 Mysql 里的主键 ID），不过 offset 并不跨区，就相当于 Mysql 不同分表里的主键 ID 一样
每一条消息被发送到 broker 之前，会根据分区规则来选择存储在哪个具体的分区
1.Kafka 同一主题下的不同分区包含的消息是不同的
2.Kafka 的分区可以分布在不同的 broker 上，所以一个主题可以横跨多个 broker，解决了单机 IO瓶颈问题，通过修改分区的数量，还可以实现水平扩展
2.2 Partition 和 Replica
2.2.1 Kafka 的分区有多副本 Replica 机制，不同的副本处于不同的 broker 上，当 leader 出现故障时，从 follower 中重新选举出新的 leader 副本对外提供服务。通过增加副本的数量，可以提升容灾的能力。
虽然 leader 宕机之后，可以故障转移快速选举出一个新的 leader，但是宕机的时候写入 leader 的消息，如果还没来得及同步，消息也一样会丢失。
这个时候需要在业务系统里实现补偿重试的逻辑，比如添加 ack 等到全部同步之后才认为是成功，否则就进行重试，再次发送消息到 Kafka 中。
Producer 和 Consumer 只和 leader 副本进行交互，follower 副本只负责消息的同步。
若 Kafka 有 10 个分区，3个副本，总体一共有 30 个副本，其中包含 10 个 leader 副本和 20个 follower 副本。
Kafka 消费端也具备一定的容灾能力，Consumer 使用 Pull 模式从服务端拉取消息，并且保存消费的具体位置？当 Consumer 宕机后恢复上线可以根据之前保存的消费位置重新拉取需要的消息进行消费，这样就不会造成消息丢失 ？ -- Consumer 都宕机了，offset 保存在哪？
2.2.2 理解 ISR，OSR 和 AR
分区里的所有副本统称为 AR（Assigned Replicas）
- 与 leader 保持同步副本叫 ISR (In-Sync Replicas)，包含 leader
- 与 leader 副本同步滞后过多的副本叫 OSR （Out-of-Sync Replicas），不包含 leader
leader 宕机之后只会从 ISR 集合中选择下一个 leader
2.2.3 理解 HW，LEO 和 SR 之间的关系
HW （High WaterMark）高水位，可消费消息的最后一位 + 1
LEO（Low End Offset）, 已有的消息的最后一位 +1，也是当前即将要写入最新消息的位置
消费者只能消费 HW 之前的消息，之后的消息表示还没有同步完成