Что плохого в том, чтоб хранить значение авторизации в memcached?
При процедуре авторизации, я генерирую token тем или иным образом привязанный к клиенту (каждая авторизация установит новый токен).
Пока что при проверке авторизации, мне приходится делать выборку записи из БД DB.sessions по IP и сверять токен из куки и токен из БД. Эта процедура делается каждый раз при вызове Auth->isAuth() (вызывается почти на каждой странице); Не будет ли считаться дурным тоном, если я буду делать копию записи из БД в мемкеш и первым делом доставать оттуда и сверять, и уже при неудачном поиске обращаться к БД, а по окончанию заносить в мемкеш?
Если я выдумал уж слишком ужасный алгоритм авторизации, поправьте меня!
P.S. у меня паранойя при работе с БД, и пытаюсь максимально уменьшить кол-во запросов, так как переживаю за скорость. Имеет ли право на жизнь эта паранойя?
В любом случае, это не какие-то важные данные.(по типу: информация о пользователе, которая не хранится в бд, но она нужна.)
Учитывая, что при авторизации создается каждый раз новый токен, использовать мемкеш - не есть плохо.
Данные стираются при перезагрузке сервера, но ведь авторизация займет пару секунд)
Да и к тому же, так проще будет(учитывая, что на каждой странице идет проверка).
1) Если хочется хранить токены в памяти - можно взять Redis, он отлично для этого предназначен.
Из мемкеша будут периодически теряться данные и придется городить огород с хождением в sql.
2) Стоит это все делать или нет - зависит от Ваших объемов и самого сервиса, насколько введение такой авторизации его ускорит. В неком сферическом случае я бы не парился если rps меньше 200-300
Дело в том, что я хочу найти полку куда можно складывать данные авторизации, дабы не бегать к БД вечно и на каждой странице. Обычные сессии php не особо подходит. Спасибо за ответ.
Александр Катков: я к тому что в 99% случаев Вы и так будете бегать к БД по другим вопросам и один сэкономленный запрос с выборкой по primary ключу ничего в производительности не изменит.
