kafka

模式

1. 点对点
2. 发布订阅（存储有7天）

基础架构

1. 分布式（非主从）
2. 通过 zookeeper，每个broker都可以成为主节点，存在controller（独享锁）
3. 有一个active节点，其余都为stand by
4. 流式数据

组成

Zookeeper：帮助记录和选举broker,负责记录和分发topic,分区，副本信息，和节点服务信息
Producer：数据推送方，Java或 flume
Consumer:数据消费方

配置文件

1. 配置标识 broker ‘.id
2. 配置存储时间和心跳检测时间
3. 配置zookeeper节点地址

broker组成

1. 多分区partition，抽象出topic
2. 单topic分布在多broker的partition里，命名多为topic 名－分区号（topic A- o）
3. 数据存储文件夹名称：topic名+partition名
4. 备份，分区在其余broker里备份

命令

Kafka-topic.sh —bootstrap-server Kafka节点 —create —topic 主题名称 —partition 数量 —replication 数量

topic

1. —Create,创建
2. —alter修改
3. —list 列表
4. —bootstrap-server 集群地址，可多指定，重复次数多的ip优先使用
5. —partition 分区数
6. —replication 副本数

数据结构

1. K-V型式，不去重，追加。
2. 数据内容为二进制(byte [])

数据流向

produce

组成：
拦截器，序列化，分区器，缓冲区（可设置时间和缓冲区大小，满足分发），发送线程
分区器
默认3种

1. 指定分区
2. 根据key hash ％分区数
3. 随机 random key 然后％分区数

消息可靠性：

1. ACK机制
   Ack=0 默认成功
   ack=1 保证主分区收到
   Ack=-1 保证所有区收到
2. 幂等性 新增sequence值，单produce单分区递增 (开启 ack默认为一1)
3. 重试机制
4. 事务

项目实战优化

1. 订单需要保证有序，且需要partition均衡
   解决方案：根据订单号做分区规则，可以保证有序，数据量大可以先线程池队列化(kafka api得线程池处理)处理
   ,
2. 幂等
   可以通过redis.setnx方法
   key = topic:pardition:offset
   redis.setnx(key ,alue);如果没设置过返回1，设置过返回0

消息堆积

1. 消息堆积时新增partition不会让旧消息重新分配，新数据会进入新分区，所以无法解决消息堆积
   可以增加线程处理分区数据
2. 消费者挂了 排查问题 修改max.poll.records，减少一批拉取的消息数量，同时增大max.poll.interval.ms参数，避免由于拉取间隔时间过长导致自我驱逐
3. 先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。
   临时建立好原先10倍或者20倍的queue数量(新建一个topic，partition是原来的10倍)。
   然后写一个临时分发消息的consumer程序，这个程序部署上去消费积压的消息，消费之后不做耗时处理，直接均匀轮询写入临时建好分10数量的queue里面。
   紧接着征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的消息。
   这种做法相当于临时将queue资源和consumer资源扩大10倍，以正常速度的10倍来消费消息。
   等快速消费完了之后，恢复原来的部署架构，重新用原来的consumer机器来消费消息