标签：
最近一段时间，使用Kafka比较多。从初期的FE项目中单纯调研KafkaProducer怎么使用到后面的在弦上项目使用KafkaConsumer期间，对Kafka有了一个大致的了解。最近由于比较空闲，所以在寻找一些关于Kafka的资料来看。总的来说，Kafka就是一个新型的分布式消息队列开源工具，现成的PDF、书籍是比较少的，最好的资料还是Apache上的Kafka，Apache Kafka
首先说下Kafka的总体架构（摘抄自官网）：
Kafka是一个生产者-消费者消息订阅系统，主载体就是topic，Producer发布消息到指定的topic上，订阅了该topic的Consumer就可以获取相关消息。Kafka是一个分布式系统，为此，每个topic被分为多个partition。
在Producer端，多个Producer可以共同写入一个topic，由于是多线程处理，发布消息的顺序在topic中是无法保证的，topic是由partition构成的，也就是partition之间的先后顺序是无法保证的。然而，每个partition内部的消息是有序的，每个producer都可以产生消息到不同的partition中。Producer在发布消息的时候可以使用同步或者异步的方式，可以根据配置文件去完成。Cluster是Producer和Consumer的中间载体，它包含多个broker。Producer发布消息到Cluster中，Consumer从Cluster中消费消息。数据的replication是每个分布式系统都要考虑的问题，在Kafka中，每个topic有多个partition，数据的replication是以partition为单位进行的，每个partition都有一个broker作为leader，别的broker都是该partition的slave，该leader接受从Producer来的关于partition的数据，而别的slave只是单纯的负责去复制leader的操作。也就是说，对每个partition只有一个leader去跟consumer和producer去沟通，为了保证该leader在宕掉后数据不丢失，系统就要从别的slave中选择一个作为leader，去执行leader的任务。cluster集群存储空间一般都比较大，所以从producer到cluster的数据推送方式是push，而从consumer到cluster获取数据的方式是pull，关于consumer下面会具体阐述。每个broker都是某个partition的leader，同时它又是别的partition的slave。
在consumer端，Consumer从cluster获取数据的方式不是push，而是pull，这两者的区别是：push是主动推送数据，像producer只要产生数据就主动推送到cluster中，而不是产生数据后放到本地，由cluster主动去pull Producer的数据。这样做是因为cluster很忙，并且空间很大，这样就可以被动的去接受Producer的数据。同样，因为cluster很忙，Consumer如果需要数据可以主动去Cluster中去pull。另外，cluster不知道Consumer的消费能力，如果Producer的生产数据的能力远大于Consumer的消费能力，并且cluster一直不停的把数据push给Consumer，很可能会导致Consumer宕机，因此，采用pull的方式，Consumer什么时候需要数据自己去取。
在分布式系统中，有多个Consumer同时去消费数据，这些Consumer的协同就成了一个重要的工作，在Kafka中，每个Consumer是有一个全局的group_id的，如下图所示：
每个Consumer都隶属于每个group，为了保证消费的正确性，每个组都是一个完整的个体，它会把Cluster的数据全部消费掉，不同的组根据自己的需求会不同的去消费数据。在每个组内，每个partition都会唯一的分配给一个consumer，不会把它分配给两个或者以上的Consumer。因此一个group内的consumer数量不能大于partition的数量，否则会有consumer永远不工作的结果。为了保证数据消费的一致性，避免数据重消费或者未消费，Kafka中每个partition都有一个offset，表示consumer消费该partition到什么位置了，该位置是由consumer保有的，每次consumer去cluster请求数据的时候它就会把offset给cluster看，告诉cluster我上次消费到哪里了，这次应该从哪里消费。同时为了满足consumer不同的需求，consumer可以重置该offset到任意位置。
吃了个饭，突然没思路了，算了先这样吧。
标签：
原文地址：http://blog.csdn.net/cimuhuan/article/details/51330257
