学习系列——kafak入门及其原理

Kafka简介
Kafka是linkedin使用Scala编写具有高水平扩展和高吞吐量的分布式消息系统。Kafka对消息保存时根据Topic进行归类，发送消息者成为Producer，消息接受者成为Consumer，此外kafka集群有多个kafka实例组成,每个实例(server)称为broker。无论是Kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性，为集群保存一些meta信息。

主流MQ对比

	ActiveMQ	RabbitMQ	Kafka
所属社区/公司	Apache	Mozilla Public License	Apache/LinkedIn
开发语言	Java	Erlang	Scala
支持的协议	OpenWire, STOMP, REST,XMPP,AMQP	AMQP	仿AMQP
事务	支持	不支持	0.11开始支持
集群	支持(不擅长)	支持(不擅长)	支持
负载均衡	支持	支持	支持
动态扩容	不支持	不支持	支持(zk)

kafaka支持对大数据量（ActiveMQ以及RabbitMQ无法支持大数据量，例如1秒10万等）数据快速落地，落地效率很高（一般是直接落地到本地磁盘）。RocketMQ的可靠性(数据一致性，数据不丢失)比Kafka高。数据量大的时候考虑kafka和RocketMQ，数据量不大时考虑ActiveMQ和RabbitMQ。kafka对事务支持的不是很好。
就吞吐量而言：Kafka>RocketMQ>RabbitMQ>ActiveMQ

kafka主要特性
Kafka是一个流处理平台，流平台需如下特性：

• 可发布和订阅流数据，类似于消息队列或者企业级消息系统，以容错的方式储存流数据。
• 可以在流数据产生时就进行处理。（一般写进队列数据什么样，读出数据就是什么样，写进和读出的数据一致。但是Kafka写进队列的数据和从队列读出的数据可以不同。）

AMQP协议
AMQP (Advanced Message Queuing Protocol) 是一个提供统一消息服务的标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件而设计。

server（Broker） AMQP服务端,接受客户端连接,实现AMQP消息队列和路由功能的进程。
producer 生产者，向broker发布消息的客户端应用程序。
consumer 消费者，向消息队列请求消息的客户端应用程序。

注：consumer可以拉去消息多次，即可以重复消费消息，broker是集群形式

tоpic 数据主题，是Kafka中用来代表一个数据流的一个抽象。发布数据时，可用topic对数据进行分类，也作为订阅数据时的主题。一个topic同时可有多个producer、 consumer。
Partition(分片) 每个partition是一个顺序的、不可变的record序列，partition中的record会被分配一个自增长的id，我们称之为offset(偏移量)。
Replication(复制) 每个partition还会被复制到其它服务器作为replication，这是一种冗余备份策略。

Partition(分片)
简单来说就是将数据均匀分布到不同服务器上，每台服务器只保留一部分数据，这样可以提高并发度。

Replication(复制)
因为对于数据采用了分片，即一台服务器上是无法保留完整数据的，当一台服务器挂掉后，就会导致数据不可用，为了提高数据的可靠性，需要将分片复制到其他服务器上。

tоpic
topic是kafka写操作的基本单元，一个topic可以有多个partition，一条消息仅属于一个topic

kafka如何向分片中写数据
客户端（client）每发送一条数据，就会向partition中写入一条数据，它会追加到已有的数据后面，其offset（偏移量，类似于下标）增加一位。

在kafka中，因为一个topic可以存在多个partition，因此数据是无序的，但是对于一个partition来说，数据是有序的，因为每生产一条消息 ，就会追加到其后面。因此，当确定一个partition以及offset就可以确定唯一的一条消息。
patition中除了有offset，还有key、value、timestamp三个字段，其中key是没有任何意义的。因为kafka不是key-value形式存储的，不能通过key检索数据。value是真正要存储到kafak当中的数据。kafka中除了用offset标记数据，还可以用timestamp来标记数据。假如发生了异常，我重启consuer时，不知道从什么地方开始消费，即不能通过offset来获取异常时的数据位置。或者发现今天的数据有问题，希望重新消费今天的数据。

kafka四个核心API

Producer API允许一个应用程序发布一串流式的数据到一个或者多个Kafka topic。
Consumer API允许一个应用程序订阅一个或多个topic，并且对发布给他们的流式数据进行处理。
Streams API允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换。
Connector API允许构建并运行可重用的生产者或者消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表(table)的所有变更内容。

API的使用可以参照官网：http://kafka.apache.org/22/documentation.html

Producer API

Properties props = new Properties();
props.put("batch.size",16384); //默认是16384
props.put("linger.ms",16384);
props.put("acks","all");
props.put("retries",1);
//...
Producer<String,String> producer = new KafkaProducer(props);
ProducerRecord<String,String> record = 
			new ProducerRecord<String,String>("my-topic","key","value");
