Наглая ложь об асинхроне и понятное обьяснение

Чел в теме спрашивал о разнице асинхрона и синхрона. Увидел такой ответ

​

Увы у многих именно такое представление об асинхроне.

Обьясняю на пальцах. В коде есть 2 вида блокирующих функций, CPU bound и IO Bound (Input Output). Первый блокируют выполнение кода, так как ждут обработки задачи процессором компьютера как тором код запущен, к таким задачам относятся сортировки, отрисовки, поиск и другие математические операции, для которых выделяется процессорное время. IO bound задачи это те задачи, которые в основном ждут ответа (например от базы данных, или удалённого сервера через интернет). Асинхронный подход позволяет как раз таки не ждать ответа.

Это можно сравнить с человеком который отправляет письма. К примеру у него есть 100 друзей, и он хочет всем отправить приглашение на день рождение. В синхронном подходе это выглядит так:
1. Человек пишет письмо.
2. Человек отправляет пиьсмо первому другу.
3. Человек ждёт ответ.
4. Только после получения ответа он отправляет письмо второму другу.

В асинхронном подходе это работает так:
1. Человек пишет письмо.
2. Человек отправляет письмо первому другу
3. Человек не дожидаясь ответа пишет письмо второму другу
4. Человек отправляет письмо второму другу
и тд до 100.
5. Человек отправил все письма и идёт смотреть какие ответы ему пришли (на самом деле ответы могут приходить и в моменте пока он пишет письма, тогда он сможет прямо между написанием писем обрабатывать ответы)

Или так:
1. Человек пишет сразу 100 писем
2. Отправляет письма по одному не дожидаясь ответа
3. Ждёт ответов
4. Получает сразу 100 ответов.



Почему это не работает с CPU bound нагрузками? В этой аналогии уберём письма, есть просто человек который что то пишет. Если у нас будет 1 человек, то он может написать 1 письмо в минуту. Давай ему хоть сто бумажек сразу и проси писать по одной букве на каждой, скорость быстрее не станет, это и есть CPU bound нагрузка, человек не ждёт чего то, он всегда выполняет работу и у нас нет этого окна во время которого мы можем делать что то другое. В таком случаи нужно пригласить ещё 99 человек что бы они писали ещё 99 писем. Итого за 1 минуту они напишут 100 писем (на самом деле дольше из-за GIL).

Основной прикол в том, что асинхронный код выполняется в 1 потоке, то есть для этого не нужно нанимать 100 человек, как в случаи с паралельностью. Сегодня такой подход является наиболее правильным для io нагрузок, ведь сразу исчезают все проблемы с GIL, с ситуациями когда 2 потока обращаются к одному адресу памяти и тд.

Вывод: асинхронность это не паралельность. Задачи выполняются последовательно, просто пропускается огромное количество времени с ожиданием. Где это нужно? Рассмотрим 2 ситуации:
1. Парсер каталога интернет магазина.
Представим что есть некий каталог на 100 страниц. Нам нужно сделать 100 запросов, что бы спарсить целый каталог. В синхронном коде это будет выглядеть примерно так:
1. Запрос к 1 странице
2. Ожидание. (к примеру Запрос к 1 странице занимает 1 секунду)
3. Обработка результата.
4. Запрос к 2 странице
и тд.
В асинхронном подходе:
1. Создаём список из 100 запросов.
2. Отправляем эти 100 запросов по очереди.
3. Ждём ответ. (всё равно 1 секунду, на самом деле немного больше, ведь мы помним, что запросы отправлялись последовательно и принимаются так же последовательно, но сами запросы идут ровно 1 секунду причём все сразу)
4. Получаем 100 ответов и обрабатываем их все последовательно.

2. Многопользовательский сайт.
К примеру у нас есть сайт который предоставляет доступ пользователям для работы с нашим парсером каталогов из примера выше. Парсер у нас будет асинхронный, но вот сайт синхронный. Например сразу 2 пользователя решили создать задачу на парсинг.
1. Первый пользователь создаёт задачу на парсинг каталога.
2. Второй пользовтаель пытается создать, но ведь поток заблокирован первым пользователем, и второму необходимо ждать, пока задача первого будет выполнена.
3. Зада первого выполнена спустя 30 секунд (например)
4. Только после этого начнётся выполнение задачи второго, то есть 30 секунд пользователь ждал своей очереди.

В аснхронном же методе нам неважно сколько пользователей будет, пока первый пользователь ждёт свои 30 секунд, мы можем сгенерировать запросы для ещё 1000 пользователей и они тоже будут ждать не блокируя поток. По итогу никакой очереди на сайте не будет, и такой сайт у которого нет никакой CPU Bound нагрузки может работать с огромным количеством пользвателей в 1 потоке.

В случаи же когда на сайте есть CPU Bound нагрузка, уже следует разрабатывать систему очередей (к примеру на сайте который обрабатывает фотографии через ИИ, вычесления для которого выполняются в CPU/GPU на сервере). Поэтому на многих таких сайтах существует явная очередь, ведь ресурсы у сервера не бесконечные и он за 1 единицу времени может обработать какое то определённое количество фотографий. К примеру у него есть 4 потока, следовательно он может обработать 4 фотографии за единицу времени. Но если пользователей будет 5, то последний из них будет помещён в очередь на 1 место, следущий на второе и так далее.

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

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