Mamba Out

Topic：一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。 Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。 Segment：partition物理上由多个segment组成，下面2.2和2.3有详细说明。 offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。parti..

1、顺序读写kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能，顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写。2、零拷贝Kafka高吞吐量的原因其中有个重要技术就是Zero-Copy(零拷贝)系统调用机制传统的文件拷贝由于应用程序无法直接读取内核空间的数据，如果要读取这些数据，那么必须把数据从读取缓冲区拷贝到应用程序缓冲区 用户态把数据拷贝到核心态Socket Buffer，然后发送到网卡DMA(Di.

生产者丢失消息生产者(Producer) 调用send方法发送消息之后，消息可能因为网络问题并没有发送过去。Kafka提供了同步发送消息方法，会返回一个Future对象，调用get()方法进行阻塞等待，就可以知道消息是否发送成功。如果消息发送失败的话，可以通过Producer 的retries（重试次数）参数进行设置，当出现网络问题之后能够自动重试消息发送，避免消息丢失。另外，建议还要设置重试间隔，因为间隔太小的话重试的效果就不明显消费者丢失消息消息在被追加到 Partition(分区)的时

Kafka的Topic是由多个Partition组成，理论上一个Topic的分区越多，集群所能达到的吞吐量就越大。分区不是越多越好1、客户端/服务端所需要的内存就越多由于Kafka支持批量消息发送，它会为每个分区缓存消息，当消息的大小达到batch.size后，就会将消息打包发送，如果分区数量很大，就会占用producer服务器一部分内存，consumer端由于分区数量很多，就会创建很多线程去消费分区消息，频繁的线程切换也会降低消费者服务器性能。2、文件句柄的开销每个分区消息在broke

模型对比KafkaRocketMQ数据可靠性RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication Kafka使用异步刷盘方式，异步ReplicationRocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。另外Kafka的Replication以topic为单位，支持主机宕机，备机自动切换，但是

场景很多系统会用到MQ做消息缓存，但是随之而来会带来一些问题，比如系统由于故障消费组的消费能力突然大幅度降低，导致几千万条的数据积压在MQ里几个小时，假设故障之前的消费者已经允许是消费组最大的数量了，即使消费者数量已经全部恢复，消费能力恢复到故障之前的状态，也需要经过一段时间才能消费完积压的消息，如果是在生产环境，这有可能就会带来灾难，那么我们如何解决这个问题呢？问题分析导致MQ消息积压的根本原因就是因为消费者的消费速度不够，如果我们能提高消费者的消费能力，问题就能够解决，那么问题就来了，我们的

面试中肯定会被问到MQ方面的问题，那么面试官一定会问你如何保证消息的顺序性，Q：看你有用到Kafka消息中间件，请问怎么保证消息顺序消费？A：在发送消息的时候指定同一个

问题描述Kafka消费者出现偏移量提交异常，报错信息如下：Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.