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中的消息也存储在数据库中)这样的前端特定的东西,您需要保留这一点。