Классный канал! На одном дыхании посмотрел про оптимизацию запросов, много нового для себя взял имея за плечами 12 лет опыта галер. Подписался бы бусти но я с Украины.
Почему ограничитель трафика работает после публикации сообщения в очередь? Разве в данном схеме не возникнет гонка? "ограничитель трафика" должен успеть отработать и поменять "состояние источника" прежде чем прилетит следующее сообщение. Если не успеет (тормоз/задержка), то в очередь попадет сообщение которое не должно было попасть. Не лучше ли поставить "ограничитель трафика" до публикации в очередь?
Если топик в кафке партицирован и ключ - идентификатор клиента, то все сообщения клиента попадут в один и тот же инстанс-кэнсьюмер ограничителя. Он читает топик пачками - скорость чтения высокая. Задержка обработки, конечно, есть, но она регулируется количеством партиций и количеством кэнсьюмеров в группе ограничителя. Да, регулировка трафика получается приближенная. Разбираем вариант с ограничителем до очереди. Приемник сообщений запущен в нескольких экземплярах. Один и тот же клиент может прислать свои сообщения в разные инстансы приемника. Как при приеме сообщения считать общее количество сообщений по клиенту? Придется при обработке каждого сообщения читать БД Состояния источников. Это замедлит обработку. В моем варианте обращение к БД происходит раз в какое-то время для обновления кеша в оперативной памяти. А при обработке сообщения достаточно этого кеша. Вывод. Противоречие между скоростью приема сообщений и точностью регулировки трафика. Мой вариант (ограничитель после кафки) дает максимальную скорость ценой приближенной регулировки. + есть способ настроить погрешность тестированием вариации числа кэнсьюмеров. В вашем варианте (ограничитель до кафки) регулировка точная, но будет ниже скорость приема сообщений. Видим частный случай CAP теоремы, когда приходится выбирать между доступностью и согласованностью. Если скорость приема низкая, то отсутствие ответа на какой-то запрос клиент может расценить, как недоступность системы. Если регулировка приближенная, то это несогласованность между сервисами (ограничитель знает, что уже достигнут лимит, а приемник еще не знает). То есть, мой вариант архитектуры про высокую доступность ценой уменьшения согласованности. А ваш вариант противоположный.
было очень интересно и полезно спасибо!
Классный канал! На одном дыхании посмотрел про оптимизацию запросов, много нового для себя взял имея за плечами 12 лет опыта галер. Подписался бы бусти но я с Украины.
Клево, спасибо!
Почему ограничитель трафика работает после публикации сообщения в очередь?
Разве в данном схеме не возникнет гонка? "ограничитель трафика" должен успеть отработать и поменять "состояние источника" прежде чем прилетит следующее сообщение. Если не успеет (тормоз/задержка), то в очередь попадет сообщение которое не должно было попасть.
Не лучше ли поставить "ограничитель трафика" до публикации в очередь?
Если топик в кафке партицирован и ключ - идентификатор клиента, то все сообщения клиента попадут в один и тот же инстанс-кэнсьюмер ограничителя. Он читает топик пачками - скорость чтения высокая. Задержка обработки, конечно, есть, но она регулируется количеством партиций и количеством кэнсьюмеров в группе ограничителя. Да, регулировка трафика получается приближенная.
Разбираем вариант с ограничителем до очереди. Приемник сообщений запущен в нескольких экземплярах. Один и тот же клиент может прислать свои сообщения в разные инстансы приемника. Как при приеме сообщения считать общее количество сообщений по клиенту? Придется при обработке каждого сообщения читать БД Состояния источников. Это замедлит обработку. В моем варианте обращение к БД происходит раз в какое-то время для обновления кеша в оперативной памяти. А при обработке сообщения достаточно этого кеша.
Вывод. Противоречие между скоростью приема сообщений и точностью регулировки трафика. Мой вариант (ограничитель после кафки) дает максимальную скорость ценой приближенной регулировки. + есть способ настроить погрешность тестированием вариации числа кэнсьюмеров. В вашем варианте (ограничитель до кафки) регулировка точная, но будет ниже скорость приема сообщений.
Видим частный случай CAP теоремы, когда приходится выбирать между доступностью и согласованностью. Если скорость приема низкая, то отсутствие ответа на какой-то запрос клиент может расценить, как недоступность системы. Если регулировка приближенная, то это несогласованность между сервисами (ограничитель знает, что уже достигнут лимит, а приемник еще не знает). То есть, мой вариант архитектуры про высокую доступность ценой уменьшения согласованности. А ваш вариант противоположный.
Спасибо
спасибо
Это не data science
Каждое твоё видео это просто золото, не ожидал что выкладывают видео на все эти темы. Есть ли у тебя советы что можно почитать?
Почитать на какие именно темы?
а что за прикольный рисователь схемок?
excalidraw