关键概念介绍
topic
以下是kafka的逻辑结构图: 每个topic也就是自定义的一个队列，producer往队列中放消息，consumer从队列中取消息，topic之间相互独立。
broker
与上图对应的是kafka的物理结构图：每个broker通常就是一台物理机器，在上面运行kafka server的一个实例，所有这些broker实例组成kafka的服务器集群。
每个broker会给自己分配一个唯一的broker id。broker集群是通过zookeeper集群来管理的。每个broker都会注册到zookeeper上，有某个机器挂了，有新的机器加入，zookeeper都会收到通知。
在0.9.0中，producer/consumer已经不会依赖Zookeeper来获取集群的配置信息，而是通过任意一个broker来获取整个集群的配置信息。如下图所示：只有服务端依赖zk，客户端不依赖zk。
partition
kafka的topic，在每个机器上，是用文件存储的。而这些文件呢，会分目录。partition就是文件的目录。比如一个topic叫abc，分了10个partion，则在机器的目录上，就是：
abc_0
abc_1
abc_2
abc_3
…
abc_9
然后每个目录里面，存放了一堆消息文件，消息是顺序append log方式存储的。关于这个，后面会详细阐述。
replica/leader/follower
每个topic的partion的所有消息，都不是只存1份，而是在多个broker上冗余存储，从而提高系统的可靠性。这多台机器就叫一个replica集合。
在这个replica集合中，需要选出1个leader，剩下的是follower。也就是master/slave。
发送消息的时候，只会发送给leader，然后leader再把消息同步给followers（以pull的方式，followers去leader上pull，而不是leader push给followers)。
那这里面就有一个问题：leader收到消息之后，是直接返回给producer呢，还是等所有followers都写完消息之后，再返回？ 关于这个，后面会相信阐述。
关键点：这里replica/leader/follower都是逻辑概念，并且是相对”partion”来讲的，而不是”topic”。也就说，同一个topic的不同partion，对于的replica集合可以是不一样的。
比如
“abc-0” <1,3,5> //abc_0的replica集合是borker 1, 3, 5， leader是1， follower是3, 5
“abc-1” <1,3,7> //abc_1的replica集合是broker 1, 3, 7，leader是1, follower是3, 7
“abc_2” < 3,7,9>
“abc_3” <1,7,9>
“abc_4” <1,3,5>
消息队列的各种策略和语义
对于消息队列的使用，表面上看起来很简单，一端往里面放，一端从里面取。但就在这一放一取中，存在着诸多策略。
Producer的策略
是否ACK
所谓ACK，是指服务器收到消息之后，是存下来之后，再给客户端返回，还是直接返回。很显然，是否ACK，是影响性能的一个重要指标。在kafka中，request.required.acks有3个取值，分别对应3种策略：
request.required.acks
//0: 不等服务器ack就返回了，性能最高，可能丢数据
//1. leader确认消息存下来了，再返回
//all: leader和当前ISR中所有replica都确认消息存下来了，再返回（这种方式最可靠）
备注：在0.9.0以前的版本，是用-1表示all
同步发送 vs 异步发送
所谓异步发送，就是指客户端有个本地缓冲区，消息先存放到本地缓冲区，然后有后台线程来发送。
在0.8.2和0.8.2之前的版本中，同步发送和异步发送是分开实现的，用的Scala语言。从0.8.2开始，引入了1套新的Java版的client api。在0.9及其以后中，同步实际上是用异步间接实现的：
Consumer的策略
Push vs Pull
所有的消息队列都要面对一个问题，是broker把消息Push给消费者呢，还是消费者主动去broker Pull消息？
kafka选择了pull的方式，为什么呢？ 因为pull的方式更灵活：消息发送频率应该如何，消息是否可以延迟然后batch发送，这些信息只有消费者自己最清楚！
因此把控制权交给消费者，消费者自己控制消费的速率，当消费者处理消息很慢时，它可以选择减缓消费速率；当处理消息很快时，它可以选择加快消费速率。而在push的方式下，要实现这种灵活的控制策略，就需要额外的协议，让消费者告诉broker，要减缓还是加快消费速率，这增加了实现的复杂性。
另外pull的方式下，消费者可以很容易的自适应控制消息是batch的发送，还是最低限度的减少延迟，每来1个就发送1个。
消费的confirm
在消费端，所有消息队列都要解决的一个问题就是“消费确认问题”：消费者拿到一个消息，然后处理这个消息的时候挂了，如果这个时候broker认为这个消息已经消费了，那这条消息就丢失了。
一个解决办法就是，消费者在消费完之后，再往broker发个confirm消息。broker收到confirm消息之后，再把消息删除。
要实现这个，broker就要维护每个消息的状态，已发送/已消费，很显然，这会增大broker的实现难度。同时，这还有另外一个问题，就是消费者消费完消息，发送confirm的时候，挂了。这个时候会出现重复消费的问题。
kafka没有直接解决这个问题，而是引入offset回退机制，变相解决了这个问题。在kafka里面，消息会存放一个星期，才会被删除。并且在一个partion里面，消息是按序号递增的顺序存放的，因此消费者可以回退到某一个历史的offset，进行重新消费。
当然，对于重复消费的问题，需要消费者去解决。
broker的策略
消息的顺序问题
在某些业务场景下，需要消息的顺序不能乱：发送顺序和消费顺序要严格一致。而在kafka中，同一个topic，被分成了多个partition，这多个partition之间是互相独立的。
之所以要分成多个partition，是为了提高并发度，多个partition并行的进行发送/消费，但这却没有办法保证消息的顺序问题。
一个解决办法是，一个topic只用一个partition，但这样很显然限制了灵活性。
还有一个办法就是，所有发送的消息，用同一个key，这样同样的key会落在一个partition里面。