21Kafka大合集

kafka是一个高吞吐的分布式消息队列系统。特点是生产者消费者模式，先进先出（FIFO）保证顺序，自己不丢数据，默认每隔7天清理数据。消息列队常见场景：系统之间解耦合、峰值压力缓冲、异步通信。

一、kafka架构简介

kafka架构的组成：
Kafka架构是由：

• producer（消息生产者）
• consumer（消息消费者）
• borker(kafka集群的server，负责处理消息读、写请求，存储消息，在kafka cluster这一层这里，其实里面是有很多个broker)
• topic（消息队列/分类相当于队列，里面有生产者和消费者模型）
• zookeeper(元数据信息存在zookeeper中，包括：存储消费偏移量，topic话题信息，partition信息) 这些部分组成。

kafka里面的消息是由topic来组织的，然后它把每个topic又分为很多个partition，这个是为了做并行的，在每个partition内部消息强有序，相当于有序的队列，其中每个消息都有个序号offset，比如0到12，从前面读往后面写。一个partition对应一个broker，一个broker可以管多个partition，比如说，topic有6个partition，有两个broker，那每个broker就管3个partition。这个partition可以很简单想象为一个文件，当数据发过来的时候它就往这个partition上面append，追加就行，消息不经过内存缓冲，直接写入文件，kafka和很多消息系统不一样，很多消息系统是消费完了我就把它删掉，而kafka是根据时间策略删除，而不是消费完就删除，在kafka里面没有一个消费完这么个概念，只有过期这样一个概念。
Kakfa提供了两种策略来删除数据。一是基于时间，二是基于partition文件大小。

producer自己决定往哪个partition里面去写，这里有一些的策略，譬如轮询、hash。consumer自己维护消费到哪个offset，每个consumer都有对应的group，group内是queue消费模型（各个consumer消费不同的partition，因此一个消息在group内只消费一次），group间是publish-subscribe消费模型，各个group各自独立消费，互不影响，因此一个消息在被每个group消费一次。

二、kafka的特点

• 系统的特点：生产者消费者模型，FIFO。
  Partition内部是FIFO的，partition之间呢不是FIFO的，当然我们可以把topic设为一个partition，这样就是严格的FIFO。
• 高性能：单节点支持上千个客户端，百MB/s吞吐，接近网卡的极限,零拷贝。
• 持久性：消息直接持久化在普通磁盘上且性能好。
• 分布式：数据副本冗余、流量负载均衡、可扩展。
• 很灵活：消息长时间持久化+Client维护消费状态。

三、kafka为什么吞吐量大、速度快

• 顺序读写：Kafka的message是不断追加到本地磁盘文件末尾的，而不是随机的写入，这使得Kafka写入吞吐量得到了显著提升 。这种方法是没有办法删除数据的 ，所以Kafka是不会删除数据的，它会把所有的数据都保留下来。
• Page Cache（操作系统内存）：Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存，通过操作系统的Page Cache，Kafka的读写操作基本上是基于内存的，读写速度得到了极大的提升。
• 零拷贝：linux操作系统 “零拷贝” 机制使用了sendfile方法， 允许操作系统将数据从Page Cache 直接发送到网络，只需要最后一步的copy操作将数据复制到 NIC 缓冲区（网卡缓冲区）， 这样避免重新复制数据，相比较于普通的读取数据，省略了把数据从服务器加载到application应用，再用应用到目标端的过程，直接从服务器到目标端。**通过这种 “零拷贝” 的机制，Page Cache 结合 sendfile 方法，Kafka消费端的性能也大幅提升。**这也是为什么有时候消费端在不断消费数据时，我们并没有看到磁盘io比较高，此刻正是操作系统缓存在提供数据。
• 分区分段+索引：Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度。
• 批量读写：Kafka数据读写也是批量的而不是单条的。在向Kafka写入数据时，可以启用批次写入，这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。
• 批量压缩：Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩。Kafka允许使用递归的消息集合，批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式，直到被消费者解压缩。Kafka支持多种压缩协议，包括Gzip和Snappy压缩协议。

