mongodb Django 会话

Django Sessions

提问by Dave

I'm looking at sessions in Django, and by default they are stored in the database. What are the benefits of filesystem and cache sessions and when should I use them?

我正在查看 Django 中的会话，默认情况下它们存储在数据库中。文件系统和缓存会话有什么好处，我应该什么时候使用它们？

回答by Andrew Wilkinson

The filesystem backend is only worth looking at if you're not going to use a database for any other part of your system. If you are using a database then the filesystem backend has nothing to recommend it.

如果您不打算将数据库用于系统的任何其他部分，则文件系统后端仅值得查看。如果您使用的是数据库，那么文件系统后端没有什么值得推荐的。

The memcache backend is much quicker than the database backend, but you run the risk of a session being purged and some of your session data being lost.

memcache 后端比数据库后端快得多，但您可能会面临会话被清除和某些会话数据丢失的风险。

If you're a really, really high traffic website and code carefully so you can cope with losing a session then use memcache. If you're not using a database use the file system cache, but the default database backend is the best, safest and simplest option in almost all cases.

如果您是一个非常非常高流量的网站，并且要仔细编写代码以应对丢失会话的情况，那么请使用 memcache。如果您不使用数据库，请使用文件系统缓存，但在几乎所有情况下，默认数据库后端都是最好、最安全和最简单的选择。

回答by Will Harris

I'm no Django expert, so this answer is about session stores generally. Downvote if I'm wrong.

我不是 Django 专家，所以这个答案通常是关于会话存储的。如果我错了，请投反对票。

Performance and Scalability

性能和可扩展性

Choice of session store has an effect on performance and scalability. This should only be a big problem if you have a very popular application.

会话存储的选择对性能和可伸缩性有影响。如果您有一个非常流行的应用程序，这应该只是一个大问题。

Both database and filesystem session stores are (usually) backed by disks so you can have a lot of sessions cheaply (because disks are cheap), but requests will often have to wait for the data to be read (because disks are slow). Memcached sessions use RAM, so will cost more to support the same number of concurrent sessions (because RAM is expensive), but may be faster (because RAM is fast).

数据库和文件系统会话存储（通常）都由磁盘支持，因此您可以廉价地拥有大量会话（因为磁盘便宜），但请求通常必须等待数据被读取（因为磁盘很慢）。Memcached 会话使用 RAM，因此支持相同数量的并发会话将花费更多（因为 RAM 很昂贵），但可能更快（因为 RAM 很快）。

Filesystem sessions are tied to the box where your application is running, so you can't load balance between multiple application servers if your site gets huge. Database and memcached sessions let you have multiple application servers talking to a shared session store.

文件系统会话与您的应用程序运行所在的盒子相关联，因此如果您的站点变得庞大，您将无法在多个应用程序服务器之间进行负载平衡。数据库和 memcached 会话让您可以让多个应用程序服务器与共享会话存储进行通信。

Simplicity

简单

Choice of session store will also impact how easy it is to deploy your site. Changing away from the default will cost some complexity. Memcached and RDBMSs both have their own complexities, but your application is probably going to be using an RDBMS anyway.

会话存储的选择也会影响部署站点的难易程度。改变默认设置会增加一些复杂性。Memcached 和 RDBMS 都有自己的复杂性，但您的应用程序可能无论如何都将使用 RDBMS。

Unless you have a very popular application, simplicity should be the larger concern.

除非您有一个非常流行的应用程序，否则应该更关注简单性。

Bonus

奖金

Another approach is to store session data in cookies(all of it, not just an ID). This has the advantage that the session store automatically scales with the number of users, but it has disadvantages too. You (or your framework) need to be careful to stop users forging session data. You also need to keep each session small because the whole thing will be sent with every request.

另一种方法是将会话数据存储在 cookie 中（所有这些，而不仅仅是一个 ID）。这样做的优点是会话存储会随着用户数量自动扩展，但也有缺点。您（或您的框架）需要小心阻止用户伪造会话数据。您还需要将每个会话保持在较小的范围内，因为整个内容将随每个请求一起发送。

回答by Anthony Batchelor

As of Django 1.1 you can use the cached_db session back end.

从 Django 1.1 开始，您可以使用 cached_db 会话后端。

This stores the session in the cache (only use with memcached), and writes it back to the DB. If it has fallen out of the cache, it will be read from the DB.

这将会话存储在缓存中（仅与 memcached 一起使用），并将其写回数据库。如果它已经从缓存中掉出来，它将从数据库中读取。

Although this is slower than just using memcached for storing the session, it adds persistence to the session.

尽管这比仅使用 memcached 存储会话慢，但它为会话增加了持久性。

For more information, see: Django Docs: Using Cached Sessions

有关更多信息，请参阅：Django 文档：使用缓存会话

回答by zgoda

One thing that has to be considered when choosing session backend is "how often session data is modified"? Even sites with moderate traffic will suffer if session data is modified on each request, making many database trips to store and retrieve data.

选择会话后端时必须考虑的一件事是“会话数据多久修改一次”？如果每次请求修改会话数据，即使是中等流量的站点也会受到影响，从而进行多次数据库访问以存储和检索数据。

In my previous work we used memcache as session backend exclusively and it worked really well. Our administrative team put really great effort in making two special memcached instances stable as a rock, but after bit of twiddling with initial setup, we did not have any interrupts of session backends operations.

在我之前的工作中，我们专门使用 memcache 作为会话后端，它运行得非常好。我们的管理团队非常努力地使两个特殊的 memcached 实例稳定如磐石，但在对初始设置进行了一些调整后，我们没有任何会话后端操作的中断。

回答by kaleissin

If the database have a DBA that isn't you, you may not be allowed to use a database-backed session (it being a front-end matter only). Until django supports easily merging data from several databases, so that you can have frontend-specific stuff like sessions and user-messages (the messages in django.contrib.auth are also stored in the db) in a separate db, you need to keep this in mind.

如果数据库的 DBA 不是您，则可能不允许您使用数据库支持的会话（这只是前端问题）。直到 django 支持轻松合并来自多个数据库的数据，以便您可以在单独的数据库中拥有前端特定的东西，如会话和用户消息（django.contrib.auth 中的消息也存储在数据库中），您需要保持这记在心上。