categories: MQ
Kafka学习笔记
Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
主要应用场景是：日志收集系统和消息系统。
Kafka主要设计目标如下：
以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
同时支持离线数据处理和实时数据处理。支持在线水平扩展
有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅
模式。Kafka就是一种发布-订阅模式。
Kafka只有消息的拉取，没有推送，可以通过轮询实现消息的推送。
Kafka在一个或多个可以跨越多个数据中心的服务器上作为集群运行。
Kafka集群中按照主题分类管理，一个主题可以有多个分区，一个分区可以有多个副本分区。
每个记录由一个键，一个值和一个时间戳组成
Kafka优势
- 高吞吐量：单机每秒处理几十上百万的消息量。即使存储了许多TB的消息，它也保持稳定的性
能。
高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。
持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防止数据丢失。
- 1 零拷贝
- 2 顺序读，顺序写
- 3 利用Linux的页缓存
分布式系统，易于向外扩展。所有的Producer、Broker和Consumer都会有多个，均为分布
式的。无需停机即可扩展机器。多个Producer、Consumer可能是不同的应用。
可靠性 - Kafka是分布式，分区，复制和容错的。
客户端状态维护：消息被处理的状态是在Consumer端维护，而不是由server端维护。当失
败时能自动平衡。
支持online和offline的场景。
支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言。
核心概念
Producer
生产者创建消息。
该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追
加到当前用于追加数据的 segment 文件中。
一般情况下，一个消息会被发布到一个特定的主题上。
默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现
的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的
消息会被写到同一个分区上。
- 生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。
Consumer
消费者读取消息。
消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。
Broker
一个独立的Kafka 服务器被称为broker。
broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。
如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。
在集群中，一个分区从属于一个broker，该broker 被称为分区的首领。