四、kafka的broker的leader

简述：通过Zookeeper的临时节点来控制broker leader Controller的选举。
Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。例如：一旦有一个broker宕机了，这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态，并选取ISR列表中的一个replica作为partition leader（如果ISR列表中的replica全挂，选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了，则将新的leader设置为-1，等待恢复，等待ISR中的任一个Replica“活”过来，并且选它作为Leader；或选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader），这个broker宕机的事情，kafka controller也会通知zookeeper，zookeeper就会通知其他的kafka broker。

kafka broker controller的作用：

• 主题管理 : Kafka Controller 可以帮助我们完成对 Kafka 主题创建、删除和增加分区的操作，简而言之就是对分区拥有最高行使权。
• 分区重分配: 分区重分配主要是指，kafka-reassign-partitions 脚本提供的对已有主题分区进行细粒度的分配功能。这部分功能也是控制器实现的。。
• 在 broker 宕机后，控制器能够选举新的分区 Leader（针对partition）。
• Prefered 领导者选举 : Preferred 领导者选举主要是 Kafka 为了避免部分 Broker 负载过重而提供的一种换 Leader 的方案
• 集群成员管理: 主要管理 新增 broker、broker 关闭、broker 宕机。
• 数据服务: 控制器的最后一大类工作，就是向其他 broker 提供数据服务。控制器上保存了最全的集群元数据信息，其他所有 broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

Kafka判断一个节点是否活着有两个条件：

• 节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接。
• 如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久。
  符合以上条件的节点准确的说应该是“同步中的（in sync）”，而不是模糊的说是“活着的”或是“失败的”。Leader会追踪所有“同步中”的节点，一旦一个down掉了，或是卡住了，或是延时太久，leader就会把它移除。由参数replica.lag.max.messages和参数replica.lag.time.max.ms决定的。

五、kafka的consumer和consumer group

• 同一partition的一条message只能被同一个Consumer Group内的一个Consumer消费。不能够一个consumer group的多个consumer同时消费一个partition。
• 一个consumer group下，无论有多少个consumer，这个consumer group一定回去把这个topic下所有的partition都消费了。如果consumer group里面的consumer数量等于这个topic下的partition数量的时候，效率是最高的。

Consumer Rebalance的触发条件：（1）Consumer增加或删除会触发 Consumer Group的Rebalance（2）Broker的增加或者减少都会触发 Consumer Rebalance。

六、kafka的producer

Kafka producer 发送message不用维护message的offsite信息，因为这个时候，offsite就相当于一个自增id，producer就尽管发送message就好了。
kafka producer的ack的三种方式：

• ack=0 ,producer不等待broker同步完成的确认，继续发送下一条(批)信息
• ack=1 ,producer要等待leader成功收到数据并得到确认，才发送下一条message。Partition的Leader死亡，follwer尚未复制，数据就会丢失。
• ack=-1 ，producer得到所有配置的follwer确认，才发送下一条数据。
  

七、kafka的topic和partition

Topic相当于传统消息系统MQ中的一个队列queue，producer端发送的message必须指定是发送到哪个topic，但是不需要指定topic下的哪个partition，因为kafka会把收到的message进行load balance。
一般来说，（1）一个Topic的Partition数量大于等于Broker的数量，可以提高吞吐率。（2）同一个Partition的Replica尽量分散到不同的机器，高可用。
当add a new partition的时候，partition里面的message不会重新进行分配，原来的partition里面的message数据不会变，新加的这个partition刚开始是空的，随后进入这个topic的message就会重新参与所有partition的load balance。

replica副本数目不能大于kafka broker节点的数目，否则报错。这里的replica数其实就是partition的副本总数，其中包括一个leader，其他的就是copy副本。

