Обработка сессий без базы данных ACID?

Question

Я думаю об использовании noSQL (mongoDB) в паре с memcached для хранения сессий в моем веб-приложении. Идея состоит в том, что при каждой загрузке страницы пользовательские данные сравниваются с данными в memcache и, если что-то изменилось, данные будут записаны как в memcached, так и в mySQL. Таким образом, чтение будет значительно сокращено, а memcached используется для того, чтобы делать то, что он делает лучше всего.

Однако меня немного беспокоит использование базы данных не-ACID для хранения сессий, особенно со слоем memcached. Допустим, что-то идет не так при обновлении сеанса для БД, и у наших пользователей сразу возникает головная боль, гадающая, почему их продукт, который они положили в корзину, не появляется ...

Какой подход к этому подходит? Стоит ли нам использовать хранилище сессий mySQL или нормально хранить не-кислотную базу данных для поддержки сессий?

Спасибо!

Answer 1

В настоящее время я использую MongoDB для хранения сессий. Можно избежать условий гонки, упомянутых пилифом. Я нашел класс, который реализует обработчик сеанса для MongoDB (http://www.jqueryin.com/projects/mongo-session/)) и разветвил его на github, чтобы удовлетворить мои потребности (http://github.com/halfdan/MongoSession).

Answer 2

Я бы посмотрел, сколько пользователь покупает, а затем спросил, сколько стоит внедрение действительно хорошей системы. Имейте в виду, что пользователи представляют собой метод биологической повторной попытки. «Мне скучно ... снова нажмите« перезагрузить »...» Хотя это и не самое совершенное решение, иногда оно приемлемо по сравнению со сравнением стоимости «ничего не потерять - никогда».

Если вам нужна дополнительная безопасность, вы можете кэшировать свои сеансы на отдельном наборе серверов memcache, чтобы избежать случайных сбросов. :)

Существует ряд других систем membase.org и некоторые другие постоянные решения memcache (реализации java), которые сохранят хранилище на диск. Если вы хотите немного изменить свой клиент или получить доступ к memcache, вы можете выполнить собственную репликацию объектов сеанса memcache.

-daniel

Answer 3

Если вы не хотите потерять свои данные, используйте проверенные базы данных ACID.

Какую прибыль вы ищете?

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

Я не вижу отдачи от хранения сеансов за пределами вашей базы данных MySQL.Вы можете убирать cron на столах, если это ваше дело, но зачем?Некоторые пользователи делают покупки на сайте, а затем отвлекаются на некоторое время.Затем они вернутся через день или два.

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

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

Answer 4

Если вы пишете свое приложение так, что пользователь хранит всю информацию о сеансе на стороне клиента, то вы просто проверяете эту информацию по мере необходимости, вам не нужно беспокоиться о сеансах на стороне сервера. Это один из принципов архитектуры стиля REST. Например, если пользователь запрашивает добавление товара в свою корзину, просто сохраните список itemID и рассчитывайте на стороне клиента. Когда вы попадаете на страницу корзины, вы можете легко найти информацию об элементе из списка идентификаторов элементов, которые, по их словам, находятся в их корзине.

Во время оформления заказа идите непосредственно к базе данных с транзакциями, чтобы убедиться, что вы не получаете никаких условий гонки, и проверьте свой текущий инвентарь. Если инвентаря нет, когда они идут, чтобы проверить, просто скажите: «Извините, мы просто распродали». Конечно, в этот момент вам следует обновить все имеющиеся у вас кеши, которые сообщают людям, что у вас есть инвентарь.

Answer 5

При использовании memcached в качестве кеша для базы данных именно пользователь должен обеспечить согласованность данных между базой данных и кешем.Если вы захотите увеличить масштаб и добавить больше серверов, есть вероятность, что вы не будете синхронизированы с базой данных, даже если все будет хорошо.

Вместо этого вы можете рассмотреть Hazelcast .Начиная с версии 1.9 он также поддерживает протокол memcache.По сравнению с memcached Hazelcast хочет, чтобы вы реализовали Map Persister и обновляет базу данных только для обновленных записей.Таким образом, вам не нужно обрабатывать «проверять кеш, если данные изменились, обновлять базу данных».

Answer 6

Не блокируя сеанс, будьте очень, очень осторожны с тем, что вы храните. Никогда не храните ничего, что зависит от того, что вы прочитали ранее, поскольку данные могут меняться между вами при чтении и записи - особенно в случае ajax, когда несколько запросов могут отправляться одновременно.

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

Посмотрите на эту статью для деталей: http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/

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