kafka具体解释四：Kafka的设计思想、理念

版权声明：本文为博主原创文章，未经博主同意不得转载。 https://blog.csdn.net/suifeng3051/article/details/37606001

     本节主要从总体角度介绍Kafka的设计思想，当中的每一个理念都能够深入研究。以后我可能会发专题文章做深入介绍，在这里仅仅做较概括的描写叙述以便大家更好的理解Kafka的独特之处。

本节主要涉及到例如以下主要内容：

• Kafka设计基本思想
• Kafka中的数据压缩
• Kafka消息转运过程中的可靠性
• Kafka集群镜像复制
• Kafka 备份机制

一、kafka由来

     因为对JMS日常管理的过度开支和传统JMS可扩展性方面的局限，LinkedIn(www.linkedin.com)开发了Kafka以满足他们对实时数据流的监控以及对CPU、IO利用率等指标的高要求。

在Linkedin开发Kafka之初，把关注重点集中在了这几个方面：

• 为生产者和消费者提供一个通用的API
• 消息的持久化
• 高吞吐量。能够满足百万级别消息处理
• 对分布式和高扩展性的支持

二、基本思想

     一个最主要的架构是生产者公布一个消息到Kafka的一个主题（topic），这个主题即是由扮演KafkaServer角色的broker提供，消费者订阅这个主题，然后从中获取消息，以下这个图能够更直观的描写叙述这个场景：

     

     上图所看到的的架构分为三部分：Producers、Kafka broker、consumers，它们分别执行在不同的节点。

     以下概括介绍一下Kafka一些设计思想：

     consumer group：各个consumer能够组成一个组，每一个消息仅仅能被组中的一个consumer消费。假设一个消息能够被多个consumer消费的话，那么这些consumer必须在不同的组。

     消息状态：在Kafka中。消息的状态被保存在consumer中。broker不会关心哪个消息被消费了被谁消费了，仅仅记录一个offset值（指向partition中下一个要被消费的消息位置）。这就意味着假设consumer处理不好的话，broker上的一个消息可能会被消费多次。

     消息持久化：Kafka中会把消息持久化到本地文件系统中。而且保持极高的效率。

     消息有效期：Kafka会长久保留当中的消息，以便consumer能够多次消费，当然当中非常多细节是可配置的。

     批量发送：Kafka支持以消息集合为单位进行批量发送，以提高push效率。

     push-and-pull:Kafka中的Producer和consumer採用的是push-and-pull模式，即Producer仅仅管向broker push消息，consumer仅仅管从broker pull消息，两者对消息的生产和消费是异步的。

     Kafka集群中broker之间的关系：不是主从关系，各个broker在集群中地位一样，我们能够随意的添加或删除不论什么一个broker节点。

     负载均衡方面：Kafka提供了一个 metadata API来管理broker之间的负载（对Kafka0.8.x而言。对于0.7.x主要靠zookeeper来实现负载均衡）。

     同步异步：Producer採用异步push方式。极大提高Kafka系统的吞吐率（能够通过參数控制是採用同步还是异步方式）。

     分区机制partition：Kafka的broker端支持消息分区，Producer能够决定把消息发到哪个分区，在一个分区中消息的顺序就是Producer发送消息的顺序。一个主题中能够有多个分区。详细分区的数量是可配置的。分区的意义非常重大。后面的内容会逐渐体现。

     离线数据装载：Kafka因为对可拓展的数据持久化的支持。它也非常适合向Hadoop或者数据仓库中进行数据装载。

     插件支持：如今不少活跃的社区已经开发出不少插件来拓展Kafka的功能，如用来配合Storm、Hadoop、flume相关的插件。

三、消息压缩

     我们上面已经知道了Kafka支持以集合为单位发送消息，在此基础上，Kafka还支持对消息集合进行压缩，Producer端能够通过GZIP或Snappy格式对消息集合进行压缩。Producer端进行压缩之后，在Consumer端需进行解压。

压缩的优点就是降低传输的数据量，减轻对网络传输的压力，在对大数据处理上。瓶颈往往体如今网络上而不是CPU（压缩和解压会耗掉部分CPU资源）。

     那么怎样区分消息是压缩的还是未压缩的呢，Kafka在消息头部加入了一个描写叙述压缩属性字节，这个字节的后两位表示消息的压缩採用的编码，假设后两位为0，则表示消息未被压缩。

     详细细节请參考：  https://cwiki.apache.org/confluence/display/KAFKA/Compression 

四、消息转运过程中的可靠性

     在消息系统中，保证消息在生产和消费过程中的可靠性是十分重要的。在实际消息传递过程中，可能会出现例如以下三中情况：

1. 一个消息发送失败
2. 一个消息被发送多次
3. 最理想的情况：exactly-once ,一个消息发送成功且仅发送了一次                   

    有很多系统声称它们实现了exactly-once，可是它们事实上忽略了生产者或消费者在生产和消费过程中有可能失败的情况。比方尽管一个Producer成功发送一个消息，可是消息在发送途中丢失。或者成功发送到broker，也被consumer成功取走，可是这个consumer在处理取过来的消息时失败了。

     从Producer端看：Kafka是这么处理的，当一个消息被发送后，Producer会等待broker成功接收到消息的反馈（可通过參数控制等待时间），假设消息在途中丢失或是当中一个broker挂掉，Producer会又一次发送（我们知道Kafka有备份机制，能够通过參数控制是否等待全部备份节点都收到消息）。

     从Consumer端看：前面讲到过partition，broker端记录了partition中的一个offset值，这个值指向Consumer下一个即将消费message。当Consumer收到了消息。但却在处理过程中挂掉。此时Consumer能够通过这个offset值又一次找到上一个消息再进行处理。Consumer还有权限控制这个offset值。对持久化到broker端的消息做随意处理。

     

五、mirror一个Kafka集群

     关于Kafka集群的mirror，參考以下这幅图：

     

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc3VpZmVuZzMwNTE=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="" />

     详细细节请參考：https://cwiki.apache.org/confluence/display/KAFKA/Kafka+mirroring

     

六、备份机制

          备份机制是Kafka0.8版本号的新特性，备份机制的出现大大提高了Kafka集群的可靠性、稳定性。有了备份机制后，Kafka同意集群中的节点挂掉后而不影响整个集群工作。一个备份数量为n的集群同意n-1个节点失败。在全部备份节点中。有一个节点作为lead节点，这个节点保存了其他备份节点列表，并维持各个备份间的状体同步。以下这幅图解释了Kafka的备份机制：

     

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc3VpZmVuZzMwNTE=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="" />

     详细细节请參考：https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Replication
 

     想更深入的了解Kafka请參阅我的还有一篇文章：《Kafka设计与原理详细解释》

   

   转发请说明出处，原文链接：http://blog.csdn.net/suifeng3051/article/details/37606001