参照 大白话 kafka 架构原理
秒杀活动
1: 风险控制 、2： 库存锁定 、3： 生成订单 、4： 短信通知 、5： 更新数据 通过消息系统将秒杀活动业务拆分开
将不急需处理的业务放在后面慢慢处理
秒杀活动
1： 风险控制 、2： 库存锁定 、3: 消息系统 、4: 生成订单 、5： 短信通知 、6： 更新数据 流量的控制
- 网关在接受到请求后，就把请求放入到消息队列里面
Producer 往Kafka集群生成数据 消费者
Consumer 往Kafka里面去获取数据，处理数据、消费数据 Kafka的数据是由消费者自己去拉去Kafka里面的数据 主题
topic 分区
partition 默认一个topic有一个分区（partition），自己可设置多个分区（分区分散存储在服务器不同节点上） Kafka的集群架构 broker
一个kafka服务器就是一个broker partition
Topic只是逻辑上的概念，partition在磁盘上就体现为一个目录。 Consumer Group
消费组 消费数据的时候，都必须指定一个group id，指定一个组的id假定程序A和程序B指定的group id号一样，那么两个程序就属于同一个消费组。
特殊:
同一个消费者成员，只有一个能消费topic同一个topic,重新指定一个group id号以后，可以消费不同消费组之间没有影响，消费组需自定义，消费者名称程序自动生成（独一无二） Controller
Kafka节点里面的一个主节点，借助zookeeper。 kafka写数据
顺序写（追加写）
保证写数据性能 零拷贝机制
消费者读取数据流程：
消费者发送请求给kafka服务kafka服务去os cache缓存读取数据（缓存没有就去磁盘读取数据）从磁盘读取了数据到os cache缓存中os cache复制数据到kafka应用程序中kafka将数据（复制）发送到socket cache中socket cache通过网卡传输给消费者
linux sendfile技术
1.消费者发送请求给kafka服务2.kafka服务去os cache缓存读取数据（缓存没有就去磁盘读取数据）3.从磁盘读取了数据到os cache缓存中4.os cache直接将数据发送给网卡5.通过网卡将数据传输给消费者 Kafka日志分段保存
topic_a
三个分区
服务器1
目录topic_a-0
kafka数据就是message
数据存储在log文件里
.log结尾的就是日志文件在kafka中把数据文件就叫做日志文件
（分段存储）
一个分区下面默认有n多个日志文件
一个日志文件默认1G
服务器2
目录topic_a-1
服务器3
目录topic_a-2: Kafka二分查找定位数据
一条消息就有两个位置
offset：相对偏移量（相对位置）
存在物理磁盘上面，在position Position
position：磁盘物理位置
稀疏索引
kafka每当写入了4k大小的日志（.log），就往index里写入一个记录索引。其中会采用二分查找。 高并发网络设计
NIO
Reactor网络设计模式 Kafka冗余副本保证高可用
创建主题时，可以指定分区，也可以指定副本个数
副本是有角色的：leader partition
1、写数据、读数据操作都是从leader partition去操作的。2、会维护一个ISR（in-sync- replica ）列表，但是会根据一定的规则删除ISR列表里面的值
生产者发送消息流程
消息首先要写入到leader partition中写完了以后，还要把消息写入到ISR列表里面的其它分区，写完后才算这个消息提交follower partition：从leader partition同步数据 优秀架构思考-总结 高并发、高可用、高性能
高可用：多副本机制
高并发：网络架构设计
三层架构：多selector -> 多线程 -> 队列的设计（NIO）
高性能：
写数据
把数据先写入到OS Cache写到磁盘上面是顺序写，性能很高
读数据：
根据稀疏索引，快速定位到要消费的数据零拷贝机制 减少数据的拷贝 减少了应用程序与操作系统上下文切换 实际应用 coordinator
每个consumer group都会选择一个broker作为自己的coordinator
他是负责监控这个消费组里的各个消费者的心跳，以及判断是否宕机，然后开启rebalance的
运行流程
1）每个consumer都发送JoinGroup请求到Coordinator2）然后Coordinator从一个consumer group中选择一个consumer作为leader3）把consumer group情况发送给这个leader4）接着这个leader会负责制定消费方案5）通过SyncGroup发给Coordinator6）接着Coordinator就把消费方案下发给各个consumer他们会从指定的分区的 leader broker开始进行socket连接以及消费消息 Rebalance
consumer group靠coordinator实现了Rebalance
策略
range
range策略就是按照partiton的序号范围
p0~3 consumer1p4~7 consumer2p8~11 consumer3
round-robin
轮询分配
consumer1: 0,3,6,9consumer2:1,4,7,10
sticky
尽可能保证在rebalance的时候，让原本属于这个consumer 的分区还是属于他们，然后把多余的分区再均匀分配过去，这样尽可能维持原来的分区分配的策略
consumer1：0-3 consumer2: 4-7 consumer3: 8-11假设consumer3挂了consumer1：0-3，+8,9 consumer2: 4-7，+10,11 controller如何管理整个集群
1: 竞争controller的 /controller/id2：controller服务监听的目录：/broker/ids/ 用来感知 broker上下线 /broker/topics/ 创建主题，我们当时创建主题命令，提供的参数，ZK地址。/admin/reassign_partitions 分区重分配 …… 时间轮机制 延时任务 Broker管理
LEO
在kafka里面，无论leader partition还是follower partition统一都称作副本（replica）。每次partition接收到一条消息，都会更新自己的LEO，也就是log end offset，LEO其实就是最新的offset + 1
HW
高水位 LEO有一个很重要的功能就是更新HW，如果follower和leader的LEO同步了，此时HW就可以更新 HW之前的数据对消费者是可见，消息属于commit状态。HW之后的消息消费者消费不到。 其他
Kafka的核心原理
如何去评估一个集群资源
搭建了一套kafka集群 -》 介绍了简单的一些运维管理的操作。
生产者（使用，核心的参数）
消费者（原理，使用的，核心参数）
broker内部的一些原理
XMind - Trial Version
