Kafka架构
一个典型的Kafka体系架构包括若干Producer（可以是服务器日志，业务数据，页面前端产生的page view等等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer（Group），以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。Producer使用push（推）模式将消息发布到broker，Consumer使用pull（拉）模式从broker订阅并消费消息。
- Topics（主题）：属于特定类别的消息流称为主题。数据存储在主题中。Topic相当于Queue。主题被拆分成分区。每个这样的分区包含不可变有序序列的消息。分区被实现为具有相等大小的一组分段文件。
- Partition（分区）：
- 一个Topic可以分成多个Partition，这是为了平行化处理。
- 每个Partition内部消息有序，其中每个消息都有一个offset序号。
- 一个Partition只对应一个Broker，一个Broker可以管理多个Partition。
- Partition offset（分区偏移）：每个分区消息具有称为 offset 的唯一序列标识。
- Replicas of partition（分区备份）：副本只是一个分区的备份。 副本从不读取或写入数据。 它们用于防止数据丢失。
- Brokers（经纪人）：
- 代理是负责维护发布数据的简单系统。每个代理可以每个主题具有零个或多个分区。假设，如果在一个主题和N个代理中有N个分区，每个代理将有一个分区。
- 假设在一个主题中有N个分区并且多于N个代理(n + m)，则第一个N代理将具有一个分区，并且下一个M代理将不具有用于该特定主题的任何分区。
- 假设在一个主题中有N个分区并且小于N个代理(n-m)，每个代理将在它们之间具有一个或多个分区共享。由于代理之间的负载分布不相等，不推荐使用此方案。
- Kafka Cluster（Kafka集群）：Kafka有多个代理被称为Kafka集群。可以扩展Kafka集群，无需停机。这些集群用于管理消息数据的持久性和复制。
- Producers（生产者）：生产者是发送给一个或多个Kafka主题的消息的发布者。生产者向Kafka经纪人发送数据。每当生产者将消息发布给代理时，代理只需将消息附加到最后一个段文件。实际上，该消息将被附加到分区。生产者还可以向他们选择的分区发送消息。
- Consumers（消费者）：Consumers从经纪人处读取数据。消费者订阅一个或多个主题，并通过从代理中提取数据来使用已发布的消息。
- Consumer自己维护消费到哪个offset
- 每个Consumer都有对应的group
- group内是queue消费模型：各个Consumer消费不同的partition，因此一个消息在group内只消费一次
- group间是publish-subscribe消费模型：各个group各自独立消费，互不影响，因此一个消息被每个group消费一次
Kafka高可用
kafka能保证HA的策略有：data replication和leader election。
Kafka中topic的每个partition有一个预写式的日志文件，虽然partition可以继续细分为若干个segment文件，但是对于上层应用来说可以将 partition看成最小的存储单元(一个有多个segment文件拼接的“巨型”文件)，每个partition都由一些列有序的、不可变的消息组成，这些消息被连续的追加到partition中。
在kafka0.8版本之后 ，为了提高消息的可靠性，Kafka每个topic的partition有N个副本(replicas)，其中N(大于等于1)是topic的复制因子(replica fator)的个数。这个时候每个 partition下面就有可能有多个 replica（replication机制，相当于是partition的副本但是有可能存储在其他的broker上）,但是这多个replica并不一定分布在一个broker上，而这时候为了更好的在replica之间复制数据，此时会选出一个leader，这个时候 producer会push消息到这个leader（leader机制），consumer也会从这个leader pull 消息，其他的 replica只是作为follower从leader复制数据，leader负责所有的读写；如果没有一个leader的话，所有的replica都去进行读写 那么NxN(N+1个replica之间复制消息)的互相同步数据就变得很复杂而且数据的一致性和有序性不能够保证。
为了实现更高的可用性，推荐在部署kafka的时候，能够保证一个topic的partition数量大于broker的数量，而且还需要把replica均匀的分布在所有的broker上，不能够只分布在一个 broker上，如果只分布在一个broker上，此时如果broker 宕机，会导致所有的replica都不能够提供服务，partition数据丢失或是不能够写入和读取，所以需要均匀的分布replica，即使某个broker宕机，但是可以保证它上面的负载可以被均匀的分配到其他幸存的拥有replica的broker上。kafka与rabbit mq,rocket mq