anchor.diff:  In the above example, the topic has five partitions.
   Partition 0 has two replicas: one on node 2, the other node 3.
   The replica on node 2 is the leader.
  -Leader partitions are evenly distributed among this 2 node cluster.
  -The leader partition is where message are
  +You will notice the leader partitions are evenly distributed among this 3 node cluster.
   
   Each partition is an independent log of events.
   In this log, messages are *sorted* by their arrival order.
  
positive.code: ----
  <1> Connect to these Kafka connect nodes.
    Like the producer, it doesn't have to be the whole Kafka cluster.
  <2> Register this application as a consumer for this list of topics.
    Kafka will assign some partitions to this consumer.
  <3> Try to pull messages from the broker.
  <4> Pulled messages are automatically acknowledged.
  
  In the above example, connecting to the broker, subscribing to one or more topics,
  and being assigned partitions takes time and is usually done once during application start-up.
  On the contrary, the `poll` should be run in loop,
  it returns a batch of records whose size is controlled by the `max.poll.records` setting.
  
  Unlike the producer, the consumer is not thread-safe.
  In order to consumer records in parallel, each thread should have it's own consumer.
  
  == Acknowledging received messages
  
  The message acknowledgement is called offset commit,
  because Kafka keeps track the offset of the last consumed message for each topic + partition + consumer group.
  
  In the previous example, the offsets were automatically and periodically committed to the broker.
  
  [source,java]
  ----
  
negative.code: A consumer is a process in charge for reading messages from a topic and dealing with them.
  As an acknowledgement, the consumer writes the message offset back to the broker, it's called *offset commit*.
  
  A *consumer group* is a set of consumers distributed on multiple machines.
  For a given topic and group, each partition gets read by a single consumer.
  This prevents messages from being consumed twice in the consumer group.
  On the contrary, a consumer can be in charge of several partitions.
  
  image::2016-10-10-Kafka-Java-Client/kafka_group.svg[Consumer and Consumer Group]
  
  The Kafka cluster tells each consumer which partition it should read from.
  Each consumer takes care of its portion of topic.
  As a result, consumers can work independently and in parallel,
  and messages stored in a topic can be load balanced to consumers on many machines.
  In case of consumer failure, Kafka reassigns the partitions to other consumers of the same group.
  
  Like the producer, the consumer is initialized and configured with some properties.
  