В дополнение ко всем этим ответам:
Если вы храните сессии в базах данных, убедитесь, что сборщик мусора сессий в PHP действительно активирован (это не относится к дистрибутивам, подобным Debian, они решили собирать сессии с помощью своего собственного cron и изменили php.ini, чтобы он никогда не запускал gc, поэтому проверьте session.gc_probability и session.gc_divisor). Основная проблема сессионного хранилища в базе данных состоит в том, что оно требует большого количества запросов на запись и большого количества противоречивого доступа к базе данных. Это отличный способ подчеркнуть сервер базы данных, как MySQL. Так что, имхо, лучше использовать другое решение, это позволит лучше соотнести чтение и запись в базе данных.
Вы также можете сохранить систему хранения файлов и просто разделить каталог файлов между серверами с NFS . Измените настройку session.save_path, чтобы использовать что-то отличное от /tmp. Но NFS по определению не самый быстрый способ использования диска. Предпочитаю memcached или mongodb для быстрого доступа.
Если единственное, что вам нужно для общего доступа между серверами, это Аутентификация , то вместо совместного использования реального хранилища сеансов вы можете поделиться учетными данными аутентификации. Как и система OpenId в SO, это то, что мы называем SSO, для веб-части у вас есть несколько решений, от OpenId до CAS и другие. Если данные объединяются на стороне клиента (ajax, ESI-gate), то вам не нужно общее хранилище данных сеанса на стороне сервера. Это позволит избежать одновременной записи 3 из 5 затронутых веб-приложений в общий сеанс. Другие методы совместного использования сеансов (база данных, NFS, даже memcached) в основном используются для обмена вашими данными между несколькими серверами, потому что инструменты балансировки нагрузки могут передавать ваш последовательный HTTP-запрос с одного сервера на другой, но если вы действительно имеете в виду параллельный сбор данных, вам действительно нужно учеба ССО.