列出集群当前所有可用的topic

Kafka-topic.sh –list –zookeeper zookeeper_address

zookeeper_address 需要注意的是  默认的是 zookeerper管理节点的根目录下的 brokers节点为存放kafka对应的服务器数据信息

但是如果在CDH-Manager 的管理界面中 Kafka 配置中 修改了 zookeeper.chroot （默认为空）修改为 /kafka

则 zookeeper_address 为 安装kafka broker进程的kafka server 对应的ip:2181（默认端口）/kafka

zookeeper.chroot Znode in zookeeper that should be used as a root for this kafka cluster.

replication.factor  意味着 某一分区的全部副本 即如果为1 意味着整个kafka集群中只有这一个副本  不是原来有一个，再加一个副本

生产者 配置时注意大小写

分区消费指定时 注意port为9092  不是19092 否则会报 java.nio.channel.closeException

分区消费时 注意 kafka.api  kafka.javaapi.* 的区别

一个index 一个log

分区文件都是存在与kafka日志所在目录下  如 topicName-0  topicName-1  topicName-0目录下包含 00000000000000000.log 00000000000000000.index

replica.log.max.messages 表示 同步状态的follower与leader 相差最大不能超过的记录数 否则认为不同步

leader处理partition的所有读写请求

Kafka每个topic的partition有N个副本，其中N是topic的复制因子。Kafka通过多副本机制实现故障自动转移，当Kafka集群中一个Broker失效情况下仍然保证服务可用。在Kafka中发生复制时确保partition的预写式日志有序地写到其他节点上。N个replicas中。其中一个replica为leader，其他都为follower，leader处理partition的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。

Kafka必须提供数据复制算法保证,如果leader发生故障或挂掉，一个新leader被选举并接收客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为leader,或者换句话说,follower追赶leader数据。leader负责维护和跟踪ISR中所有follower滞后状态。当生产者发送一条消息到Broker,leader写入消息并复制到所有follower。消息提交之后才被成功复制到所有的同步副本。消息复制延迟受最慢的follower限制,重要的是快速检测慢副本,如果follower”落后”太多或者失效,leader将会把它从replicas从ISR移除。

是什么原因导致分区的副本与leader不同步

一个副本可以不同步Leader有如下几个原因

慢副本：在一定周期时间内follower不能追赶上leader。最常见的原因之一是I / O瓶颈导致follower追加复制消息速度慢于从leader拉取速度。

卡住副本：在一定周期时间内follower停止从leader拉取请求。follower replica卡住了是由于GC暂停或follower失效或死亡。

新启动副本：当用户给主题增加副本因子时，新的follower不在同步副本列表中，直到他们完全赶上了leader日志。

一个partition的follower落后于leader足够多时，被认为不在同步副本列表或处于滞后状态。在Kafka-0.8.2.x中,副本滞后判断依据是副本落后于leader最大消息数量(replica.lag.max.messages)或replicas响应partition leader的最长等待时间(replica.lag.time.max.ms)。前者是用来检测缓慢的副本,而后者是用来检测失效或死亡的副本

Kafka中replication复制数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下如果Follower都复制完都落后于Leader，而如果Leader突然宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

优点

性能高，吞吐量大。

降低了系统和磁盘开销，Leader充分利用磁盘顺序读以及send file(zero copy)机制。

降低Leader与Follower之间网络开销和交互次数。

缺点

有可能会占用大量网络带宽(例如本来集群很大而且数据量很多，后来新增Broker节点需要迁移数据)，甚至堵塞网络，需要有流控机制，否则会影响线上服务。

因为Follower是批量拉取Leader消息，如果设置为保证所有replicas commit，才返回Ack给生产者会存在抖动现象，Follow拉取Leader修改HW，当HW与当次生产者请求logEndOffset的offst一致时，客户端等待时间会拉长。

kafka集群副本分布原理分析

Kafka中partition replication之间同步数据，从partition的leader复制数据到follower只需要一个线程(ReplicaFetcherThread)，实际上复制是follower(一个follower相当于consumer)主动从leader批量拉取消息的，这极大提高了吞吐量，从中可以看出无处不显示Kafka高吞吐量设计思想。

这是一个异步复制过程，follow从leader批量拉取消息进行同步数据

Kafka中partition replica复制机制：

Kafka中每个Broker启动时都会创建一个副本管理服务(ReplicaManager)，该服务负责维护ReplicaFetcherThread与其他Broker链路连接关系，该Broker中存在多少Follower的partitions对应leader partitions分布在不同的Broker上，有多少Broker就会创建相同数量的ReplicaFetcherThread线程同步对应partition数据，Kafka中partition间复制数据是由follower(扮演consumer角色)主动向leader获取消息，follower每次读取消息都会更新HW状态。每当Follower的partitions发生变更影响leader所在Broker变化时，ReplicaManager就会新建或销毁相应的ReplicaFetcherThread。

Kafka中partitions数据一致性：

Kafka中Producer发送消息到Broker，Broker有三种返回方式，分别为noack、leader commit成功就ack、leader和follower同时commit成功才返回ack。第三种方式是数据强一致性。

如何保证数据强一致性？

当Producer发送消息到leader partition所在Broker时，首先保证leader commit消息成功，然后创建一个“生产者延迟请求任务”，并判断当前partiton的HW是否大于等于logEndOffset，如果满足条件即表示本次Producer请求partition replicas之间数据已经一致，立即向Producer返回Ack。否则待Follower批量拉取Leader的partition消息时，同时更新Leader ISR中HW，然后检查是否满足上述条件，如果满足向Producer返回Ack。

http://www.cnblogs.com/bonelee/p/6893286.html

http://www.infoq.com/cn/articles/kafka-analysis-part-3?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global