Андрей Суховицкий
Андрей Суховицкий
  • 101
  • 132 177
Почему полезно иногда "наплодить" потоков
Больше постов о нагрузке с иллюстрациями на моем канале - t.me/andrey_threads
Видео рассказывает о блокирующих потоки операциях, пассивном ожидании потоков и рассказывает, когда может быть полезно сделать сильно больше потоков, чем ядер процессора. Мы вычисляем количество потоков, исходя из времени выполнения операций и желаемой пропускной способности.
Переглядів: 218

Відео

Потоки и многозадачность. Почему потоки стоит переиспользовать?
Переглядів 28614 днів тому
Регулярные посты о нагрузке, потоках и архитектуре с иллюстрациями на моем канале - t.me/andrey_threads Видео рассказывает о потоках, ядрах и вытесняющей многозадачности. Почему лучше переиспользовать потоки и другие дорогостоящие ресурсы? И что такое мультиплексирование? Смотрите в видео.
Consistent hashing, Rendezvous hashing | Вопросы собеседований
Переглядів 1,9 тис.Рік тому
Consistent hashing, Rendezvous hashing | Вопросы собеседований | Backend Developer Interview 3 ССЫЛКА НА КУРС: it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 11 сентября! Автор курса: Андрей Суховицкий Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем. Последние 4 года создаю и провожу авторские курсы по микросерви...
А как шардировать??? Часть 1 | Вопросы собеседований | Backend Developer Interview #2
Переглядів 2,2 тис.Рік тому
"А как шардировать??" | Вопросы собеседований | Backend Developer Interview #2 ССЫЛКА НА КУРС: it-es-course.getcourse.ru/main По промокоду ESCOURSE дополнительная скидка 10% до 11 сентября! Автор курса: Андрей Суховицкий Действующий разработчик ПО, работает над проектированием и разработкой высоконагруженных систем. Последние 4 года создаю и провожу авторские курсы по микросервисной архитектуре...
Ты используешь CAP-теорему НЕПРАВИЛЬНО! System design интервью
Переглядів 3,6 тис.Рік тому
Ты используешь CAP-теорему НЕПРАВИЛЬНО! System design интервью
Что сказать на собеседовании про обработку топика Kafka
Переглядів 9 тис.Рік тому
Что сказать на собеседовании про обработку топика Kafka
Реализация канала команд (point-to-point) в RabbitMQ
Переглядів 413Рік тому
Реализация канала команд (point-to-point) в RabbitMQ
Что сказать на собеседовании про паттерн Saga?
Переглядів 9 тис.Рік тому
Что сказать на собеседовании про паттерн Saga?
RabbitMQ - Порядок сообщений, масштабирование
Переглядів 1,2 тис.Рік тому
RabbitMQ - Порядок сообщений, масштабирование
Разбираем вопросы собеседования на Middle и Senior Developer | Backend Developer Interview #1
Переглядів 12 тис.Рік тому
Разбираем вопросы собеседования на Middle и Senior Developer | Backend Developer Interview #1
Транзакция по переводу денег. Two phase commit
Переглядів 1,9 тис.Рік тому
Транзакция по переводу денег. Two phase commit
Синхронность и асинхронность. Synchronous VS Asynchronous
Переглядів 2 тис.2 роки тому
Синхронность и асинхронность. Synchronous VS Asynchronous
Микросервисы и монолиты - что лучше и когда
Переглядів 6472 роки тому
Микросервисы и монолиты - что лучше и когда
Надежность, Масштабируемость и Производительность ваших приложений
Переглядів 9532 роки тому
Надежность, Масштабируемость и Производительность ваших приложений
6 - Архитектура с брокером сообщений. Kafka. RabbitMQ
Переглядів 1,6 тис.2 роки тому
6 - Архитектура с брокером сообщений. Kafka. RabbitMQ
6 - Надежность. Таймауты, retries, Circuit breaker, Resilience4j, speed control - window/rate limits
Переглядів 8242 роки тому
6 - Надежность. Таймауты, retries, Circuit breaker, Resilience4j, speed control - window/rate limits
5 - Синхронность / асинхронность. Процессы и потоки, закон Амдала. Пулы потоков, Executor service
Переглядів 1,2 тис.2 роки тому
5 - Синхронность / асинхронность. Процессы и потоки, закон Амдала. Пулы потоков, Executor service
4 - API compatibility, Protobuf. Document-oriented, relational and graph data models.
Переглядів 5202 роки тому
4 - API compatibility, Protobuf. Document-oriented, relational and graph data models.
3 - TCP, HTTP, REST - resource, URI, representation
Переглядів 9282 роки тому
3 - TCP, HTTP, REST - resource, URI, representation
2 - Практическое занятие Event storming
Переглядів 1,3 тис.2 роки тому
2 - Практическое занятие Event storming
1 - Архитектура, микросервисы и монолиты
Переглядів 2,8 тис.2 роки тому
1 - Архитектура, микросервисы и монолиты
2 - Domain driven design
Переглядів 1,1 тис.2 роки тому
2 - Domain driven design
ИТМО - Проектирование ПО - Лекция 18 - Messaging - RabbitMQ, Kafka
Переглядів 8762 роки тому
ИТМО - Проектирование ПО - Лекция 18 - Messaging - RabbitMQ, Kafka
ИТМО - Проект. ПО - Лекция 17 - Асинхронные сообщения. Брокер сообщений. Async messaging, brokers.
Переглядів 6892 роки тому
ИТМО - Проект. ПО - Лекция 17 - Асинхронные сообщения. Брокер сообщений. Async messaging, brokers.
ИТМО - Проект. ПО - Лекция 15 - API. Изменения API, совместимость. Форматы данных. Protocol buffers.
Переглядів 4582 роки тому
ИТМО - Проект. ПО - Лекция 15 - API. Изменения API, совместимость. Форматы данных. Protocol buffers.
ИТМО - Проект. ПО - Лекция 14 - Prometheus. Counter, Gauge, Summary, Histogram. Quantiles. Grafana
Переглядів 3,7 тис.2 роки тому
ИТМО - Проект. ПО - Лекция 14 - Prometheus. Counter, Gauge, Summary, Histogram. Quantiles. Grafana
ИТМО - Проект. ПО - Лекция 13 - Prometheus. Counter, Gauge. Запросы и агрегации. Grafana
Переглядів 1,8 тис.2 роки тому
ИТМО - Проект. ПО - Лекция 13 - Prometheus. Counter, Gauge. Запросы и агрегации. Grafana
ИТМО - Проектирование ПО - Лекция 12 - Надежное синхронное взаимодействие
Переглядів 8732 роки тому
ИТМО - Проектирование ПО - Лекция 12 - Надежное синхронное взаимодействие
ИТМО - Проектирование ПО - Лекция 11 - Межпроцессное взаимодействие. Thread pool, ExecutorService
Переглядів 6713 роки тому
ИТМО - Проектирование ПО - Лекция 11 - Межпроцессное взаимодействие. Thread pool, ExecutorService
ИТМО - Проектирование ПО - Лекция 10 - TCP протокол - устройство, проблемы, оптимизация
Переглядів 6683 роки тому
ИТМО - Проектирование ПО - Лекция 10 - TCP протокол - устройство, проблемы, оптимизация