Partition leader与follower：partition也有leader和follower之分。leader是主partition，producer写kafka的时候先写partition leader，再由partition leader push给其他的partition follower。partition leader与follower的信息受Zookeeper控制，一旦partition leader所在的broker节点宕机，zookeeper会冲其他的broker的partition follower上选择follower变为parition leader。

七、kafka的partition和segment

producer发message到某个topic，message会被均匀的分布到多个partition上，kafka broker收到message往对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息consumer才能消费，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

• segment file组成：由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件。
• segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个全局partion的最大offset(偏移message数)。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。
  
  索引文件存储大量元数据，数据文件存储大量消息，**索引文件中元数据指向对应数据文件中message的物理偏移地址。**其中以索引文件中 元数据3,497为例，依次在数据文件中表示第3个message(在全局partiton表示第368772个message)、以及该消息的物理偏移 地址为497。
  segment index file采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它 比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。

kafka的副本分配规则：

• 当有4个broker，创建1个topic包含4个Partition，2 Replication；数据Producer流动如图所示：
  
• 当集群中新增2节点，Partition增加到6个时分布情况如下：
  

八、kafka在什么情况下会丢失数据

• 1、producer配置acks=0
• 2、producer配置acks=1时，未同步副本leader宕机。
• 3、NO_ENOUGH_REPLICATE
  produer配置acks=all的时候，也是有可能会丢数据的，当某个partition的ISR列表中的副本数，不满足min.inSync.replicate的时候，生产者发送消息就得不到ack确认，这时候生产者会进入重试，重试次数为配置的message.send.max.retries，如果在重试次数内ISR列表副本数仍然达不到最小同步副本数，那么，生产者会抛出NO_ENOUGH_REPLICATE的异常，如果没能正确处理这个异常，很可能这条数据就丢失了。
  那么什么情况下ISR列表的副本数不足最小副本数呢？
  1、follower副本进程卡住，在一段时间内根本没有向leader副本发起同步请求，比如频繁的Full GC。
  2、follower副本进程同步过慢，在一段时间内都无法追赶上leader副本，比如IO开销过大。
• 4、NOT_LEADER_FOR_PARTITION
  1、其中一台Broker会出现与zk的sessionTime out 连接超时，接着导致Controller重新选举，导致producer元数据不正确，此时写入该Broker，会抛出NOT_LEADER_FOR_PARTITION的警告，此时可能会发生数据丢失。
  2、auto.leader.rebalance.enable=true 也会进行重新选举leader的操作，导致写入原leader，抛出NOT_LEADER_FOR_PARTITION。
• 5、磁盘故障
  kafka的数据一开始就是存储在PageCache上的，定期flush到磁盘上的，也就是说，不是每个消息都被存储在磁盘了，如果出现断电或者机器故障等，PageCache上的数据就丢失了。
  可以通过log.flush.interval.messages和log.flush.interval.ms来配置flush间隔。
• 6、Producer生产数据过长
  单批数据的长度超过限制会丢失数据，报kafka.common.MessageSizeTooLargeException异常
  生产者生产的数据，大于消费者配置的能拉取的最大消息大小，这条大数据将会消费失败。
• 7、无重发重试
  网络负载很高或者磁盘很忙写入失败的情况下，没有自动重试重发消息。没有做限速处理，超出了网络带宽限速。kafka一定要配置上消息重试的机制，并且重试的时间间隔一定要长一些，默认1秒钟并不符合生产环境（网络中断时间有可能超过1秒）。
• 8、消费者崩溃
  如果auto.commit.enable=true，当consumer fetch了一些数据但还没有完全处理掉的时候，刚好到commit interval出发了提交offset操作，接着consumer crash掉了。这时已经fetch的数据还没有处理完成但已经被commit掉，因此没有机会再次被处理，数据丢失。
