можно еще вспомнить, что гугл игнорирует точки в логине(не для google apps) т.е. user@gmail.com & u.s.e.r@gmail.com & u.ser@gmailcom будут приходить на один ящик
забавный другой момент, мне доставка мелкого пакета Челябинск — Харьков вышла 250р, и это только доставка, вопрос, как китайцы умудряются за 33р отправлять с бесплатной доставкой и еще при этом иметь выгоду?
до того, как пользователь начнет грузится в кэш, будет проверено, не залогинен ли пользователь уже, если да, то кука будет изменена, и пользователь попадет на нужный сервер.
да, конечно в режиме HTTP работает.https трафик тоже на прокси разбирается и по http идет на frontend
про много кук не понял, можно пояснить?
смотрится значение куки, и в зависимости от значения, направляется на нужный сервер, если не валидное значение, то на случайный север отправляется, и frintend выставит нужное значение
P.S. у нас на проекте сложилась, такая терминология: backend — 40 сервисов, которые обеспечивают поставку и прочее, frontend — сайт, который генерирует пользовательскую ленту, прокси — балансирует нагрузку между серверами frontend.
в процессе подготовки к релизу, был составлен список что может упасть:
-picture store — мы планировали использовать DFS, но после не тестов выяснилось, что там иногда начинает тупить репликация — не справляться. было решено вынести сохранение картинок на уровень приложения(краулер пытается сохранить картинку на диск на оба сервера), не очень красивое решение, но оно оправдано тем, что у нас нет файлового хранилища
-haproxy — если пользователь был залогинен, прокси могла выставить куку на рандомный сервер, решили выносом логики выставления куки на фронтэнд
-CDN первый наш CDN падал, в итоге перешли на cloudfare но там была проблема, что брался один из из списка, в итоге на picture store навешали NLB что бы внешний IP был общий
— Была проблема с логикой старта ВМ, в некоторых случаях(теоретических), у нас могла пропасть внутреняя сеть, но остаться внешняя сеть, в данном случае ВМ стартовали и поулчалось, например что раббита у нас было 2 на одном адресе после восстановления сети… что есть плохо
— с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.
во время тестирования, параллельно смотрели как себя ведет система для конечного пользователя. Самое страшное для нас это падение SQL основного, тогда даунтайм будет до 15-30 минут, остальное для пользователя проходит не заметно. SQL кластер, было бы лучше равернуть, но он упирается в отсутствие файлового хранилища
фактически пользователь попадает всегда на один и тот же фронтэнд, если он находится в работоспособном состояние, а прокси направляет его на нужный, в зависимости от куки. Если фронтэнд упадет, то пользовательская сессия пропадает, в случае падения прокси переключение составляет в пределах 1-5с, Пользователь должен попадать на тот же сервер т.к. генерация индивидуальной ленты на лету требует ресурсов и у нас их нет лишних. При логине, мы, конечно, проверяем на каком сервере уже залогинен пользователь.
проблемы были разные, начиная от некорректных условий переключения на резервный SQL до проблемы, что CDN, что он продолжал стягивать картинки с отключенного сервера статики. про какую часть проблем подробнее рассказать?
в статье небольшая неточность есть, а именно: haproxy еще установлен heartbeat, который контролирует, что все IP, на которых весит сайт находятся на живой ноде. т.е. в случае падение одной из проксей, внешний упавшей IP будет авотматически поднят на другой проксе
забавный другой момент, мне доставка мелкого пакета Челябинск — Харьков вышла 250р, и это только доставка, вопрос, как китайцы умудряются за 33р отправлять с бесплатной доставкой и еще при этом иметь выгоду?
про много кук не понял, можно пояснить?
смотрится значение куки, и в зависимости от значения, направляется на нужный сервер, если не валидное значение, то на случайный север отправляется, и frintend выставит нужное значение
P.S. у нас на проекте сложилась, такая терминология: backend — 40 сервисов, которые обеспечивают поставку и прочее, frontend — сайт, который генерирует пользовательскую ленту, прокси — балансирует нагрузку между серверами frontend.
-picture store — мы планировали использовать DFS, но после не тестов выяснилось, что там иногда начинает тупить репликация — не справляться. было решено вынести сохранение картинок на уровень приложения(краулер пытается сохранить картинку на диск на оба сервера), не очень красивое решение, но оно оправдано тем, что у нас нет файлового хранилища
-haproxy — если пользователь был залогинен, прокси могла выставить куку на рандомный сервер, решили выносом логики выставления куки на фронтэнд
-CDN первый наш CDN падал, в итоге перешли на cloudfare но там была проблема, что брался один из из списка, в итоге на picture store навешали NLB что бы внешний IP был общий
— Была проблема с логикой старта ВМ, в некоторых случаях(теоретических), у нас могла пропасть внутреняя сеть, но остаться внешняя сеть, в данном случае ВМ стартовали и поулчалось, например что раббита у нас было 2 на одном адресе после восстановления сети… что есть плохо
— с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.
во время тестирования, параллельно смотрели как себя ведет система для конечного пользователя. Самое страшное для нас это падение SQL основного, тогда даунтайм будет до 15-30 минут, остальное для пользователя проходит не заметно. SQL кластер, было бы лучше равернуть, но он упирается в отсутствие файлового хранилища
как будет время — сделаю фото отчет сборки/разборки/смазки/чистки...35 летняя пыль удручает