Привет, Хабр! Сегодня System Design интервью стало неотъемлемой и, пожалуй, самой трудной частью найма разработчиков. От кандидатов требуют за короткое время спроектировать условный YouTube, Google Drive или Telegram, способный выдерживать миллионные нагрузки, не падать при отказе дата-центров и отвечать пользователю за считанные миллисекунды. И здесь большинство разработчиков сталкивается с суровой реальностью. Сложность в том, что на собеседованиях дают задачи на проектирование масштабных распределенных систем, но реальным опытом их создания создания обладают немногие. Задача проектирования может быть решена несколькими способами и не имеет единственного правильного ответа: Одно и то же требование можно реализовать многими способами, и каждый будет иметь плюсы и минусы. Нужно уметь проектировать высоконагруженные системы, учитывая проблемы сети: задержки, сбои серверов, обеспечение согласованности данных и балансировку нагрузки. Также требуется разбираться во множестве технологий и понимать, когда и как их применять.

Поэтому на интервью кандидат часто совершает критические ошибки: не умеет собирать требования и путает функциональные рамки проекта с нефункциональными (SLA, RPS, масштабируемость). Не видит нюансов и узких мест, из-за чего архитектура рушится при первой же пиковой нагрузке. Пытается строить отказоустойчивость «на бумаге», не понимая, как выбранные базы данных или очереди сообщений будут вести себя в реальном облаке. Лучший способ разобраться в тонкостях проектирования распределенных систем и увереннее чувствовать себя на архитектурных секциях — это создать такую систему с нуля в виде пет-проекта. Этой публикацией я начинаю серию статей, целью которой является желание поделиться опытом создания такой системы с нуля. Начнем с проектирования архитектуры, далее шаг за шагом реализуем ее на языке Go, развернем в облаке и оценим производительность. Будем проектировать систему сокращения ссылок из классической книги по системному дизайну.

В предыдущей статье я рассматривал различные способы организации стековых корутин в языке Си. Эти сопрограммы имели чисто учебное значение так как вряд ли кто-то будет создавать генераторы последовательностей при помощи сопрограмм. Сегодня рассмотрим как писать стектовые корутины на С++ и создадим на их основе tcp сервер, обрабатывающий запросы от клиентов на основе опроса событий с использованием API мультиплексированного ввода-вывода epoll. Данная тема, на мой взгляд, является ключевой для понимания того, как функционируют современные серверные приложения, написанные при помощи таких библиотек как Boost Asio.

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

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

Под обычной я подразумеваю функцию, определённую синтаксисом языка, с указанием возвращаемого типа, имени функции, а также её параметров.

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

Обычная функция в Си передает управление вызывающему коду при помощи оператора return. При этом область стековой памяти, хранящая локальные переменные, больше не принадлежит функции. 

Когда речь заходит о корутинах (сопрограммах) на С++, большинство программистов вспоминает фреймворк coroutine_ts, появившийся в стандарте С++20. Многие даже не догадываются о том, что писать корутины можно было задолго до появления упомянутого стандарта. При этом можно было использовать не только С++, но и Си. Данной статьей я открываю серию, в которой хочу описать свой личный опыт изучения корутин и привести примеры их использования. Надеюсь мои статьи помогут начинающим разобраться в этой сложной и интересной теме.