• 9、消费者异常没正确处理
  （1）Consumer消费者自动提交offset，在消费者消费数据异常时，没有将异常数据处理妥当，导致业务异常数据丢失。
  （2）Consumer手动批量提交offset，在批量位点中某个位点数据异常时，没有正确处理异常，而是将批量位点的最后一个offset提交，导致异常数据丢失。

九、kafka的数据语义

具备新的里程碑意义的功能的Kafka 0.11.x版本引入了exactly-once语义。
kafka有三种语义：at-least-once、at-most-once、exactly-once。
理想状况，网络良好，代码没有错误，则 Kafka 可以保证 exactly-once，但生产环境错综复杂，故障几乎无法避免。
kafka如何实现exactly-once语义？
第一块：依赖业务控制
对生产者来说：

• 每个分区只有一个生产者写入消息，当出现异常或超时，生产者查询此分区最后一个消息，用于决定后续操作时重传还是继续发送。
• 为每个消息增加唯一主键，生产者不做处理，由消费者根据主键去重。

对消费者来说：

• 关闭自动提交 offset 的功能，由消费者自动保存 offset。将 offset 和消息处理放在一个事务里面，事务执行成功认为消息被消费，否则事务回滚需要重新处理。

第二块：依赖kafka
1、幂等性，每个分区中精确一次且有序。
一个幂等性的操作就是一种被执行多次造成的影响和只执行一次造成的影响一样的操作。
对于单个分区，幂等生产者不会因为生产者或 broker 故障而产生多条重复消息。想要开启这个特性，获得每个分区内的精确一次语义，也就是说没有重复，没有丢失，并且有序的语义，只需要 producer 配置 enable.idempotence=true。
实现原理：每一批发送到 Kafka 的消息都将包含 PID 和一个从 0 开始单调递增序列号。

• 如果消息序号比 Broker 维护的序号大 1 以上，说明中间有数据尚未写入，也即乱序，此时 Broker 拒绝该消息。
• 如果消息序号小于等于 Broker 维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息。

**注意：**如果使用idempotence，即enable.idempotence为true，那么要求配置项max.in.flight.requests.per.connection的值必须小于或等于5；配置项retries的值必须大于0；acks配置项必须设置为all。
2、事务，跨分区原子写入。
上述幂等设计只能保证单个 Producer 对于同一个 <Topic, Partition> 的 Exactly Once 语义。
Kafka 现在通过新的事务 API 支持跨分区原子写入。这将允许一个生产者发送一批到不同分区的消息，这些消息要么全部对任何一个消费者可见，要么对任何一个消费者都不可见。这个特性也允许在一个事务中处理消费数据和提交消费偏移量，从而实现端到端的精确一次语义。
实现原理：应用程序必须提供一个稳定的（重启后不变）唯一的 ID，也即Transaction ID 。为了保证新的 Producer 启动后，旧的具有相同 Transaction ID 的 Producer 失效，每次 Producer 通过 Transaction ID 拿到 PID 的同时，还会获取一个单调递增的 epoch。由于旧的 Producer 的 epoch 比新 Producer 的 epoch 小，Kafka 可以很容易识别出该 Producer 是老的 Producer 并拒绝其请求。
则上述事务可以保证producer端的exactly once。

总结：Apache Kafka的exactly-once语义需要满足下面三个方面：

• 幂等：partition内部的exactly-once顺序语义
  需要修改broker的配置：enable.idempotence = true
• 事务：跨partition的原子性写操作
  配置consumer端的配置isolation.level，来正确使用事务API。（read_committed）
• Exactly-once 流处理
  如果要在流应用中实现相关语义，只需要配置 processing.guarantee=exactly_once。

十、kafka高可用之AR ISR OSR

