Недавно меня очень удивили сообщив то, что в высоко нагруженных проектах нельзя использовать сессии и вместо них следует использовать собственные разработки с аналогичными алгоритмами. Т.е. допустим информация об авторизации должна храниться не в сессии, а в базе данных, а доступ к ней осуществляется по токену. По сути тоже самое, но как мне сообщили тут есть весомая разница с точки зрения производительности. Аргументировали повышение производительности тем, что высоко нагруженные проекты часто разносят на N-ое количество серверов в клауде и может случиться такое, что балансировщик нагрузки перекинет пользователя с одного сервера на другой, при этом должна пропасть сессия т.к. она уникальна для каждого сервера. 

Честно говоря такой ход дел меня сильно удивил и т.к. я очень плохо разбираюсь в вопросах свяханных с железом, очень хотелось бы получить комментарии людей более опытных по вышеизложенному.

Все правильно рассказали.

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

Вместе с тем. Есть возможность подключить Redis, как хранилище для сессий в рамках стандартного механизма.
А Redis в свою очередь поддерживает репликацию на несколько серверов.

Это сообщение отредактировал(а) Fortop - 22.5.2012, 12:44

Может ли Redis полностью избавить меня от возможных проблем, а разработчиков от необходимости знать как это работает внутри т.е. дальше работать с сессиями, как-будто сервер всего один?

тут не от Редиса зависит.
смотри, есть session_set_save_handler — там хоть с редисом связать можно, хоть с голубиной почтой 

Не проверял надежность поскольку не было такой необходимости.
Подключать именно так, как писал skyboy - через session_set_save_handler

В остальном работа не отличается от работы с обычными сессиями.

Интересно. Теоретически, если я плюну на безопасность и открою MySQL сервер наружу, то я могу легко организовать общую сессию для сайтов находящихся на разных серверах (но имеющих общий домен, на пример sport.ru & sub.sport.ru)?

да. тока на безопасность не плюй - ограничение по IP на этот порт в настройках фаервола 

Не проще-ли использовать как хранилище Memcached?

------------------------------------------
химические свойства меди

Это сообщение отредактировал(а) Muan - 5.1.2020, 19:16

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

Кстати, Redis на 0.5млн уников скурвился.
А мемкеш тянет

Правда и писались туда не только сессии, но и страницы кешировались.

Посмотри, отключена ли запись на диск. Редис по-умолчанию сбрасывает данные на диск. Это серьезно замедляет его работу.



Количество объектов в кеше не сказывается на производительности.



http://oldblog.antirez.com/post/redis-memc...-benchmark.html

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

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


Дело не количестве, а в объеме 

можно было два редиса поднять.

Можно было 
просто это был не первый случай сложностей с ним (например на другом проекте периодически отваливался коннект к БД при 50-100к запросов в секунду) и надоело их выявлять 

Я так понимаю это тестировали на 1 ноде?