银行系统中的消息分发利器Kafka（三）

建议从头阅读：
银行系统中的消息分发利器Kafka（一）
银行系统中的消息分发利器Kafka（二）

6、Partition
上次我们说到，Kafka可以存储数据，而且数据按照Topic进行分类。
这些存储的数据可能会很大，这可能会给Kafka的Broker带来很大的存储压力。
一个好的解决办法就是把这些数据拆成一个或多个Partition：

然后，把这多个Partition分发到不同的服务器上。
Kafka是一个分布式系统，所以对数据文件的Partition进行分布式管理是很方便的。
随之，另外一个问题来了，我们要把数据分成多少个Partition呢？

这个问题不是Kafka来解答的，而是Kafka的管理员，他们会确定一项数据分成多少个Partition，然后Kafka再按照他们的指令来处理分区。
每一个Partition就存在一个服务器上，也不能再将他们进一步拆分。所以管理员可以根据服务器情况计算出Partition的数量。
7、Offset
我们知道Kafka上会接受大量的消息（Message），然后这样一个一个消息在Kafka中会形成一个顺序的队列。
而Offset是就是“消息”在队列中的位置。

在每一个Partition 中，第一个消息的Offset就是0，第二个就是1，以此类推。另外，Offset并不是一个全局的ID，它只作用于所属的Partition。所以，在同一个Partition中，不会有相同的Offset。
结合上面的知识，我们可以知道，如果要在Kafka中定位一个消息信息，就是先找到Topic，然后找到Partition，最后找到Offset。

8、Consumer Group
先把前面的场景复习一下。
首先我们有很多节点的数据要收集，于是我们通过Kafka来实现：

然后我们为每一个节点创建一个Producer：

现在我们为Kafka创建Consumer，Consumer将从Kafka上获取数据，并将数据存入DataCenter：

这时，你有成百上千的Producer同时将数据放入同一个Topic，Kafka怎么能hold住呢？我们前面说过Kafka是一个分布式系统，于是我们利用很多的Kafka Broker来分散处理压力，并且将数据分Partition：

这时你会发现，处理压力跑到Conumser那里了，于是我们就需要一个Consumer Group了。

Consumer Group中的Consumer要与Partition一一对应。因此，一个Topic有多少Partition，一个Consumer Group就有多少Consumer。Kafka不允许两个或两个以上的Consumer同时读取一个Partition的数据，以避免double reading的问题。

Kafka的几个重要的概念就介绍完了。后面我会逐步深入的介绍Kafka的一些细节，欢迎关注～