[TODO]Kafka及Kafka Streaming架构熟悉

基本概念

名称	解释
Broker	消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群
Topic	Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic
Producer	消息生产者，向Broker发送消息的客户端
Consumer	消息消费者，从Broker读取消息的客户端
ConsumerGroup	每个Consumer属于一个特定的Consumer Group，一条消息可以发送到多个不同的Consumer Group，但是一个Consumer Group中只能有一个Consumer能够消费该消息
Partition	物理上的概念，一个topic可以分为多个partition，每个partition内部是有序的

Consumer Group

• consumer group下可以有一个或多个consumer instance，consumer instance可以是一个进程，也可以是一个线程
• group.id是一个字符串，唯一标识一个consumer group
• consumer group下订阅的topic下的每个分区只能分配给某个group下的一个consumer(当然该分区还可以被分配给其他group)

Rebalance

触发Rebalance的条件

• 组成员发生变更(新consumer加入组、已有consumer主动离开组或已有consumer崩溃了-这两者的区别后面会谈到)
• 订阅主题数发生变更-这当然是可能的，如果你使用了正则表达式的方式进行订阅，那么新建匹配正则表达式的topic就会触发rebalance
• 订阅主题的分区数发生变更

均衡策略：

• range和round-robin

Coordinator

确定consumer group位移信息写入__consumers_offsets的哪个分区。具体计算公式：

　　__consumers_offsets partition# = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount)

注意：groupMetadataTopicPartitionCount由offsets.topic.num.partitions指定，默认是50个分区。该分区leader所在的broker就是被选定的coordinator

Coordinator同Consumer Group之间的协议：

Heartbeat请求：consumer需要定期给coordinator发送心跳来表明自己还活着
LeaveGroup请求：主动告诉coordinator我要离开consumer group
SyncGroup请求：group leader把分配方案告诉组内所有成员
JoinGroup请求：成员请求加入组
DescribeGroup请求：显示组的所有信息，包括成员信息，协议名称，分配方案，订阅信息等。通常该请求是给管理员使用

---

Kafka Streaming

Stream Processing Topology

1、stream是Kafka Stream最重要的抽象，它代表了一个无限持续的数据集。stream是有序的、可重放消息、对不可变数据集支持故障转移
2、一个stream processing application由一到多个processor topologies组成，其中每个processor topology是一张图，由多个streams（edges）连接着多个stream processor（node）
3、一个stream processor是processor topology中的一个节点，它代表一个在stream中的处理步骤：从上游processors接受数据、进行一些处理、最后发送一到多条数据到下游processors

Kafka Stream提供两种开发stream processing topology的API

1、high-level Stream DSL：提供通用的数据操作，如map和fileter
2、lower-level Processor API：提供定义和连接自定义processor，同时跟state store（下文会介绍）交互

Kafka-Streams的一些亮点：
* 被设计为一个简单、轻量的客户端库，可以很容易的嵌入到任意的Java应用程序中并与现有的包、部署操作工具整合。
* 除了使用Apache Kafka自身作为内部消息层，在系统上也不需要外部依赖；尤其的，它使用Kafka的分区模型水平伸缩处理能力同时保证强有序性。
* 支持容错的local state，使得可以执行快速高效的有状态的操作，如基于窗口的连接和聚合。
* 采用一次处理一条记录的方式来实现毫秒级处理延迟，支持基于事件时间[event time]的窗口操作。
* 提供必要的流处理源语，以及一个高级的 Streams-DSL和一个低级的 Processor-API。

Source Processor：它是一种特殊的stream processor，没有上游processor。它通过消费一个或者多个topic中的记录为自身的拓扑生成输入流，然后将他们转发到下游processor
Sink Processors：也是一种特殊的stream processor，他没有下游processor。它发送从上游processor接收到的所有记录到一个特定的Kakfa Topic

Time

Event Time:
Processiong Time:
Ingestion Time:

Kafka Stream基于TimestampExtractor接口获取对应data记录的时间戳信息；

State

无状态是指消息的处理不依赖与其他消息，而有状态则相反；比如join/groupby操作均为有状态；

