Django会议

Answer 1

只有在您不打算将数据库用于系统的任何其他部分时，才值得查看文件系统后端。如果您正在使用一个数据库，那么文件系统后端就没有任何建议。

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

如果你是一个流量非常大的网站，你要小心地编写代码，这样你就可以处理掉一个会话，然后使用memcache。如果不使用数据库，请使用文件系统缓存，但默认的数据库后端在几乎所有情况下都是最好、最安全和最简单的选项。

Answer 2

从Django 1.1开始，您可以使用缓存的数据库会话后端。

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

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

有关详细信息，请参见：Django Docs: Using Cached Sessions

Answer 3

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

性能和可扩展性

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

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

文件系统会话被绑定到应用程序运行的框中，因此如果站点变大，则无法在多个应用程序服务器之间实现负载平衡。数据库和memcached会话允许多个应用程序服务器与共享会话存储对话。

简单

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

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

奖金

另一种方法是存储session data in cookies（所有这些，而不仅仅是ID）。这样做的优点是会话存储会随着用户数量的增加而自动扩展，但也有缺点。您（或您的框架）需要小心，以防止用户伪造会话数据。你还需要保持每一个会话都很小，因为每一个请求都会发送整个事件。