Авторизация при горизонтальном масштабировании. Как адекватно реализовать?

Question

[Lomoson]

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

У меня получается, что нужно делать несколько коннектов к базам при одной загрузке страницы (как-то это не гуд) и дубли в таблицах юзеров

______________

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

Answer 1

[He11ion]

Это не горизонтальное масштабирование, если вы соединяетесь со всеми базами. Самый простой вариант - Вы должны по данным пользователя (id, логину, ip ...) определить нужную Вам БД и соединяться только с ней. Для этого используется(пишется) балансировщик соединений.

Comments

[Lomoson]

He11ion, скажите, пожалуйста, получается, что коннект к двум базам при загрузке каждой страницы это норм? кэш будет позже

[He11ion]

Lomoson: если Вы про масштабирование - нет. Балансировщик и несколько бд под ним - нормально.

[Lomoson]

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

[Назар Мокринский]

Анатолий K: Вот при чем тут сессии, и вообще "придется"?

Answer 2

[Юрий Ярош]

Можно почитать/посмотреть записи с различных конференций, посмотреть как шардят большие конторы.
1. Аутентификация != Авторизация
2. Нужно понимать что при горизонтальном масштабировании сервер не должен хранить состояний - обычно люди хранят данные сессии в просоленной куке, а не в базе.
3. Распределять нагрузку нужно в зависимости от текущей, соответственно должен производится мониторинг, и запросы должны отправляться на наименее нагруженный сервер
4. В куке сессии должен записываться IP cервера который обрабатывает запросы от текущего пользователя, а DNS в свою очередь должен отдавать адрес сервера который работает с данной сессией. Таким образом с одним пользователем может работать только один сервер, и между ними не нужно гонять никаких редиректов, но на первое время можно просто редиректить.
5. В случае с push-нотификациями, и кэшированием там вообще всё очень сложно и нужно крутить CQRS-ES, иногда нужно решать задачу консенсуса Raft'ом.

Comments

[Lomoson]

Юрий Ярош, большое спасибо за развернутый ответ)
Не рассматриваю вариант, что для одной группы пользователей база будет на разных серверах.
План такой:
При регистрации для компании создается на каком-то сервеке база, дальше все сотрудники компании работают с этой базой. А в главной базе храниться, например, имя базы, а конфиги на сервере.
Получается, что при первом обращении к странице нужно определить к какой базе коннектиться, а дальше работам как обычно. Скажите, пожалуйста, это так? Или как правильно для пользователей хранить инфу к какой базе ему коннектиться?

[Юрий Ярош]

Lomoson: ну значит у вас там нет горизонтального масштабирования и один общий фронт на несколько БД - просто бутылочное горлышко. Советую сначала разобраться, хотя бы, с нормализацией моделей базы.

[Lomoson]

Юрий Ярош, с нормализацией базы проблемы нет, тут инфы хватает. а вот источника с рецептами для неочевидных задач не хватает. методом проб и ошибок что-то можно написать, но велосипедов и так в жизни наизобретал, хочется что-бы код не стыдно было показать)

[Юрий Ярош]

Lomoson: про нормализацию БД все так говорят, а на практике у всех "четыре формы", и нету ни третей, ни четвёртой, про остальные две история умалчивает. Вводите tdd/bdd используйте шаблонные классы для CRUD'a, что бы не было одна табличка-один контроллер, и стыдно точно не будет.

[Lomoson]

Юрий Ярош, у меня это вторая версия проекта (в первой база была просто жесть) и много косяков в базе устранил. Может и не идеально, но ребятам показываю - говорят норм. BDD вводим, но этой методикой еще не проникся. Контроллеры будут тонкие, код разделяю на слои.

[Юрий Ярош]

Lomoson: могу сделать ревью модели, отправьте на почту [e-mail] skype void.nugget, желательно mysql-workbench. Нормальный TDD/BDD возможен когда тесты прогоняются менее чем 5-6 секунд, в php / python / ruby с этим куча проблем, а в java вообще ужасы.