Как обрабатывать корутину с бесконечным циклом?

historydev, если уж правильно, то так

Корутина (сопрограмма) — это блок кода, который работает асинхронно, то есть по очереди.

То что называется горутины, по сути является и корутинами. Корутины есть почти в любом современном языке программирования (если не в любом). Это и те же async / await Rust, Promises в JS и так далее.

Как писать микросервисную архитектуру?

Дмитрий, спасибо за объяснение. Я честно не вижу применений этой архитектуре, но вы подпитали моё любопытство.

Как писать микросервисную архитектуру?

Дмитрий, спасибо за ответ!

Как писать микросервисную архитектуру?

Дмитрий, хорошо. Это я и спрашивал изначально. Я просто наслушался всяких спикеров из Avito, которые решали такие проблемы через саги. Но если это нормальная практика - я не против. Однако у меня вопрос. Вы сами реализовывали (работали в проекте с этим) взаимодействие одного сервиса с несколькими БД или это только ваши мысли?

Как писать микросервисную архитектуру?

Everything_is_bad, интересное решение. Однако, как Вы это себе представляете (я без грубости, правда интересно)? То есть нужно создать отдельный сервис, который пишет в очередь сообщений всё, что происходит с чатам с сообщениями в них? Тогда мы действительно уходим от блокировки чатов (правда теперь мы блокируем целую очередь, что не так эффективно, но зато мы прячем от программиста реализацию, вы же это имели в виду?) и полностью убираем проблему транзакций, но это решение выглядит странно (отдельный сервис для очереди). Если не отдельный сервис, то мы обязываем сервисы реализовывать эту функцию, как

получить запрос -> отправить его в очередь -> встать в ожидание ответа из очереди

Тут я уже не могу судить, так как не видел таких реализаций ни на одном докладе или литературе. Это нормальная практика?

Как писать микросервисную архитектуру?

Дмитрий, нам нужно хранить всех участников чата, чтобы не состоящие в нём люди не могли отправлять в него сообщения. По сути мы имеем базу данных чатов, каждый из которых хранит своих участников. И вот тут как раз и рождается мой вопрос. Мы должны реализовать взаимодействие с ней через сервис чатов и обязать программиста знать о транзакциях в этом сервисе и решать проблему утечки транзакций, или мы должны обязать программиста знать о базе данных чатов.

Как писать микросервисную архитектуру?

Everything_is_bad, без блокировок эта задача не вызывает проблем с производительностью, вы правы. Но она не отвечает бизнес требованиям (я не верю, что даже в гипотетическом мире разрешат отправку сообщений заблокированными пользователям). По сути у нас нет выбора: мы вынуждены ввести блокировки, чтобы приложение считалось рабочим. А вот дальше действительно надо решать проблему блокировки N пользователей, каждый из которых именно в этот момент отправил сообщение в этот чат, если такая проблема возникнет, конечно.

Как писать микросервисную архитектуру?

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

Как писать микросервисную архитектуру?

Everything_is_bad, я брал не реальную проблему, а просто представлял все пограничные состояния функции добавления сообщения. Почему запрос, пришедший позже, может вернуться раньше? Я нахожу этот вопрос странным. Есть много причин. Самая очевидная из них - запросы могут отправиться на две разные машины, у которых разные мощности и разная удалённость от машины с СУБД.

Как писать микросервисную архитектуру?

Дмитрий, Как минимум странно, что сервис содержит отдельную папку с названием service. Тогда это нужно называть по-другому, про это и вопрос.

Как писать микросервисную архитектуру?

Дмитрий, проблема в том, что без блокировок сообщение о том, что пользователь заблокирован, приходит раньше сообщения. Именно блокировка не позволит удалить пользователя до отправки им сообщения.

Как писать микросервисную архитектуру?

Everything_is_bad, дело в том, что я уже написал свою социальную сеть (в 10 классе). Там большой проект с несколькими СУБД, современными подходами и прочим. Сейчас я только поступаю в ВУЗ. Впервые податься на стажировку я смогу не раньше августа (мне исполнится 18), хочется чем то себя занять на 2 месяца. Писать ещё один монолит будто бы бессмысленно, так как ничего нового я не потрогаю.

Как писать микросервисную архитектуру?

Everything_is_bad, мне кажется, что блокировать меньше, чем список пользователей в одном чате, неэффективно (не отдельно же каждого пользователя выносить? Всю память на Futex и Mutex потеряешь). А сделать без блокировок, конечно, можно, если самому написать СУБД и гарантировать последовательное выполнение. Тот же Tarantool с его кооперативной многозадачностью может отнести конкретно этот чат и это сообщение в разные процессы или даже машины, и тогда мы встретим проблему. Транзакции нужны, тем более на одну строку чат они не критичны. Я, конечно, готов выслушать ваши предложения ниже.

Как писать микросервисную архитектуру?

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

Как писать микросервисную архитектуру?

Вторая вакансия на hh.ru среди "нет опыта" (осторожно, две картинки)

две картинки

Как писать микросервисную архитектуру?

Давайте представим ситуацию. Пользователь видит, что находиться в чате. Он отправляет сообщение. Параллельно администратор удаляет пользователя из чата. Мы не блокируем список участников, просто получая его. Пользователь в нём состоит, начинаем писать сообщение в базу. Параллельно пользователь удаляется из чата и администратор это видит. Сообщение записывается. Как итог, в чат приходит сообщение, что пользователь удалён, а следующее сообщение в чате от пользователя.

Как написать такой макрос?

Василий Банников, концепция верная. Но мне не хватило документации. Я прошерстил интернет, но не нашёл примеров подобных макросов, а библиотека syn не содержит примеров на такое, хотя и поддерживают Expr::Return. Не могли бы вы привести пример для такого?

Почему в этом коде значение под указателем перезаписывается?

Произошла какая-то магия, когда я решил вывести на экран в функции создания.
println!("data fd: {}, must be {fd}", data.fd);
После этого код внезапно заработал. Я попробовал вместо вывода использовать black_box, я снова поймал ошибку. У меня нет идей, с чем связана эта магия, и такой костыль меня не устраивает. Есть идеи?

Почему в Rust использую Tokio?

Василий Банников, выше D3lphi написал, что процессор будет занят переключением тредов. Не подтвердилось.

Почему в Rust использую Tokio?

D3lphi,

Спойлер: во втором случае если и удасться их заспавнить, то cpu будет занят лишь одним - переключением контекста с треда на тред.

Я провёл тест на 20 тысячах соединений. Я подключал 20 тысяч соединений к серверу и бесконечно ждал чтения из них. Я согласен, с тем, что Tokio подходит для этих задач лучше, так как он съел в 20 раз меньше памяти. Но я не согласен с нагрузкой на cpu. В обоих случаях она нулевая после старта.

Если делать вывод, то Tokio является лучшим решением для обработки миллионов соединений, так как потребляет меньше памяти. Однако производительность Tokio значительно уступает std.