producer.send(record);
producer.close();

1、Producer会为每个partition维护一个缓冲,用来记录还没有发送的数据，每个缓冲区大小用batch.size指定，默认值为16k 。（producer发送数据不是一条一条的发送,而是达到batch.size后一起发送）
2、linger.ms为 buffer中的数据在达到batch.size前，需要等待的时间。（如果数据只有15k，永远达不到16k，则永远无法发送到server端。此时可以通过linger.ms来控制发送，如果超过时间，即使达不到16k，也可以发送到server。）
3、acks用来配置请求成功的标准。（acks保证数据可靠性。主分片叫做leader，副分片叫做follower）

ack如何认定写是否成功?
0—只要发送了,就认为成功。
1—只要leader写成功了,就认为成功了。
all—leader, follower都成功了,就认为成功了。
ack为0存在数据丢失问题。
ack为1时也存在数据丢失的问题。主分片写成功了，但是突然挂掉，副分片还没写成功。

kafka API-consumer

Kafka Simple Consumer
Simple Cnsumer位于kafka.javaapi.consumer包中，不提供负载均衡、容错的特性每次获取数据都要指定topic，partition， offset， fetchSize
High-level Consumer
该客户端透明地处理kafka broker异常，透明地切换consumer的partition，通过和broker交互来实现consumer group级别的负载均衡。

Kafka的使用场景
消息系统
消息系统被用于各种场景，如解耦数据生产者，缓存未处理的消息。Kafka可作为传统的消息系统的替代者，与传统消息系统相比，kafka有更好的吐量、更好的可用性)这有利于处理大规模的消息。根据经验,通常消息传递对吞吐量要求较低，但可能要求较低的端到端延迟，并经常依赖kafka可靠的durable机制。在这方面， Kafka可以与传统的消息传递系统(ActiveMQ和RabbitMQ)相媲美。
存储系统
写入到kafka中的数据是落地到了磁盘上，并且有冗余备份，kafka允许producer等待确认通过配置，可实现直到所有的replication完成复制才算写入成功，这样可保证数据的可用性。
Kafka认真对待存储，并允许client自行控制读取位置，你可以认为kafka是一种特殊的文件系统，它能够提供高性能、低延迟、高可用的日志提交存储。
kafka可以存储数据量远大于oracle，只是没有清理的必要，因为存储的数据是磁盘存储的，磁盘是廉价的。如果数据量真的很大，可以考虑清理，清理是滚动清理（即保留多久的数据），比如一周清理一次（rotension配置）。kafka可以承载的量很大，比如几十个T，因为是硬盘存储。
日志聚合
日志系统一般需要如下功能：日志的收集（filebeat）、清洗(logstash)、聚合(es)、存储(es)、展示(kibana)。
Kafka常用来替代其他日志聚合解决方案。和Scribe、 Flume相比，Kafka提供同样好的性能、更健壮的堆积保障、更低的端到端延迟。日志会落地，导致kafka做日志聚合更昂贵。
kafka可实现日志的清洗(需要编码)、聚合(可靠但昂贵)、存储。
ELK是现在比较流行的日志系统。在kafka的配合下才是更成熟的方案， kafka在ELK技术栈中，主要起到buffer的作用，必要时可进行日志的汇流。

1、现在做日志整合多用ELK，logstash对日志解析需要消耗很大内存，云主机不堪负重。filebeat只负责读取日志，然后给logstash。filebeat消耗内存很低，是低侵入性的。

2、当日志生成很快，logstash无法支撑，所以需要添加kafka

跟踪网站活动
kafka的最初始作用就是将用户行为跟踪管道重构为一组实时发布-订阅源。把网站活动(浏览网页、搜索或其他的用户操作)发布到中心topics中，每种活动类型对应一个topic。基于这些订阅源，能够实现一系列用例，如实时处理、实时监视、批量地将Kafka的数据加载到Hadoop或离线数据仓库系统，进行离线数据处理并生成报告。
每个用户浏览网页时都生成了许多活动信息,因此活动跟踪的数据量通常非常大。(Kafka实际应用）
流处理
Kafka社区认为仅仅提供数据生产、消费机制是不够的，他们还要提供流数据实时处理机制，从0.10.0.0开始，Kafka通过提供Streams API来提供轻量，但功能强大的流处理。实际上就是Streams API帮助解决流引用中一些棘手的问题，比如：处理无序的数据，代码变化后再次处理数据，进行有状态的流式计算。
Streams API的流处理包含多个阶段，从input topics消费数据，做各种处理，将结果写入到目标topic, Streams API基于kafka提供的核心原语构建，它使用kafka consumer、 producer来输入、输出，用Kafka来做状态存储。
流处理框架: flink、spark streaming、Storm、Samza才是正统的流处理框架， Kafka在流处理中更多的是扮演流存储的角色。