Kafka 0.9+Zookeeper3.4.6集群搭建、配置，新Client API的使用要点，高可用性测试，以及各种坑_kafka_advertised_host_name 可以配置两个吗?

4. 使用Kafka的Producer API来完成消息的推送

1) Kafka 0.9.0.1的java client依赖：

Xml代码  

1. <dependency>  
2.     <groupId>org.apache.kafka</groupId>  
3.     <artifactId>kafka-clients</artifactId>  
4.     <version>0.9.0.1</version>  
5. </dependency>  

2) 写一个KafkaUtil工具类，用于构造Kafka Client

Java代码  

1. public class KafkaUtil {  
2.     private static KafkaProducer<String, String> kp;  
3.   
4.     public static KafkaProducer<String, String> getProducer() {  
5.         if (kp == null) {  
6.             Properties props = new Properties();  
7.             props.put("bootstrap.servers", "10.0.0.100:9092,10.0.0.101:9092");  
8.             props.put("acks", "1");  
9.             props.put("retries", 0);  
10.             props.put("batch.size", 16384);  
11.             props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");  
12.             props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");  
13.             kp = new KafkaProducer<String, String>(props);  
14.         }  
15.         return kp;  
16.     }  
17. }  

  KafkaProducer<K,V>的K代表每条消息的key类型，V代表消息类型。消息的key用于决定此条消息由哪一个partition接收，所以我们需要保证每条消息的key是不同的。

  Producer端的常用配置

• bootstrap.servers：Kafka集群连接串，可以由多个host:port组成
• acks：broker消息确认的模式，有三种：
  0：不进行消息接收确认，即Client端发送完成后不会等待Broker的确认
  1：由Leader确认，Leader接收到消息后会立即返回确认信息
  all：集群完整确认，Leader会等待所有in-sync的follower节点都确认收到消息后，再返回确认信息
  我们可以根据消息的重要程度，设置不同的确认模式。默认为1
• retries：发送失败时Producer端的重试次数，默认为0
• batch.size：当同时有大量消息要向同一个分区发送时，Producer端会将消息打包后进行批量发送。如果设置为0，则每条消息都独立发送。默认为16384字节
• linger.ms：发送消息前等待的毫秒数，与batch.size配合使用。在消息负载不高的情况下，配置linger.ms能够让Producer在发送消息前等待一定时间，以积累更多的消息打包发送，达到节省网络资源的目的。默认为0
• key.serializer/value.serializer：消息key/value的序列器Class，根据key和value的类型决定
• buffer.memory：消息缓冲池大小。尚未被发送的消息会保存在Producer的内存中，如果消息产生的速度大于消息发送的速度，那么缓冲池满后发送消息的请求会被阻塞。默认33554432字节（32MB）

  更多的Producer配置见官网：http://kafka.apache.org/documentation.html#producerconfigs

  3) 写一个简单的Producer端，每隔1秒向Kafka集群发送一条消息：

Java代码  

1. public class KafkaTest {  
2.     public static void main(String[] args) throws Exception{  
3.         Producer<String, String> producer = KafkaUtil.getProducer();  
4.         int i = 0;  
5.         while(true) {  
6.             ProducerRecord<String, String> record = new ProducerRecord<String, String>("test", String.valueOf(i), "this is message"+i);  
7.             producer.send(record, new Callback() {  
8.                 public void onCompletion(RecordMetadata metadata, Exception e) {  
9.                     if (e != null)  
10.                         e.printStackTrace();  
11.                     System.out.println("message send to partition " + metadata.partition() + ", offset: " + metadata.offset());  
12.                 }  
13.             });  
14.             i++;  
15.             Thread.sleep(1000);  
16.         }  
17.     }  
18. }  

  在调用KafkaProducer的send方法时，可以注册一个回调方法，在Producer端完成发送后会触发回调逻辑，在回调方法的 metadata对象中，我们能够获取到已发送消息的offset和落在的分区等信息。注意，如果acks配置为0，依然会触发回调逻辑，只是拿不到 offset和消息落地的分区信息。

    跑一下，输出是这样的：

  乍一看似乎offset乱掉了，但其实这是因为消息分布在了两个分区上，每个分区上的offset其实是正确递增的。

5. 使用Kafka的Consumer API来完成消息的消费

