我们在上次的笔记中提到了kafka的特点，这一次我们来看看它的其它细节和问题。

其它细节

消息从生产者出发，经过中间人到达消费者。

为什么kafka支持高吞吐？

如果等一条消息结束（即返回success）之后在发送，那么太慢了，并且“细嚼慢咽”也会让许多请求积压（咱们不能忘了还有重试这么一说）。为此，我们要批量发送，同时进行数据压缩。

图片来自课件：

这是中间人的文件结构，原因在于适应磁盘磁头的写入方式，原因在于顺序写入对于磁盘来说效率最高，当然，在我看来，未来随着技术发展，说不定这个文件结构也会随着磁盘的改进而改变。

我们有了偏移量，那就拥有了一段数组。我们可以把这段数组用散列表的形式进行保存和查找。

二分查找到最大索引位置，之后用偏移量寻找

二者对比图来自课件内容：

传统拷贝：

零拷贝：

我们可以发现，零拷贝的优点在于简化了数据传输的流程，同时减少了应用空间的压力。

这里不是指人工实时分配，而是指在业务上线时就确定好一切的安排。但是…… 明显可行但不用，因为新增业务需要停掉全部服务，一个坏掉，全部都坏掉…… 因此，我们需要进行Reblance。

如果我们对一个机器进行重启，需要会关闭一个Broker，此的如该Boker上存在的Leader，那么将发生leader切换。

而此时，因为数据在不断的写入，对于刚刚关闭重启的Broker来说，和新Leader之间一定会存在数据延迟，此时Broker会追赶数据，重新加入到SRI。

当数据追赶完成之后，我们需要回切leader，这一步叫做prefer leader，这一步的目的是为了避免，在一个集群长期运行后，所有的leader都分布在少教节点上，导致教据的不均衡。

但是数据的时间成本大，并且不能采用多并发处理。在一个两副本的集群中，重启了两合机器，对某一分片来进，可能两个分片都在这合机器上面，则会导致该集群处于不可用的状态。

替换本质上就是一个需要追更多数据的重启操作，因为正常重启只需要追一小部分，而替换则是需要复制整个leader的数据，时间会更长。

扩容：当分片分配到新的机器上以后，相当于要从0开始复制一些新的副本缩容：缩容节点上面的分片也会分片到集群中剩余节点上面，分配过去的副本也会从0开始复制数据

以上三个操作均有数据复制所带来的时间成本问题，所以对于Kafka来说，运维操作所带来的时间成本是不容忽视的