Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

Всем привет! Меня зовут Дима, я тимлид команды Яндекс Диска. Сегодня расскажу, как обрабатывать сотни терабайт загружаемого контента в день и быстро доставлять его в ленту со всеми фотографиями пользователя. Лента выглядит как локальная галерея на телефоне, но может содержать в себе сотни тысяч фотографий, хранящихся в облаке, и быстро переходить к любой точке среди огромного количества контента. 

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