Kafka
代码操做及解释
1、在运行每个单独class的时，要先检查pom文件中的主程序是否对应的是要执行的class
后面的发送信息的（Producer）运行操作的命令：
编译：mvn compile -Dexec.mainClass="com.kinginsai.bigdata.kafka.producer.ProducerSample"
运行：mvn exec:java -Dexec.mainClass="com.kinginsai.bigdata.kafka.producer.ProducerSample" -Dexec.classpathScope=runtime -Dmaven.test.skip=true
2、先发送100条信息，用的是producer中的Producer异步发送带回调函数和Partition负载均衡
编译成功：
运行成功：有50个0和50个1
3、开始运行consumer，先将pom文件改为consumer的
后面运行消费的（Consumer）操作命令：
编译：mvn compile -Dexec.mainClass="com.kinginsai.bigdata.kafka.consumer.ConsumerSample"
运行：mvn exec:java -Dexec.mainClass="com.kinginsai.bigdata.kafka.consumer.ConsumerSample" -Dexec.classpathScope=runtime -Dmaven.test.skip=true
4、运行consumersample中的helloworld。一般来讲工作中有，但是不推荐，因为什么都不用关心，每条消息都会有一条offset，在消费的时候就会以offset的偏移量为主，就是当前消费哪个offset会告诉kafka，下次再消费的时候会以偏移量的下一个位置继续消费，这是正常的操作形式。但是，这种形式在一般工作中很少很少有这种需要打印system.out，只是打印出kafka的数据，很多时候，我们是要拿数据去做一个业务处理，而做业务处理时就会出现操作失败，也有可能出现耗时的，在基于这样的场景下再去使用这个就很尴尬了，它会定时提交，在提交的时候你有可能没有操作完，但是提交之后，下次就消费不到了。就会出现很多问题。
因为有consumer，offset的topic就会记录在客户端在哪个partition上消费了哪个offset，室友记录的，所有在下次的时候就会发现，之前订阅过了就不会再消费了。
编译成功：
运行成功：
手动提交
5、修改pom文件
6、先发送100条信息，再手动提交。
7、提交，先注释掉手动提交的代码，反复消费，看是否可以重复消费，再取消注释，手动提交之后再消费是消费不到的。
运行结果：
8、手动对每个Partition进行提交，先发送100条信息。这没有做什么优化反而多循环，之前是都拉取下来做循环，这次是针对每次拉取下来的做循环，这是为多线程处理的时候做铺垫，多线程是对每个partition做单独的处理，在单独处理的情况下，就会出现有的partition成功，有的不成功，在这种情况下，我们循环
运行结果：
9、手动订阅某个或某些分区，并提交offset。
运行结果：
Consumer注意事项
1、单个分区的消息只能由ConsumerGroup中某个Consumer消费，也就是Consumer对partition可以是一对多或者一对一。
2、Consumer从Partition中消费信息是顺序，默认从头开始消费。
3、单个ConsumerGroup会消费所有Partition中的消息，比如：有一个consumer有两到三个partition，consumer可以消费所有的partition。
consumer基本概念
kafka的每个消息都会进入到每个partition，如果只有一个Consumer在消费的情况下，那就代表着partition数据变成串行，但是consumer比partition多是没有意义的，目前最佳事件就是一个consumer对应一个partition，这样依然可以利用CPU的性能，还可以并行处理partition中所有的数据，所以在这样的情况下，利用了高效遍历，这肯定依赖了多线程。
运行结果：
10、多线程处理consumer
运行结果：
11、也是多线程运行，这个稍微复杂，更类似于现在的生产环境。首先创建了CunsumerExecutor，也就是一个线程池。这两个最主要的区别就是consumer是创建次数，ConsumerThreadSample就是创建多次，就有一个线程就会创建一次，还有就是消息来了去做分发，consumer自身不做任何处理。以下是这次的思路。没有具体说这两种哪个好哪个不好，视情况而定。
运行结果：
12、控制offset的起始位置。手动提交offset可能还是不能更精准的控制offset，想要控制offset的起始位置，比如说需要重复消费。
这里的开始消费的位置根据发送的信息的填写。这里会打印很多回，因为我们做的是一个循环，每次循环都是根据消费的位置开始的。
这个练习告诉我们，kafka是不会随便丢消息的，和正常的消息队列是有区别的。
运行结果：
13、流量控制。因为kafka是高吞吐量，不会分配到太多的内存，当达到一个峰值的时候，consumer很可能会被停掉，这个时候就需要限流。partition1和partition0都是消费了前40条信息之后断开。
运行结果：
常见问题
问题解释：没有接受到offset数据
解决办法：不要关闭当前的命令，重新发送一遍信息，consumer就会接收到信息之后就会自动消费到。
详细学习内容可观看Spark快速大数据处理扫一扫~~~或者引擎搜索Spark余海峰
