#php #yii #mongodb #highload #масштабирование
Для одного из PHP + MongoDB проектов возникла необходимость осуществления горизонтального масштабирования. Учитывая, что будет использоваться несколько серверов, как лучше реализовать актуальность своих же скриптов? Разные мелочи появляются довольно часто, как бы их из одного централизованного хранилища сразу везде обновлять? sshfs, или gluster, или есть более простые способы? В идеале хотелось бы иметь где-то директорию с ядром проекта, которое бы использовалось напрямую остальными серверами. Кэширование сейчас организовано в файловой системе, но, как я понимаю, будет необходимо делать его общим для всех серверов. Как это делать лучше? Завести ещё одну БД под кэш, или как-то ещё "выкручиваться"? Особенность у нас - в кэше есть данные общим объёмом в несколько гигабайт, которые изменяются от силы раз в год, а используются чуть ли не каждую минуту, именно из-за этого когда-то кэш не стали делать в redis. Как с такими данными быть, тоже в БД? И какую БД для этого выбрать? Правильно ли я понимаю, что при горизонтальном масштабировании сессии тоже необходимо хранить в БД?
Ответы
Ответ 1
Использовать сетевое хранилище для исходников - не самая лучшая идея. Каждый раз когда появляются разные мелочи - они должны пройти тестирование в отдельном окружении и только после этого следует использовать скрипт развертывания (deployment) актуальной версии и только на одном сервере, - после чего при помощи a/b-тестирования убедиться, что все работает как нужно. И только после того как все изменения протестированы, - запускать скрипт развертывания на остальных серверах. Использование файлового хранилища для исходников возможно, но это выглядит как неоправданная жертва стабильности в угоду удобству. Чем не подошел кэш в redis? - Несколько ГБ данных не создаст для него проблемы. Или вы имеете в виду, что одна запись в кэшэ занимает несколько ГБ ? - В таком случае следует разделить легкий и тяжелый кэш на раздельные сервисы. Нет. При горизонтальном масштабировании вы можете привязать пользователя к определенному серверу с которым он будет работать, в частности это используется для a/b-тестирования. В любом случае хранить сессии в реляционной БД не нужно, - они очень хорошо лежат в memcached.
Комментариев нет:
Отправить комментарий