digg（或其他高负载类别网站）如何存储用户会话？

Question

digg或任何其他高流量网站如何存储用户会话？ 他们用什么来存储用户会话？ 文件系统，DB（哪一个？），memcache或两者兼而有之？

让我们想象一个简单的情况。 登录用户在登录期间设置了“记住我”标记。 我们设置了一个会话cookie，其截止日期为1年。 例如，我们将会话保留在memcache中，但我们也应该在DB中保存此会话的记录（在我的版本中）。 只有具有“记住我”标志的用户才会存储在DB中。 这是存储会话的正确方法吗？ 我的意思是高流量网站，当然（有2个或更多应用服务器，2个或更多数据库，memecache服务器等）。 在小型网站中默认存储会话方式（在文件系统中）是可以的。

我试图搜索谷歌，但未能找到任何有关它的信息。 我已经从“高级PHP编程”一书中读到了一些解决方案，但主要的重点是自定义会话存储处理程序。

真的希望听到好的想法或链接！

谢谢。

Answer 1

除了Alix的回答，您可能有兴趣查看本文：

• 由Digg员工Memcached作为Sessions Store（等） （Nick：永恒）。

简短摘录：

是什么促使Memcached作为会话存储：

在推出Digg v3后不久，非冗余的MySQL会话存储硬件崩溃了。 这导致了Digg中断。 我们一直计划在这种情况下，我们只会进行一个（微不足道的）更改，将会话放入Memcached而不是MySQL，看看它是如何发展的。

---

那么，在您每次进行会话之前都要点击数据库之前？

是。

MySQL有足够的能力跟上插入和选择完成处理会话。 我们的问题实际上是清除旧会话。 删除旧会话的脚本尽管在尝试不重载会话数据库方面相当复杂，但仍然会影响它。

我们推测Memcached将以比MySQL更少的开销删除过期的会话。

---

我们使用InnoDB进行会话[在memcached之前]。 它不是表级或行级锁定。 这是操作系统级别的争用。 在MySQL面前使用Memcached将减少负载并允许管理脚本完成其工作，但这突出了一个问题：为什么甚至让MySQL背后都是memcached？ 我们不需要甚至不需要非易失性会话。 （读者重要提示：您可能需要或想要非易失性会话）。

“为什么甚至将MySQL放在memcached后面？”......“我们不需要甚至不需要非易失性会话”。

Answer 2

他们肯定使用memcached或等价物。

Answer 3

我的实现是，当用户点击记住我时，我放了另一个cookie并为其分配随机值。

我检查非登录用户agaist该cookie。 如果它也存在与db条目匹配，我将它们登录，打开一个会话。

如果你不在共享主机中，存储在memcache应该很棒:)