• kafka分区中的所有副本统称为AR（Assigned Replicas）。
• 所有与leader副本保持一定程度同步的副本（包括leader副本在内）组成 ISR (In Sync Replicas)，因此 ISR 是 AR 中的一个子集。
• 消息会先发送到leader副本，然后follower副本才能从leader中拉取消息进行同步。同步期间，follow副本相对于leader副本而言会有一定程度的滞后。前面所说的 ”一定程度同步“ 是指可忍受的滞后范围，这个范围可以通过参数进行配置。与leader副本同步滞后过多的副本（不包括leader副本）将组成 OSR （Out-of-Sync Replied）
• AR = ISR + OSR，正常情况下，所有的follower副本都应该与leader 副本保持 一定程度的同步，即AR=ISR，OSR集合为空。
• leader副本负责维护和跟踪 ISR 集合中所有follower副本的滞后状态，当follower副本落后太多或失效时，leader副本会把它从 ISR 集合中剔除。
• **如果 OSR 集合中所有follower副本“追上”了leader副本，那么leader副本会把它从 OSR 集合转移至 ISR 集合。**默认情况下，当leader副本发生故障时，只有在 ISR 集合中的follower副本才有资格被选举为新的leader，而在 OSR 集合中的副本则没有任何机会（不过这个可以通过配置来改变）

follower 被踢出，进入 ISR 列表条件
能够进入 ISR 列表中的条件是可以进行参数配置的：

replica.lag.time.max.ms 默认值：10000，单位为：毫秒

该配置表示如果一个 follower 在有一个时间窗口内（默认值为 10 秒）没有发送任意 fetch 请求，leader 就会把这个 follower 从 ISR（in-sync replicas）移除，并存入 OSR 集合。
随着follower副本不断进行消息同步，follower副本LEO也会逐渐后移，并且最终赶上leader副本，此时follower副本就有资格进入ISR集合，追赶上leader副本的判定准侧是此副本的LEO是否小于leader副本HW，这里并不是和leader副本LEO相比。

Follower和Leader消息不同步，主要有三种情况：

• 慢副本：在一定周期内Follower不能赶上Leader。比如在一段时间内，由于Follower磁盘IO或网络IO的问题，导致数据写入速度慢。
• 卡住副本：Follower在一段时间内未向Leader获取同步数据(Fetch)的请求。比如由于GC导致进程卡住。
• 新启动副本：由于副本因子(offsets.topic.replication.factor)变化导致新增备份副本，此副本不在ISR列表，直到同步的消息赶上Leader。
  replica.lag.time.max.ms参数主要用于检测上述1和2两种情况，如果Follower Fetch数据的时间超过该值，认为节点是卡住，被踢出ISR；当Follower连续出现多次出现同步延迟超过此阈值时，就会被认为是慢副本，被踢出ISR。

Unclean 领导者选举（Unclean Leader Election）
当 leader 的所有副本都被剔除到了 OSR 列表中，此时 ISR 列表中只剩下 leader 了，此时 leader 自己“挂了”，那么 ISR 集合为空。此时该怎么选举 leader 呢？
Kafka 把所有不在 ISR 中的存活副本都称为非同步副本。通常来说，非同步副本落后 Leader 太多，因此，如果选择这些副本作为新 Leader，就可能出现数据的丢失。毕竟，这些副本中保存的消息远远落后于老 Leader 中的消息。在 Kafka 中，选举这种副本的过程称为 Unclean 领导者选举。
Broker 端参数unclean.leader.election.enable控制是否允许 Unclean 领导者选举。

十一、kafka的LEO HW LSO

HW （High Watermark）俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个offset之前的消息。
LEO （Log End Offset），标识当前日志文件中下一条待写入的消息的offset。上图中offset为9的位置即为当前日志文件的 LEO，LEO 的大小相当于当前日志分区中最后一条消息的offset值加1。分区 ISR 集合中的每个副本都会维护自身的 LEO ，而 ISR 集合中最小的 LEO 即为分区的 HW，对消费者而言只能消费 HW 之前的消息。