Kafka Streams提供State Store机制；

源码分析

运行架构

TopologyBuilder builder = new TopologyBuilder();

builder.addSource("Source", "streams-file-input");

builder.addProcessor("Process", new MyProcessorSupplier(), "Source");
builder.addStateStore(Stores.create("Counts").withStringKeys().withIntegerValues().inMemory().build(), "Process");

builder.addSink("Sink", "streams-wordcount-processor-output", "Process");

KafkaStreams streams = new KafkaStreams(builder, props);
streams.start();

// usually the stream application would be running forever,
// in this example we just let it run for some time and stop since the input data is finite.
Thread.sleep(5000L);

streams.close();

TopologyBuilder: 构建Kafka Topology关系，主要方法有addSource()/addProcessor()/addStateStore()/addSink();
KafkaStreams: 为Kafka Streams运行上下文，开启关闭整个应用；

KafkaStreams启动流程：
* TopologyBuilder构建Topology过程；
* 构建GlobalStreamThread，用于维护全局状态存储更新；
* 根据配置thread数量，构造StreamThread；
* start()启动；

GlobalStreamThread

StreamThread

疑问： Topic+Partition -> Thread -> Task之间的关系是什么？如何进行调度的？

TopologyBuilder构建Topology过程

    public synchronized ProcessorTopology buildGlobalStateTopology() {
        final Set<String> globalGroups = globalNodeGroups();
        if (globalGroups.isEmpty()) {
            return null;
        }
        return build(globalGroups);
    }

名称	类型	含义
nodeToSourceTopics	HashMap

运维

惊群与脑裂

这两种现象存在于>=0.9的版本中，当时consumer是依赖zookeeper的。

惊群： 任何Broker和Consumer的增减都会触发所有Consumer的Rebalance，导致同一个group里不同的consumer拥有了相同的partition,进而引起Consumer的消费错乱；
脑裂： 每个consumer单独通过zookeeper判断哪些broker和consumer宕机，不同的consumer在同一个时刻看到的view可能不一致，导致Rebanlance;

计算

参考：
* Consumer Group Example: https://cwiki.apache.org//confluence/display/KAFKA/Consumer+Group+Example
* Kafka架构：https://mp.weixin.qq.com/s?__biz=MjM5NjM5MzQ1MQ==&mid=2651039642&idx=1&sn=0a74d76a26a37f9367883b8e34e48737&chksm=bd1eff1e8a697608e156ad8221b7b841001e9d56af00df6365c0308ab0ddb2d868144774daeb&mpshare=1&scene=1&srcid=06152ieW99Yl1m9AaLBpp9HF&key=f17d8322b1674f1fdadb72b65c7e641f3f02c47dc7e75d6e9c6ca699c06f454483dc3a651f3fd4fcb04c85a42edd6a393b94b92f3fea9336a18bb0c506e056fa6788536a4b224bec9d51778ed60ff144&ascene=0&uin=MTQ4MDQ4Nzk1&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.12.4+build(16E195)&version=12020510&nettype=WIFI&fontScale=100&pass_ticket=i1kEs9SVYFzwE6kZTTRIaIm5HhVlqwYzdXuLqmvNPi0%3D
* Kafka Rebalance: http://www.cnblogs.com/huxi2b/p/6223228.html
* Kafka 分区数、Key和Consumer线程数：http://www.cnblogs.com/huxi2b/p/4757098.html
* new consumer api: http://blog.csdn.net/opensure/article/details/72419701
* http://www.apache.wiki/display/Kafka/Kafka+Streams
* Kafka Streams扩容：http://docs.confluent.io/current/streams/architecture.html
* Kafka Coordinator： http://blog.csdn.net/wangqyoho/article/details/54944657
* Kafka Consumer Rewrite Design: https://cwiki.apache.org/confluence/display/KAFKA/Kafka+0.9+Consumer+Rewrite+Design#Kafka0.9ConsumerRewriteDesign-Failuredetectionprotocol
* Kafka Coodinator: http://blog.csdn.net/chunlongyu/article/details/52791874