1、Kafka简介

转载自：http://blog.csdn.net/gongxinju/article/details/72622204

1.1、什么是kafka？

Kafka是由linkedin开发的一个分布式的(发布-订阅)消息系统，使用Scala编写，它以可水平扩展和高吞吐率而被广泛使用。 

1.2、Kafka创建背景

当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下几个挑战：

• 如何收集这些巨大的信息

• 如何分析它

如何及时做到如上两点 
以上几个挑战形成了一个业务需求模型，即生产者生产（produce）各种信息，消费者消费（consume）（处理分析）这些信息，而在生产者与消费者之间，需要一个沟通两者的桥梁-消息系统。从一个微观层面来说，这种需求也可理解为不同的系统之间如何传递消息。 

1.3、使用场景

一、Message 
对于一些常规的消息系统，kafka是个不错的选择；partions/replication和容错，可以是kafka具有良好的扩展性和性能优势。不过和JMS比，没有“事务性”“消息确认机制”，”消息分组”等企业级特性。

二、Websit 
kafka可以作为”网站活性跟踪”的最佳工具；可以将网页/用户操作信息发送到kafka中。

三、Log Aggregation 
kafka的特性决定它非常适合作为”日志收集”，app可以将操作日志发送到kafka集群中，而不是保存在本地或者DB中。consumer端可以存储和分析日志。

---

1.4、kafka主要设计目标

以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输同时支持离线数据处理和实时数据处理。

1.5、为何要用消息队列 (kafka)

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

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

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

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

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

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

1.6、消息队列对比-ActiveMQ、RabbitMQ、Kafka

ActiveMQ 
重量级的老牌儿MQ，诞生自Java生态，功能完备，相关的介绍很多，这里不再赘述。

RabbitMQ 
同样是老牌儿MQ，基于erlang实现，语言无关，功能完备，诞生自金融领域。

Kafka 
MQ中的后起之秀，在很多场景下都超越了前辈，诞生自Hadoop生态，在大数据的支持方面，目前无人能出其右。

横向对比 

1.7、Kafka组件、术语

一、Topics/logs 
一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)，每个partition在储存层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset(偏移量)，offset为一个long整型数字，它是唯一标记一条消息。Kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。

在kafka中，即使消息被消费，消息仍然不会被立即删除。日志文件将会根据broker中的配置要求，保留一定的时间之后删除；比如log文件保留2天，那么两天后，文件会被清除，无论其中的消息是否被消费。Kafka通过这种简单的手段，来释放磁盘空间，以及减少消息消费之后对文件内容改动的磁盘IO开支。

对于consumer而言，它需要保存消费消息的offset，对于offset的保存和使用，由consumer来控制；当consumer正常消费消息时，offset将会“线性”的向前驱动，即消息将依次顺序被消费。事实上consumer可以使用任意顺序消费消息，它只需要将offset重置为任意值，Offset保存在zookeeper中。

Kafka集群几乎不需要维护任何consumer和producer状态消息，这些信息由zookeeper保存；因此producer和consumer的客户端实现非常轻量级，它们可以随意离开，而不会对集群造成额外的影响。 
Partitions的设计目的有多个。最根本原因是kafka基于文件储存。通过分区，可以将日志内容分散到多个server上，来避免文件尺寸达到单机磁盘的上限， 
每个partitions都会被当前server保存；可以将一个topic切分多任意多个partitions来保存消息。此外越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力。

二、Distribution–partitions 
一个topic的多个partitions，被分布在kafka集群中的多个server上，每个server负责partitions中消息的 读写操作；此外kafka还可以配置partitions需要备份的个数(replicas)，每个partition将会被备份到多台机器上，以提高可用性。

基于replicated方案，那么就意味着需要对多个备份进行调度，每个partition都有一个server为“leader”；leader负责所有的读写操作，如果leader失效，那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进，同步消息即可。由此可见作为leader的server承载了全部的请求压力，因此从集群的整体考虑，有多少个partitions就意味着有多少个“leader”，kafka会将“leader”均衡的分散在每个实例上，来确保整体的性能稳定。

• 发送到partitions中的消息将会按照它接收的顺序追加到日志中。
• 对于消费者而言，它们消费消息的顺序和日志顺序一致。
• 如果topic的“replication factor”为n，那么允许n-1个kafka实例失效。

三、Producers 
Producer将消息发布到指定的topic中，同时producer也能决定将此消息归属哪个partition；比如基于“round-robin”方式或者通过其他的一些算法等。

四、consumers 
每个consumser属于一个consumer group;反过来说，每个group中可以有多个consumer。发送到Topic的消息，只会被订阅此Topic的每个group中的一个consumer消费。 
如果所有的consumer都有不同的group，那这就是“发布-订阅”，消息将会广播给所有的消费者。 
在kafka中，一个partition中的消息只会被group中的一个consumer消费；每个group中的consumer消息消费相互独立；我们可以认为一个group是一个“订阅”者，一个Topic中的每个partions，只会被一个“订阅者”中的一个consumer消费，不过一个consumer可以消费多个partitions中的消息。kafka只能保证一个partition中的消息被某个consumer消费时，消息是顺序的。事实上，从Topic角度来说，消息仍不是有序的。 
kafka的设计原理决定，对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消费。 

五、Leader 
Partition中负责消息读写的节点;Leader是从Partition的节点中随机选取的。每个Partition都会在集中的其中一台服务器存在Leader。一个Topic如果有多个Partition，则会有多个Leader。

六、ReplicationFactor 
一个Partition中复制数据的所有节点,包括已经挂了的；数量不会超过集群中broker的数量

七、isr 
ReplicationFactor的子集,存活的且和Leader保持同步的节点;