Kafka---总结篇

为了保证可靠性，一个分区可以有多个副本。其中分为leader副本和follower副本。所有副本统称为AR(assigned replicas),所有与leader副本保持一定程度同步的副本（包括leader）组成ISR(in-sync replicas)。follower滞后leader指定的时间时，则会退出 ISR。（不可读，只当做备份作用）；就是从leader副本拉取消息，如果持续拉取速度慢于leader副本写入速度，慢于时间超过replica.lag.time.max.ms后，它就变成“非同步”副本，

每个生产者会被分配一个ProducerId(PID)，SeqNumber
然后生产者端和Broker端都有 SeqNumber 的映射关系
生产者每发送一条消息后就将对应的分区序列号加一
broker端会比较序列号，如果new Sq old sq +1,说明有消息丢失了。对生产者抛出异常
怎么保证PID相同的生产者干扰数据
在分配PID时，会分配epoch，新的生产者就会加1，如果出现了两个同样的生产者PID一样，取epoch最大的那个。
Producer过程
$Kafka---总结篇,词库加载错误:未能找到文件“C:\Users\Administrator\Desktop\火车头9.8破解版\Configuration\Dict_Stopwords.txt”。,服务,网络,操作,第3张$
写入分区策略：
- 轮询策略（默认分区策略）
- 随机策略
- 按键保存策略。
  其中轮询策略是默认的分区策略，而随机策略则是较老版本的分区策略，不过由于其分配的均衡性不如轮询策略，故而后来改成了轮询策略为默认策略。
  确定好消息的topic+partition后，直接发送给对应leader副本所在的broker。消息的可靠性主要通过acks参数来配置，主要有以下三种：
  （1）acks=0, 生产者发送消息后不需要等待任务服务端的响应。吞吐性能最好，可靠性最差。
  （2）acks=1, 只要分区的leader副本成功写入消息即可。消息的可靠性和吞吐量折中
  （3）acks=-1或all，生产者在发送消息后，需要等待ISR中的所有副本都成功写入消息之后才能收到来自服务端的成功响应。但因为可能ISR中只有leader副本，也会导致消息不可靠。更高可靠性需要配置 min.insync.replicas，指定写入的最小ISR的数量，如果没有达到则会发送失败。
  Comsumer过程
  groupCoordinator和comsumerCoordinator之间的逻辑如下：
  （1）每一个broker都有coordinator(辅助实现消费组的初始化和分区的分配)，根据groupId进行哈希取模得到选举那个coordinator对消费组进行管理
  （2）消费者向负载最小的节点请求获取到groupCoordinator, 然后连接到groupCoordinator节点并发送JoinGroup请求。
  （3）groupCoordinator为消费组选举一个消费组的leader。如果没有消费组leader,则加入group的第一个消费者为leader。如果消费组leader挂了之后，会比较随意的选举一个。
  （4）消费者leader从选举出的分区分配策略来实施具体的分区分配（逻辑下面会介绍）
  （5）groupCoordinator发送SyncGroupRequest请求来同步分配方案给各个消费者。
  （6）每个消费者都会和groupCoordinator保持心跳(默认3s)，一旦超时（session.timeout.ms=45s），该消费者会被移除,并触发再平衡；或者消费者处理消息的时间过长（max.poll.interval.ms=5分钟），也会触发平衡
  总结了一下：
  （1）find_coordinator
  （2）join_group
  （3）sync_group
  （4）hearbeat
  分区策略：
  1.RangeAssignor分配策略
  按照消费者总数和分区总数进行整除运算来获得一个跨度，然后将分区按照跨度进行平均分配，以保证分区尽可能均匀地分配给所有的消费者。
  2.RoundRobinAssignor分配策略（默认的分区策略）
  将消费组内所有消费者及消费者订阅的所有主题的分区按照字典序排序，然后通过轮询方式逐个将分区依次分配给每个消费者。
  3.StickyAssignor分配策略
  目的：（1）分区的分配尽可能均匀（2）分区的分配尽可能与上次分配的保持相同
  4.自定义分区策略
  选举分区分配策略：
  （1）收集各个消费者支持的所有分配策略，组成候选集candidates
  （2）每个消费者从candidates中找出第一个自身支持的策略，为这个策略投一票
  （3）计算candidates中各个策略的选票数，选票数最多的策略即为当前消费者的分配策略
  触发消费再均衡情况：
  （1）有新的消费者加入消费组
  （2）有消费者宕机下线。
  （3）有消费者主动退出消费组
  （4）消费组所对应的groupCoordinator节点发生了变更
  （5）消费组内所订阅的任意主题或者主题的分区数量发生了变化
  提交方式
  （1）自动提交
  （2）提交当前偏移量
  （3）异步提交。api只管提交偏移量，无须等待broker做出响应。
  （4）提交特定偏移量
  底层存储数据
  流式处理
  kafka中使用的优化技巧
  1.copy-zero（零拷贝）
  linux操作系统 “零拷贝” 机制使用了sendfile方法，允许操作系统将数据从Page Cache 直接发送到网络，只需要最后一步的copy操作将数据复制到 NIC 缓冲区，这样避免重新复制数据。示意图如下：
  $Kafka---总结篇,词库加载错误:未能找到文件“C:\Users\Administrator\Desktop\火车头9.8破解版\Configuration\Dict_Stopwords.txt”。,服务,网络,操作,第4张$
  2. 页缓存技术 pagecache, 使用mmap来映射文件到程序内存中。
  为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存
  3.顺序写
  $Kafka---总结篇,词库加载错误:未能找到文件“C:\Users\Administrator\Desktop\火车头9.8破解版\Configuration\Dict_Stopwords.txt”。,服务,网络,操作,第5张$
  4.分区分段+索引
  Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。
  5.批量读写
  Kafka数据读写也是批量的而不是单条的。
  6.批量压缩
  如果每个消息都压缩，但是压缩率相对很低，所以Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩
  性能压测：
  数据不撒谎，Flink-Kafka性能压测全记录！
  大概读写的QPS:
  20W