Apache Kafka – пример группы потребителей
Потребительская группа – это многопоточное или многопользовательское потребление по темам Kafka.
Потребительская группа
- Потребители могут присоединиться к группе, используя тот же group.id.
- Максимальный параллелизм группы заключается в том, что количество потребителей в группе ← нет разделов.
- Kafka назначает разделы темы потребителю в группе, так что каждый раздел потребляется ровно одним потребителем в группе.
- Кафка гарантирует, что сообщение будет прочитано только одним потребителем в группе.
- Потребители могут видеть сообщение в том порядке, в котором они были сохранены в журнале.
Потребители могут присоединиться к группе, используя тот же group.id.
Максимальный параллелизм группы заключается в том, что количество потребителей в группе ← нет разделов.
Kafka назначает разделы темы потребителю в группе, так что каждый раздел потребляется ровно одним потребителем в группе.
Кафка гарантирует, что сообщение будет прочитано только одним потребителем в группе.
Потребители могут видеть сообщение в том порядке, в котором они были сохранены в журнале.
Перебалансировка потребителя
Добавление большего количества процессов / потоков приведет к перебалансировке Kafka. Если какой-либо потребитель или брокер не может отправить пульс ZooKeeper, его можно перенастроить через кластер Kafka. Во время этого перебалансирования Kafka назначит доступные разделы доступным потокам, возможно, переместив раздел в другой процесс.
import java.util.Properties; import java.util.Arrays; import org.apache.kafka.clients.consumer.KafkaConsumer; import org.apache.kafka.clients.consumer.ConsumerRecords; import org.apache.kafka.clients.consumer.ConsumerRecord; public class ConsumerGroup public static void main(String[] args) throws Exception if(args.length 2) System.out.println("Usage: consumer "); return; > String topic = args[0].toString(); String group = args[1].toString(); Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("group.id", group); props.put("enable.auto.commit", "true"); props.put("auto.commit.interval.ms", "1000"); props.put("session.timeout.ms", "30000"); props.put("key.deserializer", "org.apache.kafka.common.serialization.ByteArraySerializer"); props.put("value.deserializer", "org.apache.kafka.common.serializa-tion.StringDeserializer"); KafkaConsumerString, String> consumer = new KafkaConsumerString, String>(props); consumer.subscribe(Arrays.asList(topic)); System.out.println("Subscribed to topic " + topic); int i = 0; while (true) ConsumerRecordsString, String> records = con-sumer.poll(100); for (ConsumerRecordString, String> record : records) System.out.printf("offset = %d, key = %s, value = %s\n", record.offset(), record.key(), record.value()); > > >
компиляция
javac -cp “/path/to/kafka/kafka_2.11-0.9.0.0/libs/*" ConsumerGroup.java
выполнение
>>java -cp “/path/to/kafka/kafka_2.11-0.9.0.0/libs/*":. ConsumerGroup my-group >>java -cp "/home/bala/Workspace/kafka/kafka_2.11-0.9.0.0/libs/*":. ConsumerGroup my-group
Здесь мы создали пример группы названий my-group с двумя потребителями. Точно так же вы можете создать свою группу и количество потребителей в группе.
вход
Откройте CLI производителя и отправьте несколько сообщений вроде –
Test consumer group 01 Test consumer group 02
Вывод первого процесса
Subscribed to topic Hello-kafka offset = 3, key = null, value = Test consumer group 01
Вывод второго процесса
Subscribed to topic Hello-kafka offset = 3, key = null, value = Test consumer group 02
Теперь, надеюсь, вы бы поняли SimpleConsumer и ConsumeGroup, используя демонстрационную версию клиента Java. Теперь у вас есть представление о том, как отправлять и получать сообщения с помощью клиента Java. Давайте продолжим интеграцию Kafka с технологиями больших данных в следующей главе.
Apache Kafka – мой конспект
Это мой конспект, в котором коротко и по сути затрону такие понятия Kafka как:
— Тема (Topic)
— Подписчики (consumer)
— Издатель (producer)
— Группа (group), раздел (partition)
— Потоки (streams)
Kafka — основное
При изучении Kafka возникали вопросы, ответы на которые мне приходилось эксперементально получать на примерах, вот это и изложено в этом конспекте. Как стартовать и с чего начать я дам одну из ссылок ниже в материалах.
Apache Kafka – диспетчер сообщений на Java платформе. В Kafka есть тема сообщения в которую издатели пишут сообщения и есть подписчики в темах, которые читают эти сообщения, все сообщения в процессе диспетчеризации пишутся на диск и не зависит от потребителей.
В состав Kafka входят набор утилит по созданию тем, разделов, готовые издатели, подписчики для примеров и др. Для работы Kafka необходим координатор «ZooKeeper», поэтому вначале стартуем ZooKeeper (zkServer.cmd) затем сервер Kafka (kafka-server-start.bat), командные файлы находятся в соответствующих папках bin, там же и утилиты.
Создадим тему Kafka утилитой, ходящей в состав
kafka-topics.bat —create —zookeeper localhost:2181 —replication-factor 1 —partitions 1 —topic out-topic
здесь указываем сервер zookeeper, replication-factor это количество реплик журнала сообщений, partitions – количество разделов в теме (об этом ниже) и собственно сама тема – “out-topic”.
Для простого тестирования можно использовать входящие в состав готовые приложения «kafka-console-consumer» и «kafka-console-producer», но я сделаю свои. Подписчики на практике объединяют в группы, это позволит разным приложениям читать сообщения из темы параллельно.
Для каждого приложения будет организованна своя очередь, читая из которой оно выполняет перемещения указателя последнего прочитанного сообщения (offset), это называется фиксацией (commit) чтения. И так если издатель отправит сообщение в тему, то оно будет гарантированно прочитано получателем этой темы если он запущен или, как только он подключится. Причем если есть разные клиенты (client.id), которые читают из одной темы, но в разных группах, то сообщения они получат не зависимо друг от друга и в то время, когда будут готовы.
Так можно представить последователь сообщений и независимое чтение их потребителями из одной темы.
Но есть ситуация, когда сообщения в тему могут начать поступать быстрее чем уходить, т.е. потребители обрабатывают их дольше. Для этого в теме можно предусмотреть разделы (partitions) и запускать потребителей в одной группе для этой темы.
Тогда произойдет распределение нагрузки и не все сообщения в теме и группе пойдут через одного потребителя. И тогда уже будет выбрана стратегия, как распределять сообщения по разделам. Есть несколько стратегий: round-robin – это по кругу, по хэш значению ключа, или явное указание номера раздела куда писать. Подписчики в этом случае распределяются равномерно по разделам. Если, например, подписчиков будет в группе будет больше чем разделов, то кто-то не получит сообщения. Таким образом разделы делаются для улучшения масштабируемости.
Например после создания темы с одним разделом я изменил на два раздела.
kafka-topics.bat —zookeeper localhost:2181 —alter —topic out-topic —partitions 2
Запустил своего издателя и двух подписчиков в одной группе на одну тему (примеры java программ будут ниже). Конфигурировать имена групп и ИД клиентов не надо, Kafka берет это на себя.
my_kafka_run.cmd com.home.SimpleProducer out-topic (издатель)
my_kafka_run.cmd com.home.SimpleConsumer out-topic testGroup01 client01 (первый подписчик)
my_kafka_run.cmd com.home.SimpleConsumer out-topic testGroup01 client02 (второй подписчик)
Начав вводить в издателе пары ключ: значение можно наблюдать кто их получает. Так, например, по стратегии распределения по хэшу ключа сообщение m:1 попало клиенту client01
а сообщение n:1 клиенту client02
Если начну вводить без указания пар ключ: значение (такую возможность сделал в издателе), будет выбрана стратегия по кругу. Первое сообщение «m» попало client01, а уже втрое client02.
И еще вариант с указанием раздела, например в таком формате key:value:partition
Ранее в стратегии по хэш, m:1 уходил другому клиенту (client01), теперь при явном указании раздела (№1, нумеруются с 0) — к client02.
Если запустить подписчика с другим именем группы testGroup02 и для той же темы, то сообщения будут уходить параллельно и независимо подписчикам, т.е. если первый прочитал, а второй не был активен, то он прочитает, как только станет активен.
Можно посмотреть описания групп, темы соответственно:
kafka-consumer-groups.bat —bootstrap-server localhost:9092 —describe —group testGroup01
kafka-topics.bat —describe —zookeeper localhost:2181 —topic out-topic
Код SimpleProducer
public class SimpleProducer < public static void main(String[] args) throws Exception < // Check arguments length value if (args.length == 0) < System.out.println("Enter topic name"); return; >//Assign topicName to string variable String topicName = args[0].toString(); System.out.println("Producer topic=" + topicName); // create instance for properties to access producer configs Properties props = new Properties(); //Assign localhost id props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); //Set acknowledgements for producer requests. props.put("acks", "all"); //If the request fails, the producer can automatically retry, props.put("retries", 0); //Specify buffer size in config props.put("batch.size", 16384); //Reduce the no of requests less than 0 props.put("linger.ms", 1); //The buffer.memory controls the total amount of memory available to the producer for buffering. props.put("buffer.memory", 33554432); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); Producer producer = new KafkaProducer(props); BufferedReader br = null; br = new BufferedReader(new InputStreamReader(System.in)); System.out.println("Enter key:value, q - Exit"); while (true) < String input = br.readLine(); String[] split = input.split(":"); if ("q".equals(input)) < producer.close(); System.out.println("Exit!"); System.exit(0); >else < switch (split.length) < case 1: // strategy by round producer.send(new ProducerRecord(topicName, split[0])); break; case 2: // strategy by hash producer.send(new ProducerRecord(topicName, split[0], split[1])); break; case 3: // strategy by partition producer.send(new ProducerRecord(topicName, Integer.valueOf(split[2]), split[0], split[1])); break; default: System.out.println("Enter key:value, q - Exit"); >> > > > Код SimpleConsumer
public class SimpleConsumer < public static void main(String[] args) throws Exception < if (args.length != 3) < System.out.println("Enter topic name, groupId, clientId"); return; >//Kafka consumer configuration settings final String topicName = args[0].toString(); final String groupId = args[1].toString(); final String clientId = args[2].toString(); Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("group.id", groupId); props.put("client.id", clientId); props.put("enable.auto.commit", "true"); props.put("auto.commit.interval.ms", "1000"); props.put("session.timeout.ms", "30000"); //props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass()); //props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass()); props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); KafkaConsumer consumer = new KafkaConsumer(props); //Kafka Consumer subscribes list of topics here. consumer.subscribe(Arrays.asList(topicName)); //print the topic name System.out.println("Subscribed to topic=" + topicName + ", group=" + groupId + ", clientId=" + clientId); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); // looping until ctrl-c while (true) < ConsumerRecordsrecords = consumer.poll(100); for (ConsumerRecord record : records) // print the offset,key and value for the consumer records. System.out.printf("offset = %d, key = %s, value = %s, time = %s \n", record.offset(), record.key(), record.value(), sdf.format(new Date())); > > > Для запуска своих программ я сделал командный файл — my_kafka_run.cmd
@echo off set CLASSPATH="C:\Project\myKafka\target\classes"; for %%i in (C:\kafka_2.11-1.1.0\libs\*) do ( call :concat "%%i" ) set COMMAND=java -classpath %CLASSPATH% %* %COMMAND% :concat IF not defined CLASSPATH ( set CLASSPATH="%~1" ) ELSE ( set CLASSPATH=%CLASSPATH%;"%~1" ) пример запуска:
my_kafka_run.cmd com.home.SimpleConsumer out-topic testGroup02 client01
Kafka Streams
Итак, потоки в Kafka это последовательность событий, которые получают из темы, над которой можно выполнять определенные операции, трансформации и затем результат отдать далее, например, в другую тему или сохранить в БД, в общем куда угодно. Операции могут быть как например фильтрации (filter), преобразования (map), так и агрегации (count, sum, avg). Для этого есть соответствующие классы KStream, KTable, где KTable можно представить как таблицу с текущими агрегированными значениями которые постоянно обновляются по мере поступления новых сообщений в тему. Как это происходит?
Например, издатель пишет в тему события (сообщения), Kafka все сообщения сохраняет в журнале сообщений, который имеет политику хранения (Retention Policy), например 7 дней. Например события изменения котировки это поток, далее хотим узнать среднее значение, тогда создадим Stream который возьмет историю из журнала и посчитает среднее, где ключом будет акция, а значением – среднее (это уже таблица с состоянием). Тут есть особенность – операции агрегирования в отличии от операций, например, фильтрации, сохраняют состояние. Поэтому вновь поступающие сообщения (события) в тему, будут подвержены вычислению, а результат будет сохраняться (state store), далее вновь поступающие будут писаться в журнал, Stream их будет обрабатывать, добавлять изменения к уже сохраненному состоянию. Операции фильтрации не требуют сохранения состояния. И тут тоже stream будет делать это не зависимо от издателя. Например, издатель пишет сообщения, а программа — stream в это время не работает, ничего не пропадет, все сообщения будут сохранены в журнале и как только программа-stream станет активной, она сделает вычисления, сохранит состояние, выполнит смещение для прочитанных сообщений (пометит что они прочитаны) и в дальнейшем она уже к ним не вернется, более того эти сообщения уйдут из журнала (kafka-logs). Тут видимо главное, чтобы журнал (kafka-logs) и его политика хранения позволило это. По умолчанию состояние Kafka Stream хранит в RocksDB. Журнал сообщений и все с ним связанное (темы, смещения, потоки, клиенты и др.) располагается по пути указанном в параметре «log.dirs=kafka-logs» файла конфигурации «config\server.properties», там же указывается политика хранения журнала «log.retention.hours=48». Пример лога
А путь к базе с состояниями stream указывается в параметре приложения
config.put(StreamsConfig.STATE_DIR_CONFIG, «C:/kafka_2.11-1.1.0/state»);
Состояния хранятся по ИД приложениям независимо (StreamsConfig.APPLICATION_ID_CONFIG). Пример
Проверим теперь как работает Stream. Подготовим приложение Stream из примера, который есть поставке (с некоторой доработкой для эксперимента), которое считает количество одинаковых слов и приложение издатель и подписчик. Писать будет в тему in-topic
my_kafka_run.cmd com.home.SimpleProducer in-topic
Приложение Stream будет читать эту тему считать кол-во одинаковых слов, не явно для нас сохранять состояние и перенаправлять в другую тему out-topic. Тут я хочу прояснить связь журнала и состояния (state store). И так ZooKeeper и сервер Kafka запущены. Запускаю Stream с App-ID = app_01
my_kafka_run.cmd com.home.KafkaCountStream in-topic app_01
издатель и подписчик соответственно
my_kafka_run.cmd com.home.SimpleProducer in-topic
my_kafka_run.cmd com.home.SimpleConsumer out-topic testGroup01 client01
Начинаем вводить слова и видим их подсчет с указанием какой Stream App-ID их подсчитал
Работа будет идти независимо, можно остановить Stream и продолжать писать в тему, он потом при старте посчитает. А теперь подключим второй Stream c App-ID = app_02 (это тоже приложение, но с другим ИД), он прочитает журнал (последовательность событий, которая сохраняется согласно политике Retention), подсчитает кол-во, сохранит состояние и выдаст результат. Таким образом два потока начав работать в разное время пришли к одному результату.
А теперь представим наш журнал устарел (Retention политика) или мы его удалили (что бывает надо делать) и подключаем третий stream с App-ID = app_03 (я для этого остановил Kafka, удалил kafka-logs и вновь стартовал) и вводим в тему новое сообщение и видим первый (app_01) поток продолжил подсчет а новый третий начал с нуля.
Если затем запустим поток app_02, то он догонит первый и они будут равны в значениях. Из примера стало понятно, как Kafka обрабатывает текущий журнал, добавляет к ранее сохраненному состоянию и так далее.
Код KafkaCountStream
public class KafkaCountStream < public static void main(final String[] args) throws Exception < // Check arguments length value if (args.length != 2) < System.out.println("Enter topic name, appId"); return; >String topicName = args[0]; String appId = args[1]; System.out.println("Count stream topic=" + topicName +", app=" + appId); Properties config = new Properties(); config.put(StreamsConfig.APPLICATION_ID_CONFIG, appId); config.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); config.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass()); config.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass()); config.put(StreamsConfig.COMMIT_INTERVAL_MS_CONFIG, 2000); config.put(StreamsConfig.STATE_DIR_CONFIG, "C:/kafka_2.11-1.1.0/state"); StreamsBuilder builder = new StreamsBuilder(); KStream textLines = builder.stream(topicName); // State store KTable wordCounts = textLines .flatMapValues(textLine -> Arrays.asList(textLine.toLowerCase().split("\\W+"))) .groupBy((key, word) -> word) .count(); // out to another topic KStream stringKStream = wordCounts.toStream() .map((k, v) -> new KeyValue<>(appId + "." + k, v.toString())); stringKStream.to("out-topic", Produced.with(Serdes.String(), Serdes.String())); KafkaStreams streams = new KafkaStreams(builder.build(), config); // additional to complete the work final CountDownLatch latch = new CountDownLatch(1); // attach shutdown handler to catch control-c Runtime.getRuntime().addShutdownHook(new Thread("streams-shutdown-hook") < @Override public void run() < System.out.println("Kafka Stream close"); streams.close(); latch.countDown(); >>); try < System.out.println("Kafka Stream start"); streams.start(); latch.await(); >catch (Throwable e) < System.exit(1); >System.out.println("Kafka Stream exit"); System.exit(0); > > Тема Kafka очень обширна, я для себя сделал первое общее представление 🙂
Apache Kafka: что это и как работает
Apache Kafka — это система обмена сообщениями с открытым исходным кодом, которая была создана в LinkedIn примерно в 2011 году. Она обеспечивает быстрый, хорошо масштабируемый и надежный обмен сообщениями по модели pub-sub. Kafka допускает большое количество клиентов, отличается высокой доступностью, устойчивостью к сбоям узлов и поддерживает автоматическое восстановление.
Почему Apache Kafka так популярна?
Масштабируемость
Apache Kafka имеет распределенную архитектуру, обрабатывающую входящие сообщения с большим объемом и скоростью. Как результат — Kafka обладает высокой масштабируемостью без каких-либо простоев.
Высокая пропускная способность
Apache Kafka может обрабатывать миллионы сообщений в секунду. Сообщения, поступающие в большом объеме или с высокой скоростью не влияют на производительность
Низкая задержка
Kafka обеспечивает очень низкую задержку передачи, которая составляет около десяти миллисекунд
Отказоустойчивость
Используя механизм репликации, Kafka обрабатывает сбои на узлах кластера без потери данных
Надежность
Apache Kafka — это распределенная платформа с очень высокой отказоустойчивостью, что делает ее очень надежной в использовании системой
Сохранность данных
Реплики данных, хранящихся в кластере Kafka, распределены по разным серверам, при падении или сбое одного сервера копии остаются на других..
Обработка данных в реальном времени
Архитектура Apache Kafka
Рассмотрим архитектуру Apache Kafka и взаимосвязь между различными архитектурными компонентами, чтобы точнее понять Kafka для распределенной потоковой передачи.
На курсе [ Kafka Fundamentals ] мы поможем вам изучить инструмент с нуля до уверенного пользователя на реальных задачах за 7 недель.
Компоненты Apache Kafka и ее архитектурные концепции:
1. Topic
Поток сообщений, который является частью определенной категории или названия канала, называется топиком Kafka. В Kafka данные хранятся в виде топиков. Producer записывают свои данные в топик, а consumer читает данные из этого топика
2. Broker
Кластер Kafka состоит из одного или нескольких серверов, известных как брокеры. В Kafka брокер работает как контейнер, который может содержать несколько топиков с разными partitions. Уникальный ID используется для идентификации брокера в кластере Kafka. Подключение к любому из брокеров Kafka в кластере подразумевает подключение ко всему кластеру
3. Producer
Producers в Kafka публикует сообщения в одном или нескольких топиков. Они отправляют данные в кластер Kafka
4. Consumer and Consumer
GroupConsumers читает данные из кластера Kafka. Данные, которые должны быть прочитаны Consumers, получаются от брокера. Consumer group в Kafka объединяет несколько consumers, таким образом, что каждый consumer читает часть сообщений определенного топика
5. Partition
Топик в Kafka разделен на настраиваемое количество частей, которые называются partitions. Partition разделяет топик по нескольким брокерам, таким образом снижая нагрузку на каждый отдельный сервер. Consumers могут быть объединены в consumer group, и тогда один сonsumer может получать сообщения не из всего топика, а только из некоторых его partitions, что обеспечивает распределение нагрузки на обработку сообщений
6. Partition Offset
Сообщения или записи в Kafka относятся к partition, каждой записи присваивается число — offset, чтобы определить положение в partition. Запись идентифицируется в своем partition с помощью значения offset. Offset partition имеет значение только для этого конкретного partition. Для старых записей будут меньшие значения offset, поскольку записи добавляются в конец partition
7. Replicas
Реплики похожи на резервную копию partition в Kafka. Используется для предотвращения потери данных в случае сбоя или планового отключения и размещаются на нескольких серверах в кластере Kafka
Вы узнаете:
— Что такое messaging system
— Что включает в себя архитектура Kafka
— Методы разворачивания docker образа
— Как пользоваться Kafka CLI
— Основы Kafka API
— Области применения Kafka
+ Практический блок: создание Java producer и Java consumer
Посмотрите нашу
лекцию по Kafkа
БЕСПЛАТНУЮ
Недостатки Apache Kafka
Изменение сообщений внутри Kafka не предусмотрено и приводит к проблемам с производительностью. Kafka хорошо подходит только для случаев, когда сообщение не нужно менять.
В Kafka нет поддержки выбора топика по регулярным выражениям. Название топика должно быть точным (в отличие от RabbitMQ, например).
Некоторые парадигмы передачи сообщений, такие как p2p очереди и request/response сообщения не поддерживаются Kafka.
Для больших сообщений требуется сжатие и распаковка сообщений. Это влияет на пропускную способность и производительность Kafka.
Сравнение различных брокеров сообщений (сравнения Redis, Kafka, RabbitMQ)
Какой брокер когда лучше использовать?
Мы рассмотрели некоторые характеристики RabbitMQ, Kafka и Redis. Все трое устроены и работают совершенно по-разному. Вот наша рекомендация по выбору правильного брокера сообщений в зависимости от различных сценариев использования.
Сообщения с коротким временем жизни: Redis
In-memory база данных Redis почти идеально подходит для передачи сообщений, которые не требуется сохранять на диск. Redis чрезвычайно быстро обрабатывает сообщения в памяти и поэтому является идеальным кандидатом для сообщений с маленьким временем жизни, когда можно позволить себе потерять некоторое количество данных
Большие объемы данных: Kafka
Kafka — это распределенная очередь с высокой пропускной способностью, созданная для хранения и передачи большого количества данных в течение длительных периодов времени
Сложная маршрутизация: RabbitMQ
RabbitMQ — более старый и зрелый брокер с множеством функций и возможностей, поддерживающий сложную маршрутизацию. Он способен поддерживать сложную маршрутизацию, даже при высокой скорости передачи сообщений (больше нескольких десятков тысяч сообщений в секунду)
Технологический стек проекта
Также нужно учитывать ваш текущий стек проекта. Если вы ищете относительно простой процесс интеграции, то не стоит добавлять еще одну очередь сообщений в проект, лучше использовать ту что уже есть.
Например, если вы используете Celery для очереди задач в своей системе поверх RabbitMQ, у вам будет проще работать с RabbitMQ, а не с Kafka, которую еще придется ставить и настраивать
Присоединяйтесь к нам в INSTAGRAM
Соглашение на обработку персональных данных
Присоединяясь к настоящему Соглашению и оставляя свои данные на Сайте Hard&Soft Skills, путем заполнения полей онлайн-заявки (оформления заказа) Пользователь:
– подтверждает, что указанные им персональные данные принадлежат лично ему; признает и подтверждает, что он внимательно и в полном объеме ознакомился с настоящим Соглашением и содержащимися в нем условиями обработки его персональных данных, указываемых им в полях онлайн заявки (регистрации) на Сайте;
– признает и подтверждает, что все положения настоящего Соглашения и условия обработки его персональных данных ему понятны;
– дает согласие на обработку Сайтом предоставляемых персональных данных в целях регистрации Пользователя на Сайте;
– выражает согласие с условиями обработки персональных данных без каких-либо оговорок и ограничений.
Пользователь дает свое согласие на обработку его персональных данных, а именно совершение действий, предусмотренных законом «О персональных данных» Республики Беларусь, и подтверждает, что, давая такое согласие, он действует свободно, своей волей и в своем интересе. Согласие Пользователя на обработку персональных данных является конкретным, информированным и сознательным.
Настоящее согласие Пользователя применяется в отношении обработки следующих персональных данных:
– фамилия, имя, отчество;
– номера телефонов;
– адресах электронной почты (E-mail);
– данные о профессиональных навыках.
Пользователь, предоставляет сервису https://hardsoftskills.by право осуществлять следующие действия (операции) с персональными данными:
– сбор, накопление и хранение данных;
– уточнение (обновление, изменение);
– использование в целях регистрации Пользователя на Сайте;
– удаление.
Указанное согласие действует бессрочно с момента предоставления данных и может быть отозвано Вами путем обращения через «Форму обратной связи» или по e-mail info@hardsoftskills.by .
Сайт имеет право вносить изменения в настоящее Соглашение. При внесении изменений будет указываться дата последнего обновления.
Последнее обновление: 05/04/2021
Правила оплаты и безопасность платежей
Оплата банковскими картами осуществляется через ЗАО «Альфа-Банк»
К оплате принимаются карты международных платежных систем VISA, MasterCard, платежной системы БЕЛКАРТ. Оплату также можно совершить посредством сервисов Apple Pay, Samsung Pay.
Безопасность совершения платежа обеспечивается современными методами проверки, шифрования и передачи данных по закрытым каналам связи.
Ввод данных карточки осуществляется на защищенной авторизационной странице банка. Для оплаты необходимо ввести реквизиты карточки: номер, имя держателя, срок действия и трехзначный код безопасности. Трёхзначный код безопасности (CVV2 для VISA, CVC2 для MasterCard) — это три цифры, находящиеся на обратной стороне карточки. Если карточка поддерживает технологию 3DSecure или Интернет-пароль для держателей карточек БЕЛКАРТ, Вы будете перенаправлены на страницу банка, выпустившего карточку, для ввода кода безопасности. При оплате с помощью Apple Pay выберете карту из приложения Wallet, воспользуйтесь код- паролем или иным способом аутентификации, в зависимости от того, какой способ выбран в приложении. При оформлении заказа с помощью Samsung Pay нажмите «Оплатить Samsung Pay», введите ваш Samsung Account и подтвердите покупку на вашем смартфоне (по отпечатку пальца, радужке или PIN-коду Samsung Pay).
Данные карточки передаются только в зашифрованном виде и не сохраняются на данном интернет-ресурсе.
ВОЗВРАТ ПЛАТЕЖЕЙ
При оплате банковской платежной карточкой возврат наличными денежными средствами не
допускается. Расчеты с потребителем при возврате уплаченной за товар денежной суммы, при
расторжении договора о выполнении работы (оказании услуги) осуществляются в той же форме, в которой производилась оплата товара, работы (услуги), если иное не предусмотрено соглашением сторон. Порядок возврата регулируется правилами платежных систем.
Процедура возврата товара регламентируется Законом Республики Беларусь от 9 января 2002 г. N 90-З «О защите прав потребителей».
Потребитель вправе отказаться от товара в течение 14(четырнадцати) дней с момента
передачи ему товара;
Потребитель вправе в одностороннем порядке отказаться от исполнения договора о
выполнении работы (оказании услуги) при условии оплаты исполнителю фактически
понесенных им расходов, если иное не предусмотрено законодательством.
Требование потребителя об обмене либо возврате качественного товара подлежит
удовлетворению, если товар не был в употреблении, сохранены его потребительские
свойства и имеются доказательства приобретения его у данного продавца.
Перечень непродовольственных товаров надлежащего качества, не подлежащих обмену и
возврату, утверждается Правительством Республики Беларусь.
Для возврата денежных средств на банковскую платежную карточку необходимо заполнить
«Заявление о возврате денежных средств» и отправить его по электронному адресу
info@hardsoftskills.by.
Возврат денежных средств будет осуществлен на банковскую платежную карточку в течение 7
(семи) календарных дней со дня получения «Заявление о возврате денежных средств» Компанией.
Сумма возврата будет равняться сумме покупки
Для возврата денежных средств по операциям проведенными с ошибками необходимо
обратиться с письменным заявлением и приложением чеков/квитанций,
подтверждающих ошибочное списание. Данное заявление необходимо направить по электронному адресу info@hardsoftskills.by.
What is a consumer group in Kafka?
When sending messages in a distributed setup using a messaging system, you typically have two scenarios you want to achieve. Either you want to:
- send a message to a targeted group of consumers (which might be just one consumer) or
- broadcast the message to all the consumers
Kafka allows you to achieve both of these scenarios by using consumer groups.
Consumer group
A consumer group is a group of consumers (I guess you didn’t see this coming?) that share the same group id. When a topic is consumed by consumers in the same group, every record will be delivered to only one consumer. As the official documentation states: “If all the consumer instances have the same consumer group, then the records will effectively be load-balanced over the consumer instances.”
This way you can ensure parallel processing of records from a topic and be sure that your consumers won’t be stepping on each other toes.
How does Kafka achieve this?
Each topic consists of one or more partitions. When a new consumer is started it will join a consumer group (this happens under the hood) and Kafka will then ensure that each partition is consumed by only one consumer from that group.
So, if you have a topic with two partitions and only one consumer in a group, that consumer would consume records from both partitions.
After another consumer joins the same group, each consumer would continue consuming only one partition.
Does it mean if I want to have more than one consumer (from the same group) reading from one topic I need to have more than one partition?
That is correct. If you have more consumers in a group than you have partitions, extra consumers will sit idle, since all the partitions are taken. If you know that you will need many consumers to parallelize the processing, then plan accordingly with the number of partitions.
When we talked about topics and partitions, I mentioned that a partition is a unit of parallelism from the consumer’s perspective. Now you know the reason – there is a direct link between the number of partitions and number of consumers from a group reading in parallel.
What if I want to consume the same record from multiple consumers?
That is also possible. You can have many consumers reading the same records from the topic, as long as they all have different group ids.
An example to recap
Let’s illustrate what we’ve been talking about with an example.
Let’s say we’re building an online store and it consists of few microservices that are sending events to each other: payment service, shipping service, and notification service. Once the payment service processes the payment it will send an event PaymentProcessed as a record on Kafka topic. Then we want both the shipping service and notification service to consume this record. The shipping service needs the record in order to start the shipping process, while the notification service wants to receive this record so it could send an email to the customer saying ‘Your payment has been received‘. In this case, we want the PaymentProcessed record to be broadcasted to all the consumers.
Yet, if we have multiple instances of the consuming services, we always want exactly one of the instances to process each record. For example, we wouldn’t want multiple instances of the notification service to process the PaymentProcessed record and send multiple ‘Your payment has been received’ emails to the customer. Nor would we want multiple instances of shipping service to receive the same PaymentProcessed record and start the shipment process multiple times, potentially losing us money.
To ensure the record reaches both the shipping and the notification service but only once, we would put all the payment service instances in one consumer group and put all the notification service instances in another consumer group.
This ensures that all the records are always read by both shipping_group and notification_group, but within those groups, one record will always go to only one instance. That’s what consumer groups enable us to do.
A consumer group and record offset
If you remember when we talked about topics, we said that each record is uniquely identified by an offset in the partition. These offsets are used to track which record has been consumed by which consumer group.
Kafka employs an approach of ‘a dumb pipeline, smart clients’ meaning that Kafka brokers don’t know anything about consumer offsets. The consumers themselves are in charge of tracking which records have been consumed. Once the consumer reads the record it will store this offset in a special Kafka topic called __consumer_offsets (yes, those are two underscores at the beginning). When a consumer stores the offset in this topic we’re saying that it’s committing the offset.
This enables consumers to always know which record should be consumed next from a given partition. Since the consumer offset is stored in Kafka, it means that the position of the consumer group is maintained even after restarts.
In the topic post, I also mentioned that records remain in the topic even after being consumed. This allows multiple consumers to consume the same message, but it also allows one more thing: the same consumer can re-consume the records it already read, by simply rewinding its consumer offset. This is very useful when you e.g. had a bug in your consumer and want to re-read the records after fixing the bug.
And there you have it, Kafka consumer groups in a nutshell.
Would you like to learn more about Kafka?
I have created a Kafka mini-course that you can get absolutely free. Sign up below and I will send you lessons directly to your inbox.