强大的分布式消息中间件——kafka

在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题：

l  我想分析一下用户行为（pageviews），以便我能设计出更好的广告位

l  我想对用户的搜索关键词进行统计，分析出当前的流行趋势。这个很有意思，在经济学上有个长裙理论，就是说，如果长裙的销量高了，说明经济不景气了，因为姑娘们没钱买各种丝袜了。

l  有些数据，我觉得存数据库浪费，直接存硬盘又怕到时候操作效率低。

这个时候，我们就可以用到分布式消息系统了。虽然上面的描述更偏向于一个日志系统，但确实kafka在实际应用中被大量的用于日志系统。

首先我们要明白什么是消息系统，在kafka官网上对kafka的定义叫：A distributed publish-subscribe messaging system。publish-subscribe是发布和订阅的意思，所以更准确的说kafka是一个消息订阅和发布的系统。publish-subscribe这个概念很重要，因为kafka的设计理念就可以从这里说起。

我们将消息的发布（publish）暂时称作producer，将消息的订阅（subscribe）表述为consumer，将中间的存储阵列称作broker，这样我们就可以大致描绘出这样一个场面：

生产者（蓝色，蓝领么，总是辛苦点儿）将数据生产出来，丢给broker进行存储，消费者需要消费数据了，就从broker中去拿出数据来，然后完成一系列对数据的处理。

乍一看这也太简单了，不是说了它是分布式么，难道把producer、broker和consumer放在三台不同的机器上就算是分布式了么。我们看kafka官方给出的图：

多个broker协同合作，producer和consumer部署在各个业务逻辑中被频繁的调用，三者通过zookeeper管理协调请求和转发。这样一个高性能的分布式消息发布与订阅系统就完成了。图上有个细节需要注意，producer到broker的过程是push，也就是有数据就推送到broker，而consumer到broker的过程是pull，是通过consumer主动去拉数据的，而不是broker把数据主动发送到consumer端的。

这样一个系统到底哪里体现出了它的高性能，如官网上所述，翻译如下：

（1）数据在磁盘上存取代价为O(1)。一般数据在磁盘上是使用BTree存储的，存取代价为O（lgn）。

（2）高吞吐率。即使在普通的节点上每秒钟也能处理成百上千的message。

（3）显式分布式，即所有的producer、broker和consumer都会有多个，均为分布式的。

（4）支持数据并行加载到Hadoop中。

等等

至此你应该对kafka是一个什么样的系统有所体会，并能了解他的基本结构，还有就是他能用来做什么。那么接下来，我们再回到producer、consumer、broker以及zookeeper这四者的关系中来。

我们看上面的图，我们把broker的数量减少，只有一台。现在假设我们按照上图进行部署：

l  Server-1 broker其实就是kafka的server，因为producer和consumer都要去连它。Broker主要还是做存储用。

l  Server-2是zookeeper的server端，zookeeper的具体作用你可以去官网查，在这里你可以先想象，它维持了一张表，记录了各个节点的IP、端口等信息（以后还会讲到，它里面还存了kafka的相关信息）。

l  Server-3、4、5他们的共同之处就是都配置了zkClient，更明确的说，就是运行前必须配置zookeeper的地址，道理也很简单，这之间的连接都是需要zookeeper来进行分发的。

l  Server-1和Server-2的关系，他们可以放在一台机器上，也可以分开放，zookeeper也可以配集群。目的是防止某一台挂了。

简单说下整个系统运行的顺序：

1.         启动zookeeper的server

2.         启动kafka的server

3.         Producer如果生产了数据，会先通过zookeeper找到broker，然后将数据存放进broker

4.         Consumer如果要消费数据，会先通过zookeeper找对应的broker，然后消费。