![Андрей Суховицкий](/img/default-banner.jpg)
- Видео 98
- Просмотров 120 721
Андрей Суховицкий
Грузия
Добавлен 12 ноя 2014
КУРС EVENT SOURCING:
it-es-course.getcourse.ru/main
Автор курса: Андрей Суховицкий
Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем.
Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре, проектированию производительных систем и проектированию ПО в университете ИТМО и МФТИ.
В 2021 году получил награду как лучший преподаватель ИТМО.
it-es-course.getcourse.ru/main
Автор курса: Андрей Суховицкий
Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем.
Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре, проектированию производительных систем и проектированию ПО в университете ИТМО и МФТИ.
В 2021 году получил награду как лучший преподаватель ИТМО.
Consistent hashing, Rendezvous hashing | Вопросы собеседований
Consistent hashing, Rendezvous hashing | Вопросы собеседований | Backend Developer Interview 3
ССЫЛКА НА КУРС:
it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 11 сентября!
Автор курса: Андрей Суховицкий
Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем.
Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре, проектированию производительных систем и проектированию ПО в университете ИТМО и МФТИ.
В 2021 году получил награду как лучший преподаватель ИТМО.
0:57 Повторение подходов из прошлого видео
5:58 Rendezvous hasing алгоритм
13:40 Consistent hashing
21:45 Оптимизация Consistent hashing - VNode ...
ССЫЛКА НА КУРС:
it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 11 сентября!
Автор курса: Андрей Суховицкий
Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем.
Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре, проектированию производительных систем и проектированию ПО в университете ИТМО и МФТИ.
В 2021 году получил награду как лучший преподаватель ИТМО.
0:57 Повторение подходов из прошлого видео
5:58 Rendezvous hasing алгоритм
13:40 Consistent hashing
21:45 Оптимизация Consistent hashing - VNode ...
Просмотров: 1 518
Видео
А как шардировать??? Часть 1 | Вопросы собеседований | Backend Developer Interview #2
Просмотров 1,9 тыс.11 месяцев назад
"А как шардировать??" | Вопросы собеседований | Backend Developer Interview #2 ССЫЛКА НА КУРС: it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 11 сентября! Автор курса: Андрей Суховицкий Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем. Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре...
Ты используешь CAP-теорему НЕПРАВИЛЬНО! System design интервью
Просмотров 2,9 тыс.Год назад
Ты используешь CAP-теорему НЕПРАВИЛЬНО! System design интервью ССЫЛКА НА КУРС: it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 7 сентября! Ссылки на статьи и полезные ресурсы: 1. Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. Seth Gilbert, Nancy Lynch disk.yandex.ru/i/Tnv_ayuDPsYQEg 2. Типы консистентности/сог...
Что сказать на собеседовании про обработку топика Kafka
Просмотров 6 тыс.Год назад
Что сказать на собеседовании про обработку топика Kafka ССЫЛКА НА КУРС: it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 7 сентября! Автор курса: Андрей Суховицкий Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем. Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре, проектированию произво...
Реализация канала команд (point-to-point) в RabbitMQ
Просмотров 389Год назад
Реализация канала команд (point-to-point) в RabbitMQ
Что сказать на собеседовании про паттерн Saga?
Просмотров 7 тыс.Год назад
Что сказать на собеседовании про паттерн Saga?
RabbitMQ - Порядок сообщений, масштабирование
Просмотров 1,1 тыс.Год назад
RabbitMQ - Порядок сообщений, масштабирование
Разбираем вопросы собеседования на Middle и Senior Developer | Backend Developer Interview #1
Просмотров 11 тыс.Год назад
Разбираем вопросы собеседования на Middle и Senior Developer | Backend Developer Interview #1
Транзакция по переводу денег. Two phase commit
Просмотров 1,7 тыс.Год назад
Транзакция по переводу денег. Two phase commit
Синхронность и асинхронность. Synchronous VS Asynchronous
Просмотров 1,7 тыс.Год назад
Синхронность и асинхронность. Synchronous VS Asynchronous
Микросервисы и монолиты - что лучше и когда
Просмотров 622Год назад
Микросервисы и монолиты - что лучше и когда
Надежность, Масштабируемость и Производительность ваших приложений
Просмотров 891Год назад
Надежность, Масштабируемость и Производительность ваших приложений
6 - Архитектура с брокером сообщений. Kafka. RabbitMQ
Просмотров 1,5 тыс.2 года назад
6 - Архитектура с брокером сообщений. Kafka. RabbitMQ
6 - Надежность. Таймауты, retries, Circuit breaker, Resilience4j, speed control - window/rate limits
Просмотров 7612 года назад
6 - Надежность. Таймауты, retries, Circuit breaker, Resilience4j, speed control - window/rate limits
5 - Синхронность / асинхронность. Процессы и потоки, закон Амдала. Пулы потоков, Executor service
Просмотров 1,1 тыс.2 года назад
5 - Синхронность / асинхронность. Процессы и потоки, закон Амдала. Пулы потоков, Executor service
4 - API compatibility, Protobuf. Document-oriented, relational and graph data models.
Просмотров 4882 года назад
4 - API compatibility, Protobuf. Document-oriented, relational and graph data models.
3 - TCP, HTTP, REST - resource, URI, representation
Просмотров 8622 года назад
3 - TCP, HTTP, REST - resource, URI, representation
2 - Практическое занятие Event storming
Просмотров 1,3 тыс.2 года назад
2 - Практическое занятие Event storming
1 - Архитектура, микросервисы и монолиты
Просмотров 2,6 тыс.2 года назад
1 - Архитектура, микросервисы и монолиты
ИТМО - Проектирование ПО - Лекция 18 - Messaging - RabbitMQ, Kafka
Просмотров 8502 года назад
ИТМО - Проектирование ПО - Лекция 18 - Messaging - RabbitMQ, Kafka
ИТМО - Проект. ПО - Лекция 17 - Асинхронные сообщения. Брокер сообщений. Async messaging, brokers.
Просмотров 6472 года назад
ИТМО - Проект. ПО - Лекция 17 - Асинхронные сообщения. Брокер сообщений. Async messaging, brokers.
ИТМО - Проект. ПО - Лекция 15 - API. Изменения API, совместимость. Форматы данных. Protocol buffers.
Просмотров 4472 года назад
ИТМО - Проект. ПО - Лекция 15 - API. Изменения API, совместимость. Форматы данных. Protocol buffers.
ИТМО - Проект. ПО - Лекция 14 - Prometheus. Counter, Gauge, Summary, Histogram. Quantiles. Grafana
Просмотров 3,5 тыс.2 года назад
ИТМО - Проект. ПО - Лекция 14 - Prometheus. Counter, Gauge, Summary, Histogram. Quantiles. Grafana
ИТМО - Проект. ПО - Лекция 13 - Prometheus. Counter, Gauge. Запросы и агрегации. Grafana
Просмотров 1,7 тыс.2 года назад
ИТМО - Проект. ПО - Лекция 13 - Prometheus. Counter, Gauge. Запросы и агрегации. Grafana
ИТМО - Проектирование ПО - Лекция 12 - Надежное синхронное взаимодействие
Просмотров 8592 года назад
ИТМО - Проектирование ПО - Лекция 12 - Надежное синхронное взаимодействие
ИТМО - Проектирование ПО - Лекция 11 - Межпроцессное взаимодействие. Thread pool, ExecutorService
Просмотров 6562 года назад
ИТМО - Проектирование ПО - Лекция 11 - Межпроцессное взаимодействие. Thread pool, ExecutorService
ИТМО - Проектирование ПО - Лекция 10 - TCP протокол - устройство, проблемы, оптимизация
Просмотров 6562 года назад
ИТМО - Проектирование ПО - Лекция 10 - TCP протокол - устройство, проблемы, оптимизация
ИТМО - Проектирование ПО - Лекция 9 - Процессы, потоки - синхронизация и блокирование. Асинхронность
Просмотров 6812 года назад
ИТМО - Проектирование ПО - Лекция 9 - Процессы, потоки - синхронизация и блокирование. Асинхронность
Речь шла про dead letter queue в одном месте, видимо. К сожалению, Kafka не поддерживает DLQ в отличие от AWS SQS, например. Но как отметили это хорошо работает при условии идемпотентности и ассоциативности, иначе начинается пляска с синхронизацией очередей.
О, Нифёдыч в it вкатился
За такое дизлайк по факту видео самореклама а информации по теме нет.
Топ!
Когда-то разбирался с этим вопросом, понял эту теорему совсем по-другому: 1) partitioning tolerance - это свойство переживать разрыв сети. Разрыв сети - это когда все узлы работают, но между ними возник split brain, который потом полечился. Да, сеть имеет свойство пропадать, поэтому распрелеленные системы не способные пережить разрыв сети нам не интересны. 2) availability - это способность сохранять работоспособность пока работает хотя бы один узел 3) consistency - это когда система возвращает одинаковый ответ на одинаковый запрос, независимо от узла, к которому обращаются. И раз P нужна всегда, то речь может идти о CP системах и AP системах. CP - это когда запись в одну ноду сразу дублируется во все ноды. Она не может быть available, т. к. если часть нод временно не ответит, то система должна прекратить обслуживать запросы (иначе с неответившей ноды могут прилететь неконсистентные данные) AP - это большая часть nosql субд: система будет отвечать "до последнего", но иногда данные могут быть устаревшими т. к. мы не синхронизируемся в момент записи и допускаем чтение когда часть нод лежит. На самом деле CA систему тоже можно представить: это зеркало их 2-х реляционных субд с двумя мастерами и синхронной репликацией. Все будет консистентно, умершая нода потом сможет накатить лог транзакций с живой и восстановиться, но вот split brain (когда ноды потеряли связь и продолжили работать не зная что вторая нода жива и тоже что-то пишет) эта схема не переживет.
Split brain это как раз таки не описание состояния partitioning tolerance, а описание partitioning tolerance и точно неконсистентных систем. Если кластер, скажем, поделился на две части и при этом смог выбрать лидера с обеих сторон и решить, что теперь он будет работать, как два независимых кластера. Availability - это не просто способность сохранять работоспособность пока работает хотя бы один узел, а обслуживать любые запросы на любой из нод кластера. Суть в том, что большинство статей описывают вообще не CAP теорему, а просто "в какую стороную больше склоняется система", быть доступной или быть консистентной в присутствии разрыва сети. Я прикладывал в описании конкретные работы, где вводилось понятие CAP теоремы, это академические работы, можете ознакомиться с ними, как с первоисточником.
Очень познавательно, спасибо!
Очень понятное объяснение, спасибо)
СОМНИТЕЛЬНО, но окэй
Отличное видео! Сейчас разбираюсь с метриками, очень такого не хватало.
Крутая лекция, спасибо! Из слайда, объясняющего работу WAL, осталось не очень понятно, что произойдёт, если отключится питание в момент, когда мы записали файл-сегмент с отсортированными данными из in-memory structure, но не успели подать команду discard offer flush. Получается WAL у нас останется заполненным после восстановления? Не произойдёт ли дублирования сегмента?
Отличный разбор. Спасибо! А разве репликация и наличие нескольких нод не подразумевает наличия сети, и соответственно, не допускает ее разделения (сегментации)?
спасибо) Да, конечно, любая система, где между узлами пролегает сеть является распределенной и, конечно, предполагает ситуация разрыва сети.
100 партиций на топик это конечно сильно и универсально, такое количество вероятно в любом кластере сделает меньший перформанс - каждая партиция файловый дескриптор, каждая партиция это усложнение этапа ребаланса, увеличивать партиции - норма, и да кафка ничего не сделает, обычно просто предупреждают и потом убеждаются что консюмер группы дошли до конца, а кто нет - его проблемы. К универсальному запасу в 100 и возможному экспоненциальному приросту нагрузки заранее невозможно подготовиться, в теории и со 100 партиций может придется апскейлится, если так страшно - то вы можете перелить данные в новый топик с новым количеством партиций.
Забыл поместить ссылку на курс :) Вот она - it-es-course.getcourse.ru/main. Мои мини-курсы можно увидеть на степике stepik.org/a/202085 и udemy - www.udemy.com/user/andrei-sukhovitskii/
Где комментарий
34:17 "Разобраться с Кибаной - это, наверное, минут 20 составит". Такой смешной лектор. Такие шутки отпускает - ухохочешься. Пусть идет за 20 минут KQL изучит. Приду - проверю.
Это студенты первого-второго курсов?
Кто писал кафку, с вики: Kafka was originally developed at LinkedIn, and was subsequently open sourced in early 2011. Jay Kreps, Neha Narkhede and Jun Rao helped co-create Kafka.
Огонь. Пошел смотреть новую версию по метрикам.
Вы забыли упомянуть, что: 1 нужно решать вопрос консистентности, пока финалтная маленькая транзакция не закомичена, система находится в неконсистентном состоянии, и нужно уметь с зтим жить. 2 процесс отката маленьких транзакций иакде может обломаться, это собственно коррелирует с первыми вопросом. И с жтим также нужно уметь жить.
Распространенные бизнес ошибки - ошибка десериализации или валидации. распространеные технические ошибки - ошибки ввода/вывода при коммуникации с низлежащими сервисами, недоступность низлежащих сервисов, сетевые ошибки типа 502/503/504
Размазали видео почти на час, много воды (верю, что это препод из универа). Лучше идти по сценарию интервью и придерживаться ему.
Андрей, можете сказать пожалуйста название и модель вашего планшета?)
Да, конечно. Это Huion GT-133. Не могу его сильно рекомендовать, основная претензия в том, что у него довольно странный адаптер, который после нескольких месяцев использования разболтался, что приводит к отключению питания планшета переодически. В остальном неплох.
блиии максимально просто максимально кратко но максимально непонятно :) может на курсе расскажете?
:) расскажу, конечно!
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
29:36 В графане есть версионирование бордов! Вкладка Versions в настройках самой борды
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
я бы добавил ребятам redpanda еще как аналог кроля когда еще как не в студенчестве делать тесты и сравнения)
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
Спасибо за лекцию
Посмотрел на одном дыхании) Будучи джуном, пытался залететь на сеньора и мне задавали аналогичные вопросы. Теперь я более опытен, но все равно не знаю как подать некоторые вещи на собеседовании. А тут все довольно круто изложено и аргументировано: Андрей - вы очень крутой преподаватель и разработчик)
первый вопрос дичь. Деньги хранятся в виде дебита и кредита
Очень много воды, отвечал бы по сути уважаемый
Подскажите а как получить количество запросов в секунду т.е RPS верный ли такой запрос? sum by(vhost)(rate(allnginx_http_response_count_total{}[60s])) / 60
На самом деле вижу, что в вашем запросе используется функция rate и одновременно вы производите деление на 60, видимо, чтобы получить per second. prometheus.io/docs/prometheus/latest/querying/functions/#rate функция rate уже делает за вас по сути increate{..}[60s] / 60. Так что точно либо rate, либо 60 лишнее :)
Андрей, а как вы рисуете, можете подробнее рассказать, у вас открыта программа Sketchbook на Mac, но рисуете как будто на другом устройстве
Добрый день! Да, все верно, я рисую в Sketchbook, но на графическом планшете
@@sukhoa графический планшет? айпад что ли?
Классные лекции, очень много интересной информации, рассказывается живо. Но вот студенты совсем какие-то деревянные. Но, возможно, они просто ещё не понимают, что происходит
Где микросервисы , что за вода
а можно не на белом фоне слайды?
ну и муть
та чего, в банковских системах такое используется
Спасибо
Спасибо
Спасибо