Kafka原理基本组件

Kafka

一、Kafka是什么

         Kafka是一种高吞吐量的分布式发布--订阅消息系统。它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。

        

Kafka是一个分布式的流处理平台。

         kafka主要是作为一个分布式的、可分区的、具有副本数的日志服务系统,

                   具有高水平扩展性、高容错性、访问速度快、分布式等特性；

• 主要应用场景是

主要应用场景是：日志收集系统和分布式发布--订阅消息系统

1.kafka 应用场景

             A.日志收集

                  B.消息系统 解耦生产者和消费者、缓存消息。

                  C.用户活动跟踪: 就是我们在做的。

                  D.运营指标：生产各种操作的集中反馈。

                  E.流式处理：比如spark steaming

2.为什么需要消息队列（重要）

消息系统的核心作用就是三点：解耦，异步和并行

1. 解耦       在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

 

1. 冗余       有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。

 

（3）扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

 

（4）灵活性 & 峰值处理能力   在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

 

（5）可恢复性      当体系的一部分组件失效，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。

 

（6）送达保证    消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列即可。在此基础上，IronMQ提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据，每一个消息只能被处理一次。这之所以成为可能，是因为获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。

 

（7）顺序保证      在大多使用场景下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。IronMO保证消息通过FIFO（先进先出）的顺序来处理，因此消息在队列中的位置就是从队列中检索他们的位置。

 

1. 缓冲       在任何重要的系统中，都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行–写入队列的处理会尽可能的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。

 

1. 理解数据流   在一个分布式系统里，要得到一个关于用户操作会用多长时间及其原因的总体印象，是个巨大的挑战。消息队列通过消息被处理的频率，来方便的辅助确定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。

 

（10）异步通信    很多时候，你不想也不需要立即处理消息。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。

• Kafka核心组件

         Topic ：消息根据Topic进行归类

            Producer：发送消息者

            Consumer：消息接受者

            broker：每个kafka实例(server)

            Zookeeper：依赖集群保存meta信息。

            GroupConsmer：消费组的概念

Broker

            Kafka集群包含一个或多个服务器，这种服务器被称为broker。

一台kafka服务器就是一个broker。

一个集群由多个broker组成。

一个broker可以容纳多个topic。

Topic

            每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）。可以理解为一个队列。

Partition

            parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。

每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件。

为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，

一个topic可以分为多个partition，每个partition是一个有序的队列。

partition中的每条消息都会被分配一个有序的id（offset）。

kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition            间）的顺序。

Producer

            消息生产者，就是向kafka broker发消息的客户端。负责发布消息到Kafka broker

Consumer

            消息消费者，向kafka broker获取消息的客户端。

每个consumer属于一个特定的consumer group（可为每个consumer指定group name，若不指定group             name则属于默认的group）。

使用consumer highlevel API时，同一topic的一条消息只能被同一个consumer group内的一个consumer            消费，但多个consumer group可同时消费这一消息。

Consumer Group （CG）：

            这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。

Offset：

            kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然thefirstoffset就是00000000000.kafka