digg 或任何其他高流量网站如何存储用户会话？他们用什么来存储用户会话？文件系统、数据库（哪一个？）、内存缓存或两者兼而有之？
让我们想象一个简单的情况。登录用户在登录期间设置了“记住我”标志。我们设置了一个有效期为 1 年的会话 cookie。例如，我们在 memcache 中保存会话，但我们也应该在数据库中保存这个会话的记录（在我的版本中）。只有带有“记住我”标志的用户才会存储在数据库中。这是存储会话的正确方法吗？当然，我指的是高流量网站（具有 2 个或更多应用程序服务器、2 个或更多数据库、memecache 服务器等）。在小型网站中，默认方式（在文件系统中）存储会话是可以的。
我试图搜索谷歌，但未能找到任何有关它的信息。我从“高级 PHP 编程”一书中阅读了一些解决方案，但主要强调的是自定义会话存储处理程序。
真的希望听到好的想法或链接！
谢谢你。
除了 Alix 的回答，您可能有兴趣查看这篇文章：
一个简短的摘录：
是什么促使 Memcached 作为会话存储：
在 Digg v3 推出后不久，非冗余 MySQL 会话存储硬件崩溃了。这导致了 Digg 中断。我们一直计划在这种情况下，我们只需滚动一个（微不足道的）更改，将会话放入 Memcached 而不是 MySQL，看看它的表现如何。
那么，在您每次都在访问数据库之前进行会话？
是的。
MySQL 有足够的能力跟上为处理会话所做的插入和选择。我们的问题实际上是清除旧会话。删除旧会话的脚本尽管在尝试不使会话数据库超载方面相当复杂，但仍然对其产生了影响。
我们推测 Memcached 会以比 MySQL 更少的开销来删除过期会话。
我们使用 InnoDB 进行会话 [在 memcached 之前]。这不是表级或行级锁定。这是操作系统级别的争用。在 MySQL 前面使用 Memcached 会减少负载并允许管理脚本完成它的工作，但这突出了一个问题：为什么还要在 memcached 后面使用 MySQL？我们不需要甚至不需要非易失性会话。（给读者的重要提示：您可能需要或想要非易失性会话）。
“为什么还要在 memcached 后面使用 MySQL？”...“我们不需要甚至不想要非易失性会话”。
他们肯定在使用memcached或等效。
我的实现是，当用户点击记住我时，我放了另一个 cookie 并为其分配随机值。
我从未登录的用户那里检查该 cookie。如果它存在也与 db 条目匹配，我将它们登录，打开一个会话。
如果您不在共享主机中，则存储在 memcache 中应该很棒:)