WEBVTT 00:04.270 --> 00:10.360 We have just successfully launched consumer and consumer messages that were produced by a producer and 00:10.360 --> 00:15.150 we co-produced messages to topic numbers, and we have consumer messages from the same topic. 00:15.640 --> 00:18.420 Also, we hear from every message like this. 00:18.640 --> 00:25.690 And here we were able to see offset for each message, give value and partition. 00:25.690 --> 00:27.330 Each message was written to. 00:27.610 --> 00:34.640 And if I scroll down here to this output somewhere here, you'll see such kind of messages here in the 00:34.640 --> 00:35.230 terminal. 00:35.470 --> 00:42.340 And we have noticed that the actually consumer does not read the every message one by one from different 00:42.340 --> 00:43.090 partitions. 00:43.510 --> 00:47.050 Instead, it tries to read messages in batches. 00:47.290 --> 00:53.200 This way here in this output, you see a set of messages that were read from the same position in this 00:53.200 --> 00:55.330 example, partition number two. 00:55.630 --> 01:01.900 But of course, offset the numbers are incrementing in because consumer consumers messages one by one. 01:02.410 --> 01:02.830 Great. 01:02.830 --> 01:06.750 And we have said such properties as a boost for observers group Edem. 01:06.760 --> 01:10.920 It is consumer group Edem Gajda Serializer, Melida, Serializer. 01:10.960 --> 01:17.400 We have also enabled us to commit and all the messages we are sent every second. 01:17.800 --> 01:24.460 Let's now get back to all properties that you are able to set for consumer and let me quickly go through 01:24.460 --> 01:27.910 most important of them and explain them in greater details. 01:28.270 --> 01:34.270 Let's go to documentation here and let's scroll to the configuration of the consumer. 01:34.390 --> 01:38.470 So please click on Consumer Config section, this one and let's start. 01:38.770 --> 01:45.010 We have already discussed the serializer and Berlinda serializer, and with those properties you could 01:45.010 --> 01:54.130 set actually interfaces that should be used in order to the gold, its sequences and the if on our producer 01:54.130 --> 02:00.790 you use the string serializer, then on consumer side you should use strewing death serializer. 02:00.970 --> 02:03.460 And that's the most common serializer. 02:03.580 --> 02:05.740 And this really is those that are usually used. 02:06.130 --> 02:08.140 OK, next bootstrap sevres. 02:08.410 --> 02:11.500 This property is the same as for producers. 02:11.500 --> 02:16.110 And here you specify list of servers in your Kafka Gloster. 02:16.270 --> 02:22.090 And again, it's a good convention to specify all available servers instead of just one. 02:22.360 --> 02:30.070 That's why here in our example, we have listed all three brokers that exist in our cluster next pfeg 02:30.070 --> 02:30.850 mean bytes. 02:31.210 --> 02:34.450 This parameter specifies minimum amount of data. 02:34.450 --> 02:40.600 The server should return for a feature request and default value for this parameter is one one byte 02:40.870 --> 02:47.650 and this well tells how many bytes a broker should accumulate before sending them to consumer. 02:47.920 --> 02:54.820 And actually, if you'll increase this value, then the data will be sent more efficiently and with 02:54.820 --> 02:55.660 higher throughput. 02:55.840 --> 03:00.070 But it also will introduce some additional latency. 03:00.220 --> 03:07.510 So I suggest you to leave with this parameter as a default one one byte next one group idea with group 03:07.510 --> 03:08.260 is the parameter. 03:08.260 --> 03:15.130 You are able to set up a consumer group ID and from the previous sections, you know that all consumers 03:15.130 --> 03:19.480 in the same group will actually share messages from specific topic. 03:19.780 --> 03:27.080 And every message in the topic will be received only by one of the consumers in specific consumer group. 03:27.970 --> 03:30.370 Next one here, beta internal dot. 03:30.370 --> 03:37.690 Unless this parameter works in conjunction with the parameter session, the timeout dot amyas and the 03:37.690 --> 03:46.720 default value for this beta interval is three seconds and the value of the session timeout is actually 03:46.720 --> 03:47.620 ten seconds. 03:47.620 --> 03:54.370 And that means that this had to be the interval is three times smaller than session time out. 03:54.760 --> 04:02.620 And actually with such setting, the consumer will front have to be two Kafka brockers every three seconds. 04:02.800 --> 04:09.280 And this parameter is actually used to indicate that the consumer is still alive, is still active and 04:09.280 --> 04:10.960 is waiting for new messages. 04:11.350 --> 04:19.090 But the if three bit messages were missed, that means that the session time out will be expired. 04:19.240 --> 04:26.350 And in ten seconds Brokers' may decide that the consumer is down and they will rebalance the consumer 04:26.350 --> 04:31.870 group and the will no longer send any messages to that consumer that went down again. 04:31.870 --> 04:38.830 The session time out in milliseconds indicates how long the client, the consumer may be silent or inactive 04:38.980 --> 04:42.100 before Broecker decides that this consumer is down. 04:42.580 --> 04:46.000 OK, next parameter marks partition Fage bytes. 04:46.390 --> 04:54.220 This parameter indicates how much bytes per partition consumer can consume just in a single request 04:54.610 --> 04:55.630 and by default. 04:55.630 --> 04:57.880 This asset is the one megabyte. 04:57.880 --> 04:58.660 Here it is. 04:58.660 --> 05:03.310 And with the help of this parameter, consumer is able to retrieve multiple messages. 05:03.560 --> 05:09.740 Personally request that the gold actually badge match request, and that's why here in Domhnall, we 05:09.740 --> 05:14.920 have seen that the consumer read the messages in batches from different partitions. 05:14.930 --> 05:17.860 Here you see batch that came from proposition number two. 05:18.200 --> 05:22.070 Here you see badge that came from partition with 84 and so on. 05:22.290 --> 05:23.840 That's because of this parameter. 05:23.840 --> 05:29.210 And by default, again, it is set to one megabyte after session time out parameter that we have already 05:29.210 --> 05:29.770 discussed. 05:29.930 --> 05:33.920 You may see different parameters related to SSL encryption. 05:33.920 --> 05:40.920 And again, by default, there was no encryption between consumers and brokers and the same as with 05:41.210 --> 05:41.950 producers. 05:41.960 --> 05:49.030 It is recommended to use SSL encryption if there is unsecure network between the brokers and consumers. 05:49.580 --> 05:54.230 Also below, you may see other parameters with the medium and low importance. 05:54.320 --> 05:59.410 And again, I suggest you do briefly go through those parameters and read about all of them. 05:59.960 --> 06:04.940 This old guy is for this example, where I will briefly overview the most important parameters that 06:04.940 --> 06:07.340 you are able to set up on a consumer level. 06:07.610 --> 06:14.090 And next, let's proceed and have a look at another example of consumer and instead of how the and will 06:14.090 --> 06:15.730 set Menorca meeting. 06:15.890 --> 06:21.680 And also we will write every message that we will consume to file instead of time. 06:21.740 --> 06:23.870 Now, I'll see you in the next laubscher by.