Kafka消息topic分区

 

kafka是为分布式环境设计的,所以若是日志文件,其实也能够理解成消息数据库,放在同一个地方,那么必然会带来可用性的降低,一挂全挂,若是全量拷贝到全部的机器上,那么数据又存在过多的冗余,并且因为每台机器的磁盘大小是有限的,因此即便有再多的机器,可处理的消息仍是被磁盘所限制,没法超越当前磁盘大小.所以有了partition的概念.

kafka对消息进行必定的计算,经过hash来进行分区.这样,就把一份log文件分红了多份.如上面的分区读写日志图,分红多份之后,在单台broker上,好比快速上手中,若是新建topic的时候,咱们选择了--replication-factor 1 --partitions 2,那么在log目录里,咱们会看到
test-0目录和test-1目录.就是两个分区了.

你可能会想,这特么没啥区别呀.注意,当有了多个broker以后,这个意义就存在了.这里上一张图,原文在参考连接里有

 

这是一个topic包含4个Partition，2 Replication(拷贝),也就是说所有的消息被放在了4个分区存储,为了高可用,将4个分区作了2份冗余,而后根据分配算法.将总共8份数据,分配到broker集群上.

结果就是每一个broker上存储的数据比全量数据要少,但每份数据都有冗余,这样,一旦一台机器宕机,并不影响使用.好比图中的Broker1,宕机了.那么剩下的三台broker依然保留了全量的分区数据.因此还能使用,若是再宕机一台,那么数据不完整了.固然你能够设置更多的冗余,好比设置了冗余是4,那么每台机器就有了0123完整的数据,宕机几台都行.须要在存储占用和高可用之间作衡量.
至于宕机后,zookeeper会选出新的partition leader.来提供服务.这个等下篇文章

每一个使用者进程都属于一个使用者小组（consumer group） 。

 

准确地讲，每条消息都只会发送给每一个使用者小组中的一个进程。

 

所以，使用者小组使得许多进程或多台机器在逻辑上做为一个单个的使用者出现。使用者小组这个概念很是强大，能够用来支持JMS中队列（queue）或者话题（topic）这两种语义。

 

为了支持队列语义，咱们能够将全部的使用者组成一个单个的使用者小组，在这种状况下，每条消息都会发送给一个单个的使用者。

 

为了支持话题语义，能够将每一个使用者分到它本身的使用者小组中，随后全部的使用者将接收到每一条消息。

 

在咱们的使用当中，一种更常见的状况是，咱们按照逻辑划分出多个使用者小组，每一个小组都是有做为一个逻辑总体的多台使用者计算机组成的集群。在大数据的状况下，Kafka有个额外的优势，对于一个话题而言，不管有多少使用者订阅了它，一条条消息都只会存储一次。