1) 改造一下KafkaUtil类，加入Consumer client的构造。

Java代码  

1. public class KafkaUtil {  
2.     private static KafkaProducer<String, String> kp;  
3.     private static KafkaConsumer<String, String> kc;  
4.   
5.     public static KafkaProducer<String, String> getProducer() {  
6.         if (kp == null) {  
7.             Properties props = new Properties();  
8.             props.put("bootstrap.servers", "10.0.0.100:9092,10.0.0.101:9092");  
9.             props.put("acks", "1");  
10.             props.put("retries", 0);  
11.             props.put("batch.size", 16384);  
12.             props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");  
13.             props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");  
14.             kp = new KafkaProducer<String, String>(props);  
15.         }  
16.         return kp;  
17.     }  
18.       
19.     public static KafkaConsumer<String, String> getConsumer() {  
20.         if(kc == null) {  
21.             Properties props = new Properties();  
22.             props.put("bootstrap.servers", "10.0.0.100:9092,10.0.0.101:9092");  
23.             props.put("group.id", "1");  
24.             props.put("enable.auto.commit", "true");  
25.             props.put("auto.commit.interval.ms", "1000");  
26.             props.put("session.timeout.ms", "30000");  
27.             props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");  
28.             props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");  
29.             kc = new KafkaConsumer<String, String>(props);  
30.         }  
31.         return kc;  
32.     }  
33. }  

  同样，我们介绍一下Consumer常用配置

• bootstrap.servers/key.deserializer/value.deserializer：和Producer端的含义一样，不再赘述
• fetch.min.bytes：每次最小拉取的消息大小（byte）。Consumer会等待消息积累到一定尺寸后进行批量拉取。默认为1，代表有一条就拉一条
• max.partition.fetch.bytes：每次从单个分区中拉取的消息最大尺寸（byte），默认为1M
• group.id：Consumer的group id，同一个group下的多个Consumer不会拉取到重复的消息，不同group下的Consumer则会保证拉取到每一条消息。注意，同一个group下的consumer数量不能超过分区数。
• enable.auto.commit：是否自动提交已拉取消息的offset。提交offset即视为该消息已经成功被消费，该组下的Consumer无法再拉取到该消息（除非手动修改offset）。默认为true
• auto.commit.interval.ms：自动提交offset的间隔毫秒数，默认5000。

  全部的Consumer配置见官方文档：http://kafka.apache.org/documentation.html#newconsumerconfigs

2) 编写Consumer端：

Java代码  

1. public class KafkaTest {  
2.     public static void main(String[] args) throws Exception{  
3.         KafkaConsumer<String, String> consumer = KafkaUtil.getConsumer();  
4.         consumer.subscribe(Arrays.asList("test"));  
5.         while(true) {  
6.             ConsumerRecords<String, String> records = consumer.poll(1000);  
7.             for(ConsumerRecord<String, String> record : records) {  
8.                 System.out.println("fetched from partition " + record.partition() + ", offset: " + record.offset() + ", message: " + record.value());  
9.             }  
10.         }  
11.     }  
12. }  

  运行输出：

说明：

• KafkaConsumer的poll方法即是从Broker拉取消息，在poll之前首先要用subscribe方法订阅一个Topic。
• poll方法的入参是拉取超时毫秒数，如果没有新的消息可供拉取，consumer会等待指定的毫秒数，到达超时时间后会直接返回一个空的结果集。
• 如 果Topic有多个partition，KafkaConsumer会在多个partition间以轮询方式实现负载均衡。如果启动了多个 Consumer线程，Kafka也能够通过zookeeper实现多个Consumer间的调度，保证同一组下的Consumer不会重复消费消息。注 意，Consumer数量不能超过partition数，超出部分的Consumer无法拉取到任何数据。
• 可以看出，拉取到的消息并不是完全顺序化的，kafka只能保证一个partition内的消息先进先出，所以在跨partition的情况下，消息的顺序是没有保证的。
• 本 例中采用的是自动提交offset，Kafka client会启动一个线程定期将offset提交至broker。假设在自动提交的间隔内发生故障（比如整个JVM进程死掉），那么有一部分消息是会被 重复消费的。要避免这一问题，可使用手动提交offset的方式。构造consumer时将enable.auto.commit设为false，并在代 码中用consumer.commitSync()来手动提交。

