1. Topics
Kafka 只支持基于 Topic 的发布/订阅模式,它并没有实现 JMS 规范。
与传统的消息系统不同,Kafka系统中存储的消息没有明确的消息Id。
消息通过日志中的逻辑偏移量来公开。这样就避免了维护配套密集寻址,用于映射消息ID到实际消息地址的随机存取索引结构的开销。消息ID是增量的,但不连续。要计算下一消息的ID,可以在其逻辑偏移的基础上加上当前消息的长度。
消费者始终从特定分区顺序地获取消息,如果消费者知道特定消息的偏移量,也就说明消费者已经消费了之前的所有消息。消费者向代理发出异步拉请求,准备字节缓冲区用于消费。每个异步拉请求都包含要消费的消息偏移量。Kafka利用sendfile API高效地从代理的日志段文件中分发字节给消费者。
参考文献:
1. http://www.infoq.com/cn/articles/apache-kafka/
2. http://www.cnblogs.com/likehua/p/3999538.html
Kafka 只支持基于 Topic 的发布/订阅模式,它并没有实现 JMS 规范。
一个 Topic 可以认为是一类消息,每个 Topic 被分成多个 partitions,每个 partition 是一个有序的队列,在物理存储层面,每个 partition 由多个日志文件组成。每条发布到 partition 的消息都会以 append 方式写到日志文件的尾部,每条消息在文件中的位置称为 offset,offset 是一个 long 型数字,它唯一的标记一条消息。
2. Broker
Broker 不维护 Producer 和 Consumer 的状态信息,这些信息由 Zookeeper 保存,即 Broker 本身是无状态的。
一个 Topic 的多个 partitions 被分布在 Kafka 集群中的多个 Broker 上,每个 Broker 负责 partitions 中消息的读写操作。
Broker 不维护 Producer 和 Consumer 的状态信息,这些信息由 Zookeeper 保存,即 Broker 本身是无状态的。
一个 Topic 的多个 partitions 被分布在 Kafka 集群中的多个 Broker 上,每个 Broker 负责 partitions 中消息的读写操作。
此外,Kafka 还可以配置 partitions 的副本个数(replicas),将 partition 备份到多台机器上,提高可用性。
基于 partitions 的副本方案,意味着需要对多个备份进行调度,每个 partition 都有一个 leader 负责所有的读写操作,如果 leader 失效,那么会有一个 follower成为新的 leader 来接管工作。follower 本身不接受用户请求,只是和 leader 进行消息同步。
有多少个 partitions 就有多少个 leader,Kafka 会把 leader 均衡地分布在每个 Broker 实例上,来确保整体的性能稳定。
3. Producers 生产者
Producer 将消息发布到指定的 Topic 中,同时 Producer 也能决定消息归属于哪个 partition,比如基于 round-robin 方式或者通过其他的一些算法等。
4. Consumers 消费者
每个 Consumer 属于一个 Consumer Group;一个 Consumer Group 可以有多个 Consumers。
发送到 Topic 的消息,只会被订阅此 Topic 的每个 Consumer Group 中的一个 Consumer 消费,因此可以认为一个 Consumer Group 是一个“订阅者”。
如果所有的 Consumer 都具有相同的 Consumer Group,消息将会在所有的 Consumers 之间负载均衡,跟 Queue 特性很像。
如果所有的 Consumer 都具有不相同的 Consumer Group,消息将会广播给所有的 Consumers,跟 Topic 特性一样。
Consumer 需要保存已消费消息的 offset。
再说的仔细些,一个 Topic 中的每个 partition,只会被一个“订阅者”(一个 Consumer Group)中的一个 Consumer 消费;不过,一个 Consumer 可以消费多个 partitions 中的消息。
Kafka 的设计原理决定:对于一个 Topic,同一个 Consumer Group 中不能有多于 partitions 个数的 Consumer 同时消费,否则意味着某些 Consumer 将无法得到消息。
Kafka只能保证一个 partition 中的消息被某个 Consumer 消费时是按顺序消费的。但从 Topic 角度来说,消息仍然不是有序消费的.
Kafka 保证
(1)发送到 partitions 中的消息将会按照它接收的顺序追加到日志中。
(2)对于 Consumer 而言,它们消费消息的顺序和日志中消息顺序一致。
(3)如果 Topic 的 replicationfactor=N,那么允许 N-1 个 broker 实例失效。
5. 存储
Kafka的存储布局非常简单。话题的每个分区对应一个逻辑日志。物理上,一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区,代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后,段文件真正写入磁盘中。写入完成后,消息公开给消费者。与传统的消息系统不同,Kafka系统中存储的消息没有明确的消息Id。
消息通过日志中的逻辑偏移量来公开。这样就避免了维护配套密集寻址,用于映射消息ID到实际消息地址的随机存取索引结构的开销。消息ID是增量的,但不连续。要计算下一消息的ID,可以在其逻辑偏移的基础上加上当前消息的长度。
消费者始终从特定分区顺序地获取消息,如果消费者知道特定消息的偏移量,也就说明消费者已经消费了之前的所有消息。消费者向代理发出异步拉请求,准备字节缓冲区用于消费。每个异步拉请求都包含要消费的消息偏移量。Kafka利用sendfile API高效地从代理的日志段文件中分发字节给消费者。
1. http://www.infoq.com/cn/articles/apache-kafka/
2. http://www.cnblogs.com/likehua/p/3999538.html
没有评论:
发表评论