在没有 ACID 数据库的情况下处理会话？
我正在考虑使用 noSQL (mongoDB) 与 memcached 配对来在我的 web 应用程序中存储会话。这个想法是，在每次页面加载时，都会将用户数据与 memcache 中的数据进行比较，如果发生更改，数据将写入 memcached 和 mySQL。这样，读取次数将大大减少，并且可以利用 memcached 来做它最擅长的事情。
然而，我有点担心使用非 ACID 数据库进行会话存储，尤其是 memcached 层。假设在将会话更新到数据库时出现问题，我们的用户立即头痛，想知道为什么他们放入购物车的产品没有显示......
对此有什么合适的方法？我们应该选择 mySQL 会话存储还是为会话保留非酸性支持数据库？
谢谢！
I am thinking about using a noSQL (mongoDB) paired with memcached to store sessions with in my webapp. The idea is that upon each page load, the user data is compared to the data in the memcache and if something has changed, the data would be written to both memcached and mySQL. This way the reads would be greatly reduced and memcached utilized to do what it does best.
However I am a bit concerned about using a non-ACID database for session storage especially with the memcached layer. Let's say something goes wrong while updating the session to the DB and our users got instant headache wondering why their product that they put in the cart doesn't show up...
What's an appropriate approach to this? Should we go for a mySQL session storage or is it fine to keep a non-acid supportive database for sessions?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我目前使用 MongoDB 作为会话存储。可以避免 pilif 提到的竞争条件。我找到了一个为 MongoDB 实现会话处理程序的类 (http://www.jqueryin.com /projects/mongo-session/）并在 github 上分叉以满足我的需求（http:// github.com/halfdan/MongoSession）。
I'm using MongoDB as session storage currently. It is possible to avoid race conditions mentioned by pilif. I found a class that implements a session handler for MongoDB (http://www.jqueryin.com/projects/mongo-session/) and forked it on github to suit my needs (http://github.com/halfdan/MongoSession).
如果您不想丢失数据，请坚持使用经过 ACID 测试的数据库。
您正在寻找什么回报？
如果您想要一个安全的系统，则不能信任用户的任何内容，除了可能选定的整数之外，因此让他们存储信息通常是一个非常糟糕的主意。
我没有看到将会话存储在 MySQL 数据库之外的好处。如果您担心的话，您可以对表进行 cron 清理，但为什么要麻烦呢？有些用户会在网站上购物，然后会暂时分心。他们会在一两天后回来。
如果您使用 cookie 或临时的东西来存储他们的会话信息，那么他们的购物时间很有可能被浪费。用户真的很珍惜他们的时间......所以如果你将他们的会话信息存储在数据库中，你可以编写一些有趣的东西来管理这些数据。
另外，这样做的一个好处是，您将生成大量有关人们喜欢您网站上的内容的残留信息，而您以后可能无法获得这些信息。就像您甚至可以将其中的一些视为民意调查或人们添加到购物车的商品可能会影响您管理业务、订购库存或集中营销的方式。
如果你选择一些非常暂时的东西，那么你就会失去获得剩余利益的机会。
If you don't want to lose your data, stick with ACID tested databases.
What's the payoff you're looking for?
If you want a secure system, you can't trust anything from the user, save for perhaps selected integers, so letting them store the information is typically a really bad idea.
I don't see the payoff for storing sessions outside of your MySQL database. You can cron cleanup on the tables if that's your concern, but why bother? Some users will shop on a site and then get distracted for a while. They would then come back a day or two later.
If you use cookies or something really temporary to store their session info, there is a really good chance their shopping time was wasted. Users really value their time... so if you stored their session info in the database, you can write something sexy to manage that data.
Plus, the nice side effect of this is that you'll generate a lot of residual information about what people like on your website that wouldn't perhaps be available to you later on. Like you could even consider some of it to be like a poll or something where the items people are adding to their cart could impact how you manage your business, order inventory or focus your marketing.
If you go with something really temporary then you lose out on getting residual benefits.
如果不对会话进行任何锁定，请务必非常小心您存储的内容。永远不要存储任何依赖于您之前读取的内容的内容，因为数据可能会在您读取和写入之间发生变化 - 特别是在 ajax 的情况下，多个请求可以同时发出。
例如，您不得在非锁定会话中存储购物车，因为要添加产品，您必须读取、反序列化、添加产品，然后再次序列化。如果任何其他请求在第一个请求读取和写入之间执行相同的操作，您将丢失第二个请求的数据。
有关详细信息，请参阅这篇文章： http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/
将会话保留在您的文件系统上（PHP 为您锁定它们），在您的数据库中（如果该值是从先前的读取中派生的，则永远不要将任何有价值的内容写入会话。
Without any locking on the session, be really, really careful of what you are storing. Never ever store anything that is dependent on what you have read before as the data might change between you reading and writing - especially in case of ajax where multiple requests can go out at once.
An example what you must not store in a non-locked session would be a shopping cart as, to add a product, you have to read, unserialize, add the product and then serialize again. If any other request does the same thing between the first requests read and write, you lose the second request's data.
Have a look at this article for detail: http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/
Keep Sessions on your filesystem (where PHP locks them for you), in your database (where you have to do manual locking) or never, ever, write anything of value to your session if that value is derived of a previous read.
在使用memcached作为数据库的缓存时，需要保证数据库和缓存之间的数据一致性的是用户。如果您想要扩展并添加更多服务器，即使一切看起来都正常，也有可能与数据库不同步。
相反，您可以考虑 Hazelcast。从 1.9 开始，它还支持 memcache 协议。与 memcached 相比，Hazelcast 希望您实现 Map Persister 并且仅自身更新数据库更新的条目。这样您就不必处理“检查缓存，如果数据更改则更新数据库”之类的事情。
While using memcached as a cache for database, it is the user who have to ensure the data consistency between database and cache. If you'll want to scale up and add more servers there is a probability to be out of sync with database even if everything seems ok.
Instead you may consider Hazelcast. As of 1.9 it also supports memcache protocol. Compared to memcached Hazelcast wants you to implement Map Persister and only itself updates the database for the updated entries. This way you don't have to handle "check cache, if data changed update database" kind of stuff.
如果您编写应用程序以便用户在客户端存储所有会话信息，那么您只需根据需要验证该信息，而无需担心服务器端的会话。这是 REST 风格架构的原则之一。例如，如果用户请求将商品添加到购物车，只需存储 itemID 列表并在客户端进行计数即可。当您点击购物车页面时，您可以轻松地从他们告诉您在购物车中的 itemID 列表中查找商品信息。
在结帐期间，直接针对数据库进行交易，以确保您不会遇到任何竞争条件，并检查您的实时库存。如果他们结账时没有库存，只需说：“抱歉，我们刚刚卖完了”。当然，此时您应该去更新所有告诉人们您有库存的缓存。
If you write your app so that the user stores all session information client side, then you just verify that information as needed, you won't need to worry about sessions on the server side. This is one of the principles in REST style architecture. For instance, if the user is requesting adding an item to their shopping cart, just store the itemID list and count on the client side. When you hit the cart page, you can easily look up the item information from the list of itemIDs they are telling you are in their cart.
During checkout, go directly against the database with transactions to ensure you aren't getting any race conditions, and check your live inventory. If inventory isn't there when they go to check out, just say, "sorry, we just sold out". Of course, at that point you should go update any caches you have out there that are telling people you have inventory.
我会看看用户购买的成本是多少，然后问实施一个真正好的系统的成本是多少。请记住，用户是一种生物重试方法。 “我很无聊……再次按重新加载……”虽然，这不是最完美的解决方案，但与“永远不会丢失任何东西”的成本比较相比，它有时是可以接受的。
如果您想要额外的安全性，可以将会话缓存到一组单独的内存缓存服务器，这样就不会出现意外刷新。 :)
还有许多其他系统 membase.org 以及其他一些持久性 memcache 解决方案（java 实现）将存储持久存储到磁盘。如果您想稍微修改客户端或访问内存缓存的方式，您可以自己复制内存缓存会话对象。
-丹尼尔
I would look at how much the user costs to acquire and then ask what is the cost for implementing a really good system. Keep in mind that users are a biological retry method. "I'm bored... press reload again..." While, this isn't the most perfect solution, it is sometimes acceptable vs the cost comparsion for "not lose anything - ever".
If you want additional security, you can have your sessions cached to a separate set of memcache servers so there are no accidental flushes. :)
There are a number of other systems membase.org, and some other persistent memcache solutions (java implementations) that will persist storage to disk. If you want to modify your client somewhat, or how you access memcache, you can do your own replication of memcache session objects.
-daniel