目录
[Kafka 由来](#Kafka 由来)
[Kafka 特性](#Kafka 特性)
[Kafka 使用场景](#Kafka 使用场景)
[Kafka 复制备份](#Kafka 复制备份)
[2、Kafka 架构](#2、Kafka 架构)
[Consumer Group](#Consumer Group)
1、概念介绍
Kafka 由来
Kafka 是最初由 Linkedin 公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于 zookeeper 协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于 hadoop 的批处理系统、低延迟的实时系统、storm/Spark 流式处理引擎，web/nginx 日志、访问日志，消息服务等等，生产者往队列里写消息，消费者从队列里取消息进行业务逻辑。一般在架构设计中起到解耦、削峰、异步处理的作用。用 scala 语言编写，Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。
ZooKeeper
Kafka将元数据信息保存在Zookeeper中，消费者发送给Topic本身的数据是不会发到Zk上。
1、kafka使用zookeeper来实现动态的集群扩展，broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新，我们不需要更改客户端（producer和consumer）的配置。
2、而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)。
3、Broker端使用zookeeper来注册broker信息，以及监测partition leader存活性
4、Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。
5、Zookeeper和Producer没有建立关系，只和Brokers、Consumers建立关系以实现负载均衡，即同一个Consumer Group中的Consumers可以实现负载均衡
Kafka 特性
1、高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition，consumer group 对partition进行消费操作。
2、可扩展性：kafka集群支持热扩展
3、持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
4、容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
5、高并发：支持数千个客户端同时读写
Kafka 使用场景
1、日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
2、消息系统：解耦和生产者和消费者、缓存消息等。
3、用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
4、运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
5、流式处理：比如spark streaming和storm
Kafka 复制备份
kafka将每个partition数据复制到多个broker上,任何一个partition有一个leader和多个follower(可以没有)；备份的个数可以通过broker配置文件来设定。
leader处理所有的read-write请求,follower需要和leader保持同步。Follower和consumer一样,消费消息并保存在本地日志中；leader负责跟踪所有的follower状态,如果follower"落后"太多或者失效,leader将会把它从replicas同步列表中删除。
当所有的follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它。即使只有一个replicas实例存活,仍然可以保证消息的正常发送和接收,只要zookeeper集群存活即可。(不同于其他分布式存储,比如hbase需要"多数派"存活才行)
当leader失效时，需在followers中选取出新的leader,可能此时follower落后于leader,因此需要选择一个"up-to-date"的follower。选择follower时需要兼顾一个问题,就是新leader server上已经承载的partition leader的个数,如果一个server上有过多的partition leader,意味着此server将承受着更多的IO压力。在选举新leader,需要考虑到"负载均衡"。
2、Kafka 架构
Broker
一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个topic；
Topic
Topic 即主题，通过对消息指定主题可以将消息分类，消费者可以只关注自己需要的 Topic 中的消息。
Producer
即生产者，向 Kafka 集群发送消息，在发送消息之前，会对消息进行分类，即 Topic, 同时 Producer 也能决定将此消息归属于哪个 partition。
Partition
Topic 在逻辑上可以被认为是一个 queue，每条消费都必须指定它的 Topic，一个Topic 可以认为是一类消息。为了使得 Kafka 的吞吐率可以线性提高，物理上把Topic 分成一个或多个 Partition，每个Partition 在物理上对应一个文件夹，该文件夹下存储这个 Partition 的所有消息和索引文件。
创建一个 topic 时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka 在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中。如果 partition 规则设置的合理，所有消息可以均匀分布到不同的 partition 里，这样就实现了水平扩展。
每个 Partition 中的消息都是有序的，任何发布到此 partition 的消息都会被直接追加到 append log 文件的尾部，其中每条消息在文件中的位置称为 offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。每条消息都被append到partition中，是顺序写磁盘，因此效率非常高。其组织结构如下图所示：
kafka 和 JMS（Java Message Service）实现(activeMQ)不同的是：即使消息被消费，消息仍然不会被立即删除。日志文件将会根据 broker 中的配置要求,保留一定的时间之后删除;比如 log 文件保留 2 天,那么两天后,文件会被清除,无论其中的消息是否被消费.kafka 通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘 IO 开支。
Consumers
Consumer 即消费者，消费者通过与 kafka 集群建立长连接的方式，不断地从集群中拉取消息，然后可以对这些消息进行处理。
Consumer Group
发布消息通常有两种模式：
- 队列模式（queuing，即单播）
- 发布-订阅模式(publish-subscribe，即广播)
kafka通过引入consumer组(consumer group)来同时支持这两种模型。
各个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，如果consumer group中的某个consumer失效那么其消费的partitions将会有其他consumer自动接管，如果一个消息可以被多个consumer消费的话，那么这些consumer必须在不同的组。
如果所有的consumer都具有不同的group，那这就是"发布-订阅"，消息将会广播给所有的消费者。
如果所有的consumer都具有相同的group，那这就是队列模式，消息将会在consumers之间负载均衡。
通过分区的概念，Kafka可以在多个consumer组并发的情况下提供较好的有序性和负载均衡。将每个分区只分发给一个consumer组，这样一个分区就只被这个组的一个consumer消费，就可以顺序的消费这个分区的消息。因为有多个分区，依然可以在多个consumer之间进行负载均衡。注意同一个Consumer Group 中consumer的数量不能多于分区的数量，否则将意味着某些consumer将无法得到消息。
对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,由consumer来控制;当consumer正常消费消息时,offset将会"线性"的向前驱动,即消息将依次顺序被消费，事实上consumer可以使用任意顺序消费消息,它只需要将offset重置为任意值
Distribution
每个分区在Kafka集群的若干服务中都有副本，这样这些持有副本的服务可以共同处理数据和请求，副本数量是可以配置的。副本使Kafka具备了容错能力，以提高可用性。
每个分区都由一个服务器作为"leader"，零或若干服务器作为"followers",leader负责处理消息的读和写，followers则去复制leader。如果leader down了，followers中的一台则会自动成为leader。集群中的每个服务器都会同时扮演两个角色：作为它所持有的一部分分区的leader，同时作为其他分区的followers，这样集群就会具有较好的负载均衡。