深入浅出系列之 -- kafka分区分配策略

生产者的分区分配

对于用户而言，当调用send方法发送消息之后，消息就自然而然的发送到了broker中。其实在这一过程中，有可能还要经过拦截器、序列化器和分区器（Partitioner）的一系列作用之后才能被真正地发往broker。

producer.send(record);

消息在发往broker之前是需要确定它所发往的分区的，如果消息ProducerRecord中指定了partition字段，那么就不需要分区器的作用，因为partition代表的就是所要发往的分区号。但是如果消息ProducerRecord中没有指定partition字段，那么就需要依赖分区器，根据key这个字段来计算partition的值。分区器的作用就是为消息分配分区。

Kafka中提供的默认分区器是DefaultPartitioner，它实现了Partitioner接口（用户可以实现这个接口来自定义分区器），其中的partition方法就是用来实现具体的分区分配逻辑：

public int partition(String topic, Object key, byte[] keyBytes,
                     Object value, byte[] valueBytes, Cluster cluster);

默认情况下，如果消息的key不为null，那么默认的分区器会对key进行哈希（采用MurmurHash2算法，具备高运算性能及低碰撞率），最终根据得到的哈希值来计算分区号，拥有相同key的消息会被写入同一个分区。如果key为null，那么消息将会以轮询的方式发往主题内的各个可用分区。

注意：如果key不为null，那么计算得到的分区号会是所有分区中的任意一个；如果key为null并且有可用分区，那么计算得到的分区号仅为可用分区中的任意一个，注意两者之间的差别。

消费者的分区分配

用过Kafka的同学用过都知道，每个主题一般会有很多个分区。为了使得我们能够及时消费消息，我们也可能会启动多个消费者去消费，而每个消费者又会启动一个或多个溪流去分别消费Topic里面的数据。我们又知道，Kafka存在Consumer Group的概念，也就是group.id一样的Cons