[读文档] Kafka的一点笔记

在职跳槽，学习系统设计，读点论文和文档，自己记点笔记。只选取了一些我认为可能对面试有用的知识点和可以在系统设计题复用的component。完全不涉及实战经验，配置，具体实现和调优等等。

previous post：
Amazon Dynamo笔记：https://www.1point3acres.com/bbs ... 5467&extra=page%3D1
==========
参考：http://orchome.com/295

Kafka，消息队列中以吞吐量著称，功能上则相对简单，比较适合数据量很大，处理不复杂，也能容忍一定数据丢失的情况。如网站流量追踪，日志聚合，事件采集等等。

基本功能：
Producer针对topic发送消息，每个Topic有多个partition，分布在各个Broker（机器）上。
Consumer Group包含多个Consumer，Group可以订阅Topic，对每一个topic，他的每个partition中的消息会发送到Group中的一个特定Consumer上，不会出现一个partition被Group中多个Consumer接收的情况。
当所有Consumer都在一个group：每个消息只会Consume一次
当所有Consumer各自在一个group：pubsub模式，每个消息会发送给所在topic的所有订阅consumer。
消息都直接持久化在磁盘上，可以适用于both离线操作或在线流处理。

消费者：Pull from Broker：消费者采用pull比较常见，因为如果broker push不容易考虑消费者的能力，有可能会拒绝服务。pull的问题是如果暂时没有数据会轮询，这时我们可以用long pull。有数据的时候也可以用long pull，积累一定量以后一起返回。Consumer metadata：由消费者自己保持和控制，而不是broker。这样的劣势是broker没法通过观察是否所有消费者都已经消费消息来决定是否可以删除，但省去了很多track message status的麻烦（new，sent，acked），也不会出现消费者应答失败而重复发送（但会有其他情况导致发送多次）。同时broker改用ttl决定消息是否删除，不管是否有被消费。另一个优势是消费者可以自行决定回到之前的position重新消费某些消息。


生产者：
客户端控制发送到哪个partition，可以随机，也可以指定partition method，比如根据user id进行partition，同一个user的数据就都在一个partition并保证有序。

消息传递保障：
producer端：
最少一次：如果producer发送失败（没有得到保存到n个replica的应答），则重新发送
刚好一次：在最少一次的基础上，对每个producer有一个ID和序列号，针对他们进行去重。 以上两种都会降低吞吐量，来保证数据不丢失。
最多一次：只发送一次，不管应答，快速，适用于能够容忍一定数据丢失的场景。
consumer端：
最少一次：先读数据，处理数据，再commit offset
最多一次：读数据，commit offset，再来处理
刚好一次：利用消息的primary key来去重。

replica：
每一个分区可以存在多个replica分布在不同broker上，其中一个leader处理所有读写，follower只负责备份和恢复。
利用zookeeper monitor failover。Producer可以选择需要得到多少replica的ack才认为写入成功。

太感谢楼主分享这么好的内容了。大家多讨论呀。要再讨论下Redis的一些feature和use case么？😄！

很不错，多谢分享

楼主应该自建一个博客，放在其他平台不够可靠。

多谢，很有用

很有用的信息！

正在学kafka，感谢楼主分享