КОМЕНТАРІ

  • @sukhoa
    @sukhoa 2 дні тому

    Больше постов о нагрузке с иллюстрациями на моем канале - t.me/andrey_threads

  • @jagobingIT
    @jagobingIT 15 днів тому

    Имхо, ненадёжно не делать компенсации у последней транзакции, т.к. когда-нибудь появился следующая n+1 транзакция и про n-ую забудут и не реализуют компенсацию

  • @mamonov01
    @mamonov01 16 днів тому

    С возвращением!🎉

  • @adwawdwad2499
    @adwawdwad2499 16 днів тому

    Очень круто рассказано

    • @sukhoa
      @sukhoa 16 днів тому

      спасибо!

  • @MikitaIsakau
    @MikitaIsakau 17 днів тому

    полезная информация, ждем больше видео и больше постов!

    • @sukhoa
      @sukhoa 17 днів тому

      Спасибо, буду стараться!

  • @alexborodin366
    @alexborodin366 17 днів тому

    если при синхронной репликации отдавать пользователю ОК только когда записали во все follower, тогда линеаризуемость вполне будет: следующее чтение, согласно линеаризации, должно происходить после успешной операции предыдущего, то есть уже к моменту завершения репликации

  • @timur.piftaev
    @timur.piftaev Місяць тому

    Просто огромнейшее спасибо за подобный материал в открытом доступе. Не поступил в итмо, но могу посмотреть лекции, кайф!)))) Еще вопрос - на каком курсе изучают эти лекции?

  • @bubbletubbe
    @bubbletubbe Місяць тому

    как по мне просто отлично, Юрка наверно половину не понял 😁 т.к. таких развёрнутых ответов на собесах не встретишь

  • @winter-lb7id
    @winter-lb7id 2 місяці тому

    Про снапшот конечно смешно, когда человек называет снимок всей таблы хорошим решением... Но он хотя бы говорит свою шизу, а что у остальных в головах - вообще не понятно

  • @ankofl
    @ankofl 2 місяці тому

    Как же тихо...

  • @АндрейСиманов-л3я
    @АндрейСиманов-л3я 3 місяці тому

    41:09 а разве фичу с весами нельзя добавить в Rendezvous hasing? например добавив суррогатный ключ? (обозначу его через 's') hash( K + "s1"+ '1') hash( K + "s1"+ '2') hash( K + "s1"+ '3') hash( K + "s1"+ '4') <- добавляем "сильную ноду 4" hash( K + "s2"+ '4') <- добавляем "сильную ноду 4"

  • @mertviy_games
    @mertviy_games 3 місяці тому

    в конце подвели итог - всё это знать прикольно, но в общем и не нужно xD

  • @dragvs
    @dragvs 3 місяці тому

    Речь шла про dead letter queue в одном месте, видимо. К сожалению, Kafka не поддерживает DLQ в отличие от AWS SQS, например. Но как отметили это хорошо работает при условии идемпотентности и ассоциативности, иначе начинается пляска с синхронизацией очередей.

  • @fischer960
    @fischer960 4 місяці тому

    О, Нифёдыч в it вкатился

  • @whazapbaz
    @whazapbaz 5 місяців тому

    За такое дизлайк по факту видео самореклама а информации по теме нет.

  • @SmadyarovBerik
    @SmadyarovBerik 5 місяців тому

    Топ!

  • @tsc472
    @tsc472 5 місяців тому

    Когда-то разбирался с этим вопросом, понял эту теорему совсем по-другому: 1) partitioning tolerance - это свойство переживать разрыв сети. Разрыв сети - это когда все узлы работают, но между ними возник split brain, который потом полечился. Да, сеть имеет свойство пропадать, поэтому распрелеленные системы не способные пережить разрыв сети нам не интересны. 2) availability - это способность сохранять работоспособность пока работает хотя бы один узел 3) consistency - это когда система возвращает одинаковый ответ на одинаковый запрос, независимо от узла, к которому обращаются. И раз P нужна всегда, то речь может идти о CP системах и AP системах. CP - это когда запись в одну ноду сразу дублируется во все ноды. Она не может быть available, т. к. если часть нод временно не ответит, то система должна прекратить обслуживать запросы (иначе с неответившей ноды могут прилететь неконсистентные данные) AP - это большая часть nosql субд: система будет отвечать "до последнего", но иногда данные могут быть устаревшими т. к. мы не синхронизируемся в момент записи и допускаем чтение когда часть нод лежит. На самом деле CA систему тоже можно представить: это зеркало их 2-х реляционных субд с двумя мастерами и синхронной репликацией. Все будет консистентно, умершая нода потом сможет накатить лог транзакций с живой и восстановиться, но вот split brain (когда ноды потеряли связь и продолжили работать не зная что вторая нода жива и тоже что-то пишет) эта схема не переживет.

    • @sukhoa
      @sukhoa 5 місяців тому

      Split brain это как раз таки не описание состояния partitioning tolerance, а описание partitioning tolerance и точно неконсистентных систем. Если кластер, скажем, поделился на две части и при этом смог выбрать лидера с обеих сторон и решить, что теперь он будет работать, как два независимых кластера. Availability - это не просто способность сохранять работоспособность пока работает хотя бы один узел, а обслуживать любые запросы на любой из нод кластера. Суть в том, что большинство статей описывают вообще не CAP теорему, а просто "в какую стороную больше склоняется система", быть доступной или быть консистентной в присутствии разрыва сети. Я прикладывал в описании конкретные работы, где вводилось понятие CAP теоремы, это академические работы, можете ознакомиться с ними, как с первоисточником.

  • @ДмитрийПечников-у7ш
    @ДмитрийПечников-у7ш 6 місяців тому

    Очень познавательно, спасибо!

  • @ДмитрийПечников-у7ш
    @ДмитрийПечников-у7ш 6 місяців тому

    Очень понятное объяснение, спасибо)

  • @Denis-sds
    @Denis-sds 6 місяців тому

    СОМНИТЕЛЬНО, но окэй

  • @levaryazan
    @levaryazan 6 місяців тому

    Отличное видео! Сейчас разбираюсь с метриками, очень такого не хватало.

  • @Квадрососисон-ш9у
    @Квадрососисон-ш9у 6 місяців тому

    Крутая лекция, спасибо! Из слайда, объясняющего работу WAL, осталось не очень понятно, что произойдёт, если отключится питание в момент, когда мы записали файл-сегмент с отсортированными данными из in-memory structure, но не успели подать команду discard offer flush. Получается WAL у нас останется заполненным после восстановления? Не произойдёт ли дублирования сегмента?

  • @YuriySamorodov
    @YuriySamorodov 7 місяців тому

    Отличный разбор. Спасибо! А разве репликация и наличие нескольких нод не подразумевает наличия сети, и соответственно, не допускает ее разделения (сегментации)?

    • @sukhoa
      @sukhoa 5 місяців тому

      спасибо) Да, конечно, любая система, где между узлами пролегает сеть является распределенной и, конечно, предполагает ситуация разрыва сети.

  • @HideDJeker
    @HideDJeker 7 місяців тому

    100 партиций на топик это конечно сильно и универсально, такое количество вероятно в любом кластере сделает меньший перформанс - каждая партиция файловый дескриптор, каждая партиция это усложнение этапа ребаланса, увеличивать партиции - норма, и да кафка ничего не сделает, обычно просто предупреждают и потом убеждаются что консюмер группы дошли до конца, а кто нет - его проблемы. К универсальному запасу в 100 и возможному экспоненциальному приросту нагрузки заранее невозможно подготовиться, в теории и со 100 партиций может придется апскейлится, если так страшно - то вы можете перелить данные в новый топик с новым количеством партиций.

  • @sukhoa
    @sukhoa 7 місяців тому

    Забыл поместить ссылку на курс :) Вот она - it-es-course.getcourse.ru/main. Мои мини-курсы можно увидеть на степике stepik.org/a/202085 и udemy - www.udemy.com/user/andrei-sukhovitskii/

  • @timurbaburin8668
    @timurbaburin8668 7 місяців тому

    Где комментарий

  • @ЛеонидКоролев-л5щ
    @ЛеонидКоролев-л5щ 7 місяців тому

    34:17 "Разобраться с Кибаной - это, наверное, минут 20 составит". Такой смешной лектор. Такие шутки отпускает - ухохочешься. Пусть идет за 20 минут KQL изучит. Приду - проверю.

  • @ЛеонидКоролев-л5щ
    @ЛеонидКоролев-л5щ 8 місяців тому

    Это студенты первого-второго курсов?

  • @cbrnt4157
    @cbrnt4157 8 місяців тому

    Кто писал кафку, с вики: 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.

  • @АлексейБондаренко-т8т

    Огонь. Пошел смотреть новую версию по метрикам.

  • @alext6083
    @alext6083 11 місяців тому

    Вы забыли упомянуть, что: 1 нужно решать вопрос консистентности, пока финалтная маленькая транзакция не закомичена, система находится в неконсистентном состоянии, и нужно уметь с зтим жить. 2 процесс отката маленьких транзакций иакде может обломаться, это собственно коррелирует с первыми вопросом. И с жтим также нужно уметь жить.

  • @alexshavlovsky7922
    @alexshavlovsky7922 11 місяців тому

    Распространенные бизнес ошибки - ошибка десериализации или валидации. распространеные технические ошибки - ошибки ввода/вывода при коммуникации с низлежащими сервисами, недоступность низлежащих сервисов, сетевые ошибки типа 502/503/504

  • @МихаилА-у3л
    @МихаилА-у3л 11 місяців тому

    Размазали видео почти на час, много воды (верю, что это препод из универа). Лучше идти по сценарию интервью и придерживаться ему.

  • @mamonov01
    @mamonov01 11 місяців тому

    Андрей, можете сказать пожалуйста название и модель вашего планшета?)

    • @sukhoa
      @sukhoa 11 місяців тому

      Да, конечно. Это Huion GT-133. Не могу его сильно рекомендовать, основная претензия в том, что у него довольно странный адаптер, который после нескольких месяцев использования разболтался, что приводит к отключению питания планшета переодически. В остальном неплох.

  • @jukovb111
    @jukovb111 11 місяців тому

    блиии максимально просто максимально кратко но максимально непонятно :) может на курсе расскажете?

    • @sukhoa
      @sukhoa 11 місяців тому

      :) расскажу, конечно!

  • @applemodus
    @applemodus 11 місяців тому

    Спасибо за лекцию

  • @applemodus
    @applemodus 11 місяців тому

    Спасибо за лекцию

  • @applemodus
    @applemodus 11 місяців тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @1apaladin
    @1apaladin Рік тому

    29:36 В графане есть версионирование бордов! Вкладка Versions в настройках самой борды

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @applemodus
    @applemodus Рік тому

    Спасибо за лекцию

  • @alexricher2554
    @alexricher2554 Рік тому

    Посмотрел на одном дыхании) Будучи джуном, пытался залететь на сеньора и мне задавали аналогичные вопросы. Теперь я более опытен, но все равно не знаю как подать некоторые вещи на собеседовании. А тут все довольно круто изложено и аргументировано: Андрей - вы очень крутой преподаватель и разработчик)