Django会话

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

如果您不打算将数据库用于系统的任何其他部分，那么文件系统后端是唯一值得关注的。如果您使用的是数据库，那么文件系统后端没有任何build议。

memcache后端比数据库后端快得多，但运行会话被清除的风险和一些会话数据丢失。

如果你真的是一个真正的高stream量的网站和代码仔细，所以你可以应付丢失一个会话，然后使用memcache。如果您不使用数据库，则使用文件系统caching，但几乎所有情况下，默认数据库后端都是最好，最安全和最简单的选项。

我不是Django的专家，所以这个答案是关于会话商店的。 Downvote，如果我错了。

性能和可伸缩性

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

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

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

会话存储的select也将影响部署您的网站是多么容易。改变默认设置会花费一些复杂性。 Memcached和RDBMS都有自己的复杂性，但是您的应用程序可能会使用RDBMS。

除非你有一个非常stream行的应用程序，否则简单应该是更大的关注。

另一种方法是将会话数据存储在cookie中（全部不仅仅是一个ID）。这具有会话存储自动按用户数量扩展的优点，但也有缺点。您（或您的框架）需要小心，以阻止用户伪造会话数据。您还需要保持每个会话的小，因为整个事情将随每个请求一起发送。

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

这将会话存储在caching中（仅用于memcached），并将其写回到数据库。如果已经退出caching，它将从数据库中读取。

尽pipe这比使用memcached存储会话要慢，但是它为会话添加了持久性。

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

select会话后端时必须考虑的一件事是“会话数据被修改的频率”？如果会话数据在每个请求上被修改，那么即使是具有中等stream量的站点也将受到影响，使得许多数据库访问来存储和检索数据

在我以前的工作中，我们独占地使用了memcache作为会话后端，它工作得很好。我们的pipe理团队非常努力地将两个特殊的memcached实例作为一个稳定的工具，但是在初始设置之后，我们没有任何会话后端操作的中断。

如果数据库具有不是您的DBA，则可能不允许使用数据库支持的会话（仅作为前端事宜）。直到django支持轻松地合并来自多个数据库的数据，以便您可以在一个单独的数据库中拥有像会话和用户消息（django.contrib.auth中的消息也存储在数据库中）这样的前端特定的东西，您需要保留这一点。