WEBVTT 00:04.320 --> 00:06.580 Let's summarize key points of this example. 00:06.900 --> 00:12.690 We have started the single Brylcreem and greet the topic with five partitions and then of the topic 00:12.690 --> 00:19.350 was Nomura's replication factor was set to default equal to one next week of Loung. 00:19.740 --> 00:27.240 Several consumers in the same consumer group using this command and a group name was NOM's. 00:27.510 --> 00:33.900 And we have started just with a single consumer and ended up with six concurrent consumers in the same 00:33.900 --> 00:40.530 group and while having multiple consumers in the same group running, we have read the tales about specific 00:40.530 --> 00:47.370 consumer group, and in this output we're able to see which partitions were assigned to different consumers. 00:47.700 --> 00:54.420 And Kafka tries to spread the different partitions across all available consumers in the same group 00:54.420 --> 00:55.110 equally. 00:55.410 --> 01:01.710 And also in this output, you always see current of sales that are committed offsets by specific consumers 01:01.710 --> 01:06.150 in specific partition look end and offsets of the messages in each partition. 01:06.390 --> 01:12.780 And also you may select and we will try to make this number non-zero in the next example. 01:13.020 --> 01:19.890 And main outcome from this example is that if there are more consumers, then available partitions, 01:20.160 --> 01:25.160 then some of the consumers will be idle and will not consume any messages at all. 01:25.710 --> 01:27.030 That's all for this example. 01:27.030 --> 01:34.200 And the next Dalitz Lounge Kafka performance producer that will produce a bunch of messages instead 01:34.200 --> 01:36.750 of this is a built in producer. 01:36.870 --> 01:43.770 And we will actually try to overload our consumers and we will try to observe how they will be able 01:43.770 --> 01:45.840 to catch up with increased load. 01:46.080 --> 01:47.670 So see you in the next example. 01:47.670 --> 01:48.060 By by.