模式
- 点对点
- 发布订阅（存储有7天）
基础架构
- 分布式（非主从）
- 通过 zookeeper，每个broker都可以成为主节点，存在controller（独享锁）
- 有一个active节点，其余都为stand by
- 流式数据
组成
Zookeeper：帮助记录和选举broker,负责记录和分发topic,分区，副本信息，和节点服务信息
Producer：数据推送方，Java或 flume
Consumer:数据消费方
配置文件
- 配置标识 broker ‘.id
- 配置存储时间和心跳检测时间
- 配置zookeeper节点地址
broker组成
- 多分区partition，抽象出topic
- 单topic分布在多broker的partition里，命名多为topic 名－分区号（topic A- o）
- 数据存储文件夹名称：topic名+partition名
- 备份，分区在其余broker里备份
命令
Kafka-topic.sh —bootstrap-server Kafka节点 —create —topic 主题名称 —partition 数量 —replication 数量
topic
- —Create,创建
- —alter修改
- —list 列表
- —bootstrap-server 集群地址，可多指定，重复次数多的ip优先使用
- —partition 分区数
- —replication 副本数
数据结构
- K-V型式，不去重，追加。
- 数据内容为二进制(byte [])
数据流向
produce
组成：
拦截器，序列化，分区器，缓冲区（可设置时间和缓冲区大小，满足分发），发送线程
分区器
默认3种
- 指定分区
- 根据key hash ％分区数
- 随机 random key 然后％分区数
消息可靠性：
- ACK机制
Ack=0 默认成功
ack=1 保证主分区收到
Ack=-1 保证所有区收到 - 幂等性 新增sequence值，单produce单分区递增 (开启 ack默认为一1)
- 重试机制
- 事务
项目实战优化
- 订单需要保证有序，且需要partition均衡
解决方案：根据订单号做分区规则，可以保证有序，数据量大可以先线程池队列化(kafka api得线程池处理)处理
,
- 幂等
可以通过redis.setnx方法
key = topic:pardition:offset
redis.setnx(key ,alue);如果没设置过返回1，设置过返回0
消息堆积
- 消息堆积时新增partition不会让旧消息重新分配，新数据会进入新分区，所以无法解决消息堆积
可以增加线程处理分区数据 - 消费者挂了 排查问题 修改max.poll.records，减少一批拉取的消息数量，同时增大max.poll.interval.ms参数，避免由于拉取间隔时间过长导致自我驱逐
- 先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。
临时建立好原先10倍或者20倍的queue数量(新建一个topic，partition是原来的10倍)。
然后写一个临时分发消息的consumer程序，这个程序部署上去消费积压的消息，消费之后不做耗时处理，直接均匀轮询写入临时建好分10数量的queue里面。
紧接着征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的消息。
这种做法相当于临时将queue资源和consumer资源扩大10倍，以正常速度的10倍来消费消息。
等快速消费完了之后，恢复原来的部署架构，重新用原来的consumer机器来消费消息
