We have just successfully launched consumer and consumer messages that were produced by a producer and
we co-produced messages to topic numbers, and we have consumer messages from the same topic.
Also, we hear from every message like this.
And here we were able to see offset for each message, give value and partition.
Each message was written to.
And if I scroll down here to this output somewhere here, you'll see such kind of messages here in the
terminal.
And we have noticed that the actually consumer does not read the every message one by one from different
partitions.
Instead, it tries to read messages in batches.
This way here in this output, you see a set of messages that were read from the same position in this
example, partition number two.
But of course, offset the numbers are incrementing in because consumer consumers messages one by one.
Great.
And we have said such properties as a boost for observers group Edem.
It is consumer group Edem Gajda Serializer, Melida, Serializer.
We have also enabled us to commit and all the messages we are sent every second.
Let's now get back to all properties that you are able to set for consumer and let me quickly go through
most important of them and explain them in greater details.
Let's go to documentation here and let's scroll to the configuration of the consumer.
So please click on Consumer Config section, this one and let's start.
We have already discussed the serializer and Berlinda serializer, and with those properties you could
set actually interfaces that should be used in order to the gold, its sequences and the if on our producer
you use the string serializer, then on consumer side you should use strewing death serializer.
And that's the most common serializer.
And this really is those that are usually used.
OK, next bootstrap sevres.
This property is the same as for producers.
And here you specify list of servers in your Kafka Gloster.
And again, it's a good convention to specify all available servers instead of just one.
That's why here in our example, we have listed all three brokers that exist in our cluster next pfeg
mean bytes.
This parameter specifies minimum amount of data.
The server should return for a feature request and default value for this parameter is one one byte
and this well tells how many bytes a broker should accumulate before sending them to consumer.
And actually, if you'll increase this value, then the data will be sent more efficiently and with
higher throughput.
But it also will introduce some additional latency.
So I suggest you to leave with this parameter as a default one one byte next one group idea with group
is the parameter.
You are able to set up a consumer group ID and from the previous sections, you know that all consumers
in the same group will actually share messages from specific topic.
And every message in the topic will be received only by one of the consumers in specific consumer group.
Next one here, beta internal dot.
Unless this parameter works in conjunction with the parameter session, the timeout dot amyas and the
default value for this beta interval is three seconds and the value of the session timeout is actually
ten seconds.
And that means that this had to be the interval is three times smaller than session time out.
And actually with such setting, the consumer will front have to be two Kafka brockers every three seconds.
And this parameter is actually used to indicate that the consumer is still alive, is still active and
is waiting for new messages.
But the if three bit messages were missed, that means that the session time out will be expired.
And in ten seconds Brokers' may decide that the consumer is down and they will rebalance the consumer
group and the will no longer send any messages to that consumer that went down again.
The session time out in milliseconds indicates how long the client, the consumer may be silent or inactive
before Broecker decides that this consumer is down.
OK, next parameter marks partition Fage bytes.
This parameter indicates how much bytes per partition consumer can consume just in a single request
and by default.
This asset is the one megabyte.
Here it is.
And with the help of this parameter, consumer is able to retrieve multiple messages.
Personally request that the gold actually badge match request, and that's why here in Domhnall, we
have seen that the consumer read the messages in batches from different partitions.
Here you see batch that came from proposition number two.
Here you see badge that came from partition with 84 and so on.
That's because of this parameter.
And by default, again, it is set to one megabyte after session time out parameter that we have already
discussed.
You may see different parameters related to SSL encryption.
And again, by default, there was no encryption between consumers and brokers and the same as with
producers.
It is recommended to use SSL encryption if there is unsecure network between the brokers and consumers.
Also below, you may see other parameters with the medium and low importance.
And again, I suggest you do briefly go through those parameters and read about all of them.
This old guy is for this example, where I will briefly overview the most important parameters that
you are able to set up on a consumer level.
And next, let's proceed and have a look at another example of consumer and instead of how the and will
set Menorca meeting.
And also we will write every message that we will consume to file instead of time.
Now, I'll see you in the next laubscher by.