четверг, 3 апреля 2014 г.

Google App Engine - система авторизации и аутентификации пользователей. Регулируем и экономим.

Еще раз возвращаюсь к Google App Engine и обдумыванию реализации авторизации и аутентификации пользователей на сайте.
Конечно, можно предположить, что все наши посетители - пользователи Google и на этом сильно сэкономить :), однако предположим, что большинство из них не обладает учеткой Google, либо не хочет светить ее и акцептировать наш сайт.

Возьмем все труды по ведению базы пользователей на себя.
При традиционной реализации, с учетом, что надо сделать надежную систему, накладные ресурсы будут расти как на дрожжах.
А потому введем некоторые ограничения.
Система будет работать на основе сессий. Сессия будет генерироваться и записываться в кукис браузера пользователя только после прохождения аутентификации на сайте.
Этот момент уже убирает нагрузку по работе с БД. Ну, точнее расходы, связанные с операциями с БД.
Кукис с сессией должен иметь разумный срок хранения в пределах суток - устанавливая его длительность можем регулировать "расходы".
Кукис должны удаляться принудительно только при выходе из системы самим пользователем или автоматически при истечении срока хранения (скажем - сутки).
Далее..
Допустим, пользователь залогинился, походил и отошел.. кукис еще в браузере.
При заходе на сайт имеем ситуацию - пускать его автоматом в "кабинет" или заставлять логиниться?
Тут мы должны определиться для себя на сервере - незакрытые сессии мы храним, ну или считаем активными в течение допустим суток!
Какие накладные "расходы" в этом случае?
Мы должны обновлять маркер времени активности пользователя. Он находится в БД. Как сэкономить?
Использовать Memcache конечно. Изначально, мы доверяем нашему Memcache, так как никто кроме нас туда "залезть" не может.
То есть и временную метку мы будем хранить тамже, как и сессию и логин.
Тогда, расходы по считыванию из БД у нас возникнут только при сбросе Memcache.
Рабочий момент - обновлять метку времени в самой БД, если она удовлетворяет правилу - не больше суток dt не нужно.
В таком варианте обновление БД и расходы будут только когда дельта времени уже выйдет за дозволенные рамки. И только тогда нам необходимо будет обновлять метку сессии и времени. А это уже черевато либо логином, либо "доверяем" - хотя есть еще варианты.
Имеем гарантированный "расход" на запись только при:
Аутентификации.
Выходе из системы.
Просрочке метки времени в БД более установленного нами интервала.

Регулируется нагрузка на БД в нашем варианте двумя параметрами - времени жизни кукис и разрешенным интервалом активности сессии на сервере.
Регулируя первый - изменяем количество запросов на чтение.
Регулируя второй параметр - количество запросов на запись.

Борьба с ботами и зловредами монтируется отдельно. Варианты есть.

Комментариев нет:

Отправить комментарий