如果不想让kafka控制consumer拉取数据时在partition间的负载均衡，也可以手工控制：

Java代码  

1. public static void main(String[] args) throws Exception{  
2.     KafkaConsumer<String, String> consumer = KafkaUtil.getConsumer();  
3.     String topic = "test";  
4.     TopicPartition partition0 = new TopicPartition(topic, 0);  
5.     TopicPartition partition1 = new TopicPartition(topic, 1);  
6.     consumer.assign(Arrays.asList(partition0, partition1));  
7.     while(true) {  
8.         ConsumerRecords<String, String> records = consumer.poll(100);  
9.         for(ConsumerRecord<String, String> record : records) {  
10.             System.out.println("fetched from partition " + record.partition() + ", offset: " + record.offset() + ", message: " + record.value());  
11.         }  
12.         consumer.commitSync();  
13.     }  
14. }  

 使用consumer.assign()方法为consumer线程指定1个或多个partition。

  此处的坑：

  题外话：

6. Kafka集群高可用性测试

1) 查看当前Topic的状态：

Shell代码  

1. /kafka-topics.sh --describe --zookeeper 10.0.0.100:2181,10.0.0.101:2181,10.0.0.102:2181 --topic test  

  输出：

  可以看到，partition0的leader是broker1，parition1的leader是broker0

2) 启动Producer向Kafka集群发送消息

  输出：

3) 登录SSH将broker0，也就是partition 1的leader kill掉

  再次查看Topic状态：

  可以看到，当前parition0和parition1的leader都是broker1了

  此时再去看Producer的输出：

  能看到Producer端的DEBUG日志显示与broker0的链接断开了，此时Kafka立刻开始更新集群metadata，更新后的metadata表示broker1现在是两个partition的leader，Producer进程很快就恢复继续运行，没有漏发任何消息，能够看出Kafka集群的故障切换机制还是很厉害的

4) 我们再把broker0启动起来

Shell代码  

1. bin/kafka-server-start.sh -daemon config/server.properties   

  然后再次检查Topic状态：

  我们看到，broker0启动起来了，并且已经是in-sync状态（注意Isr从1变成了1,0），但此时两个partition的leader还都是 broker1，也就是说当前broker1会承载所有的发送和拉取请求。这显然是不行的，我们要让集群恢复到负载均衡的状态。

  这时候，需要使用Kafka的选举工具触发一次选举：

Shell代码  

1. bin/kafka-preferred-replica-election.sh --zookeeper 10.0.0.100:2181,10.0.0.101:2181,10.0.0.102:2181  

  选举完成后，再次查看Topic状态：

  可以看到，集群重新回到了broker0挂掉之前的状态

  但此时，Producer端产生了异常：

  原因是Producer端在尝试向broker1的parition0发送消息时，partition0的leader已经切换成了broker0，所以消息发送失败。

  此时用Consumer去消费消息，会发现消息的编号不连续了，确实漏发了一条消息。这是因为我们在构造Producer时设定了retries=0，所以在发送失败时Producer端不会尝试重发。

  将retries改为3后再次尝试，会发现leader切换时再次发生了同样的问题，但Producer的重发机制起了作用，消息重发成功，启动Consumer端检查也证实了所有消息都发送成功了。

至此，我们通过测试证实了集群出现单点故障和恢复的过程中，Producer端能够保持正确运转。接下来我们看一下Consumer端的表现：

5) 同时启动Producer进程和Consumer进程

  此时Producer一边在生产消息，Consumer一边在消费消息

6) 把broker0干掉，观察Consumer端的输出：

能看到，在broker0挂掉后，consumer也端产生了一系列INFO和WARN输出，但同Producer端一样，若干秒后自动恢复，消息仍然是连续的，并未出现断点。

7) 再次把broker0启动，并触发重新选举，然后观察输出：

  能看到，重选举后Consumer端也输出了一些日志，意思是在提交offset时发现当前的调度器已经失效了，但很快就重新获取了新的有效调度器，恢复 了offset的自动提交，验证已提交offset的值也证明了offset提交并未因leader切换而发生错误。

  如上，我们也通过测试证实了Kafka集群出现单点故障时，Consumer端的功能正确性。