Как стать автором
Обновить

Как мы упростили жизнь высоконагруженным сервисам с Platform V SessionsData. Часть 2

Время на прочтение6 мин
Количество просмотров1.4K
Всего голосов 10: ↑10 и ↓0+10
Комментарии9

Комментарии 9

Лучше расскажите зачем ваш сберонлайн просит 300+ запросов со страницы.. что там такого? Какой-то треш и угар, особенно на деревенских скоростях соединения в 56кбод .. :(

Ребят, давайте по делу. Согласен, это боль, но она не относится к теме статьи.

Мало того, что минусуетеЮ, так ещё и врете внаглую! Вопрос НАПРЯМУЮ относится как в вашей "новой" микросервисной архитектуре, так и тематике этой статьи. Сначала насоздавали себе проблем, потом выпускаете статью "как мы себе упростили"?

Что "упростили"-то? Уберите эту безмозглую тучу из 300+ запросов, и опаньки .. много "нагрузки" слиняет в кусты.. Может Вам ПОКАЗАТЬ список этих 300+ запросов, да раскодировать те JS, которые там запрашиваются на потеху читателям?

.. sbsans.woff2 dhjlt вроде бы шрифт .. с какого лешего он подгружается ТРИЖДЫ?

.. index.js -- 6(шесть!!!) раз подряд.

И это только зашел по ключу, ещё ничего даже нажать не успелось. Каждая(!!!) иконка грузится .. отдельно и самостоятельно. Про различные собственные и сторонние(!) метрики, ваще молчу..

позорище, а не разработка..

Статья про backend.

Отставить негатив про frontend!

Правая рука не знает что творит левая? ;) Бывает..

Интересно: при балансировке учитывается ли текущая очередь задач мастер-узла?
по тексту понял, что сначала RoundRobin, а далее sticky session. Или тут без магии?

При создании каждой новой сессии запросы распределяются по мастер-узлам равномерно с помощью RoundRobin балансировки.

А запросы в рамках уже созданной сессии (прочитать/записать данные) идут строго в тот мастер-узел, где сессия была создана. Вот здесь уже используется sticky session.

В продакшене постоянно есть нескончаемый поток как первых запросов, так и вторых, поэтому RoundRobin и sticky session работают параллельно (в разных запросах).

тут как раз все понятно. но процессорная стоимость задачи может быть разная, а следовательно может сложится так, что один из мастер - узлов обрабатывает 100 "тяжелых" задач при этом остальные инстансы мастер-узлов в этот же момент имеют - 0 задач. Тут кажется удачным, пока исключить мастер-узел_100_задач из балансировки на время.
или такой проблемы нет т.к. асинхронность позволяет об этом не думать?

Такой проблемы нет, потому что:

  1. Очень много сессий в online (в СберБанк Онлайн полмиллиона-миллион). И все они равномерно распределены по мастер-узлам.

  2. Абсолютное большинство сессий всё-таки более-менее однородные (в пляне "тяжести" создаваемой нагрузки).

Поэтому нагрузка, создаваемая такими сессиями, очень равномерно нагружает CPU на всех мастер-узлах кластера.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий