一.Message Queue好处
解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
峰值处理能力：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
二.Message Queue的发布/订阅模式
一对多，消费者消费数据之后不会清除消息：因为有多个消费者，消息保留一段时间
两种模式：1.推送给消费者
2.消费者主动拉取（kafka采取）
三.kafka架构
消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。
一个 topic 可以分为多个 partition，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个follower。
四.文件存储机制
消费位移信息存放在了__consumer_offsets内置topic中，默认分区50个。
由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment。每个 segment对应两个文——“.index”文件和“.log”文件。
总偏移量=文件名的偏移量+一个massage的偏移量
五.生产者
ISR(in-sync Replica)
Leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集合。当 ISR 中的 follower 完成数据的同步之后，follower 就会给leader 发送 ack。如果 follower长时间 未 向 leader 同 步 数 据 ， 则 该 follower 将 被 踢 出 ISR ， 该 时 间 阈 值 由replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR 中选举新的 leader。
ACK应答机制
request.required.asks=0
# 0:相当于异步的，不需要leader给予回复，producer立即返回，发送就是成功,
那么发送消息网络超时或broker crash(1.Partition的Leader还没有commit消息 2.Leader与Follower数据不同步)，
既有可能丢失也可能会重发
# 1：当leader接收到消息之后发送ack，丢会重发，丢的概率很小
# -1：当所有的follower都同步消息成功后发送ack. 丢失消息可能性比较低
Exactly Once 语义
开启幂等性的 Producer 在
初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而
Broker 端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker 只
会持久化一条。
六.消费者
分区分配策略
1）RoundRobin
RoundRobin是轮询算法，它会将所有的TopicPartition统一进行分配。
如果Topic01只c1接受，则不会分配到其他同组消费者。
2）Range
它是针对每一个Topic单独进行分配
offset 的维护
消费者偏移量的保存，按照（consumer_group，topic，partition）-> （offset）来保存，同一组中的消费者可以读取上一个消费者的offset。offset根据key值保存到kafka自动生成的topic中，用哈希来分配到50个分区。
当消费者组中加入新的消费者，则会消费者中的消费者进行重新分配。
六.Zookeeper 在 Kafka 中的作用
Kafka 集群中有一个 broker 会被选举为 Controller，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。Controller 的管理工作都是依赖于 Zookeeper 的。
七.Kafka 事务
Producer 事务
为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer获得的PID 和Transaction ID 绑定。这样当Producer 重启后就可以通过正在进行的 TransactionID 获得原来的 PID。
为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就
是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。TransactionCoordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。