Kafka -- 缓冲区里的数据什么时候发送
我们数据都写入了缓冲区，那这里的数据不可能一直放在缓存里的，所以kafka有一个线程，叫做Sender，这个线程，会一直运行，查看缓冲区里的可以发送的消息，就会把他发出去，下面看看有几种场景可以发消息。
内存池不够
上一篇也提供，当申请的内存不足时，就会进入阻塞状态，这个阻塞状态是在waiters的deque里放入一个Condition对象，所以当waiters里有Condition对象的时候，说明此事内存池是不够的，此事就可以发送消息了。
文章图片
批次写满
我们回忆一下上篇的内容，每个RecordBatch默认为16k，可能会有多个消息往一个RecordBatch写，当写满16k的时候，此时就具备了发送出去的条件。
所以Sender就会从元数据里拿到每一个topic+partition构成的TopicPartition，每一个TopicPartition又有一个Deque，从Deque里拿出已经写满的RecordBatch发出去。
这里有个比较重要的是，每次都只检查deque里的第一个RecordBatch，只要他满了，就可以开始发送。
文章图片
时间到了
如果RecordBatch一直不到16k，那消息也不能一直存放在缓存里吧，所以lingerMs，默认0ms，通过linger.ms进行设置。也就是当lingerMs毫秒后，这个RecordBatch如果没有16k，也会发送出去。所以这里我们一般不能用默认值，当默认为0ms的时候，Sender每次都直接把消息发出去，这样就失去了RecordBatch按批次分发的优势了。
由于kafka发送失败的时候会进行重试，所以如果有重试的话，那以重试的时间作为准，通过retry.backoff.ms进行设置，默认100ms，所以重试的时候，当超过100ms的时候也会自动发出去。
如果过期了，这些RecordBatch就会从队列里移除，并且释放对应的内存资源。
其他
其他两个，分布为缓冲区关闭的时候或者有进程在flush的时候。
连接
当确认到可以发送的deque的时候，就会把对应的Node给记录下来，存放在Node列表中，这个Node是每个partition的leader节点，如果没有对应的leader节点，就需要进行标记，等发送的时候再重新拉取元数据信息。
文章图片
遍历完每个RecordBatch的队列后，此时还没有达到要发出去的条件，毕竟Node里对应的broker服务器，此时还不知道能不能连接的上，所以还要验证有没有连接，如果没有，看看能不能连接的上，如果都不行，说明这个Node节点是用不了了，此时就要把这个Node从Node列表中，那这个Node对应的消息就不能发送了。
【Kafka -- 缓冲区里的数据什么时候发送】上面的Node对应的是broker服务器，如果Node0和Node1是一个服务器，那发送的时候，就会把同一个服务器的对应的RecordBatch封装成一个个的ClientRequest一起发送。
推荐阅读
- 深入浅出谈一下有关分布式消息技术（Kafka）
- 15.Kafka
- 小人物
- Springboot整合kafka的示例代码
- 华山山庄
- 搭建大数据三节点（Hadoop、Hbase、Zookeeper、Kafka、Hive）环境（含配置文件参考）
- kafka集群维护
- 十年开发大佬整理的（六大Redis+Nginx+kafka+MySQL+JVM实战文档）
- JavaScript|JavaScript WebGL 帧缓冲区对象
- 用 logstash 从 kafka 读取数据写入 Elasticsearch（qbit）