由此可见kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的follower副本都复制完，这条消息才会被确认已成功提交，这种复制方式极大的影响了性能。而在异步复制的方式下，follower副本异步的从leader副本中复制数据，数据只要被leader副本写入就会被认为已经成功提交。在这种情况下，如果follower副本都还没有复制完而落后于leader副本，然后leader副本宕机，则会造成数据丢失。kafka使用这种ISR的方式有效的权衡了数据可靠性和性能之间的关系。

LSO特指LastStableOffset。它具体与kafka的事务有关。
消费端参数——isolation.level,这个参数用来配置消费者事务的隔离级别。字符串类型，“read_uncommitted”和“read_committed”，表示消费者所消费到的位置，如果设置为“read_committed"，那么消费这就会忽略事务未提交的消息，既只能消费到LSO(LastStableOffset)的位置，默认情况下，”read_uncommitted",既可以消费到HW（High Watermak）的位置。
follower副本的事务隔离级别也为“read_uncommitted"，并且不可修改。
在开启kafka事务的同时，生产者发送了若干消息，（msg1，msg2，）到broker中，如果生产者没有提交事务（执行CommitTransaction），那么对于isolation.level=read_committed的消费者而言是看不到这些消息的，而isolation.level=read_uncommitted则可以看到。

可以得出一个结论：LSO≤HW≤LEO

十二、kafka的消费组和分区重平衡

当新的消费者加入消费组，它会消费一个或多个分区，而这些分区之前是由其他消费者负责的；另外，当消费者离开消费组（比如重启、宕机等）时，它所消费的分区会分配给其他分区。这种现象称为重平衡（rebalance）

• 重平衡是Kafka一个很重要的性质，这个性质保证了高可用和水平扩展。
• 不过也需要注意到，在重平衡期间，所有消费者都不能消费消息，因此会造成整个消费组短暂的不可用。
• 而且，将分区进行重平衡也会导致原来的消费者状态过期，从而导致消费者需要重新更新状态，这段期间也会降低消费性能。

消费者通过定期发送心跳（hearbeat）到一个作为组协调者（group coordinator）的broker来保持在消费组内存活。这个broker不是固定的，每个消费组都可能不同。当消费者拉取消息或者提交时，便会发送心跳。
如果消费者超过一定时间没有发送心跳，那么它的会话（session）就会过期，组协调者会认为该消费者已经宕机，然后触发重平衡。可以看到，从消费者宕机到会话过期是有一定时间的，这段时间内该消费者的分区都不能进行消息消费；通常情况下，我们可以进行优雅关闭，这样消费者会发送离开的消息到组协调者，这样组协调者可以立即进行重平衡而不需要等待会话过期。
**在0.10.1版本，Kafka对心跳机制进行了修改，将发送心跳与拉取消息进行分离，**这样使得发送心跳的频率不受拉取的频率影响。另外更高版本的Kafka支持配置一个消费者多长时间不拉取消息但仍然保持存活，这个配置可以避免活锁（livelock）。活锁，是指应用没有故障但是由于某些原因不能进一步消费。

十三、kafka的监控-KafkaOffsetMonitor

KafkaOffsetMonitor是Kafka的一款客户端消费监控工具，用来实时监控Kafka服务的Consumer以及它们所在的Partition中的Offset，我们可以浏览当前的消费者组，并且每个Topic的所有Partition的消费情况都可以一目了然。
将下载下来的KafkaOffsetMonitor jar包上传到linux上，可以新建一个目录KafkaMonitor，用于存放KafkaOffsetMonitor-assembly-0.2.0.jar进入到KafkaMonitor目录下，通过java编译命令来运行这个jar包：

java -cp KafkaOffsetMonitor-assembly-0.2.0.jar \
com.quantifind.kafka.offsetapp.OffsetGetterWeb \
--zk 10.0.0.50:12181,10.0.0.60:12181,10.0.0.70:12181 \
--port 8088  \
--refresh 5.seconds \
--retain 1.days