ApacheKafka?是一个分布式流处理平台。原本开发自LinkedIn，用作LinkedIn的活动流（ActivityStream）和运营数据处理管道（Pipeline）的基础。
为什么叫“流处理平台”？
Kafka具有消息系统的能力，也有实时流式数据处理分析能力，只是我们更多的偏向于把他当做消息队列系统来使用。
首先是一些概念1，Kafka作为一个集群，运行在一台或者多台服务器上.
2，Kafka通过topic对存储的流数据进行分类。
，每条记录中包含一个key，一个value和一个timestamp（时间戳）。
4，Kafka使用Avro作为消息序列化框架
主要设计目标1，以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能；
2，高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒K条以上消息的传输；
，支持KafkaServer间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输；
4，同时支持离线数据处理和实时数据处理；
5，支持在线水平扩展。
为何使用消息系统解耦。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。2，冗余。有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
，扩展性。因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
4，削峰填谷。在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5，可恢复性。系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6，顺序保证。在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
7，缓冲。在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
异步通信。很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。kafka使用场景：1，分布式消息。更好的吞吐量，具有复制和容错的功能，也有强大的持久性；
2，监控数据。涉及到分布式应用程序中汇总数据，然后生成可操作的集中数据源。例如：cannal模拟mysql从库收到binlog，cannal-client接收sql后发送到kafka，业务方订阅kafkatopic即可。
，日志聚合，日志收集中心。例如：分布式项目的日志发送到kafka，kafka消费者发送到Logstash，再推送到ElasticSearch，最后使用Kibana图形化界面访问（ELK）。
4，流处理。许多Kafka用户通过管道来处理数据，有多个阶段：从topic中消费原始输入数据，然后聚合，修饰或通过其他方式转化为新的topic，以供进一步消费或处理。在很多领域，如股市走向分析、气象数据测控、网站用户行为分析，由于数据产生快、实时性强且量大，您很难统一采集这些数据并将其入库存储后再做处理，这便导致传统的数据处理架构不能满足需求。与传统架构不同，消息队列Kafka版以及Storm、Samza、Spark等流计算引擎的出现，就是为了更好地解决这类数据在处理过程中遇到的问题，流计算模型能实现在数据流动的过程中对数据进行实时地捕捉和处理，并根据业务需求进行计算分析，最终把结果保存或者分发给需要的组件。
基本概念Kafka拓扑结构一个典型的Kafka集群中包含若干Producer（可以是web前端产生的PageView，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干ConsumerGroup，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在ConsumerGroup发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。
Kafka基本元素Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker
Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
Partition：Parition是物理上的概念，每个Topic包含一个或多个Partition.
Producer：负责发布消息到Kafkabroker
Consumer：消息消费者，向Kafkabroker读取消息的客户端。
ConsumerGroup：每个Consumer属于一个特定的ConsumerGroup（可为每个Consumer指定groupname，若不指定groupname则属于默认的group）。
Kafka有四个核心的API:1，TheProducerAPI允许一个应用程序发布一串流式的数据到一个或者多个Kafkatopic。
2，TheConsumerAPI允许一个应用程序订阅一个或多个topic，并且对发布给他们的流式数据进行处理。
，TheStreamsAPI允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换。
4，TheConnectorAPI允许构建并运行可重用的生产者或者消费者，将Kafkatopics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表（table）的所有变更内容。如：