关于此问题肯定还有其他帖子，但我还有一个问题。
我们即将扩展工作中的网站，使其拥有多个服务器。我们需要在服务器之间共享会话。
我们一直在研究不同的解决方案，其中之一memcached并在 PHP 中使用 Memcached 作为会话处理程序。这可能会奏效。
我们的想法是在每台机器上运行 memcached，并让所有网络服务器访问所有其他服务器的 memcached 服务器，然后我们在机器之间共享会话，耶。（我们还没有资源来设置粘性会话，那是以后的项目。我们需要运行它，我们现在就需要运行它。作为起动器，我们将使用 DNS 进行负载平衡）
但是...如果我要关闭一台服务器，比如说，进行维护，或者服务器崩溃，或者其他原因。我不希望用户丢失他们的会话，不得不从头开始...这就是为什么我们需要某种复制，而 Memcached 不支持这种复制。
然后我发现http://repcached.lab.klab.org/-- 它具有 memcached 的多主复制功能，这很棒，也是我想要的。但它能与 2 台以上的机器一起工作吗？比如说 3、5、10 台？用于未来的扩展。
我也研究了 redishttp://redis.io/——这似乎也很棒，但是由于 php-session-handler 支持而有点“不稳定”，并且没有多主复制。
问题是我喜欢使用 memcached，但我希望能够关闭两个盒子中的一个，而不会丢失一半的会话。有什么建议吗？
答案1
您可能想要了解一下使用 memcache API 实现复制密钥存储的 couchdb。它还比大多数 memcache 实现更优雅地处理内存存储溢出（故障转移期间可能出现的结果）。我必须承认，我并不熟悉它如何实现复制的细节。
我见过的所有“粘性”会话实现都将请求绑定到显式设备 - 这不利于实现良好的故障转移 - 而使用 PHP，会话亲和性仅与存储底层相关（与 Java 不同，Java 通常需要位于逻辑层）。因此，在 HTTP 层使用粘性会话是无关紧要的。
当然，由于复制滞后和单线程写入操作，在底层使用异步 MySQL 复制并非易事 - 我使用 PHP 中的连接代理（它在故障转移期间实现首选项和阻止）来解决这个问题。虽然 MySQL 不是最有效的会话处理解决方案，但如果您的应用程序已经依赖于高可用性关系数据库，那么将其用于会话存储就很有意义了。MySQL 有多主复制实现 - 例如 Percona。
MongoDB 也使用异步复制，但没有 MySQL 的单线程依赖。
您将不得不花一些时间考虑如何隔离节点。虚拟地址接管（如果正确实施）应该使操作透明，但 IME 可能很难做到正确，它需要接管 arp 地址以及 IP 地址，以避免在故障转移期间出现长时间暂停。
比如说 3、5、10？用于未来的扩展
如果您打算扩展到这种程度，那么您可能应该考虑多个数据中心 - 这意味着一种可以应对低带宽/更高延迟的同步方法，即而不是共享文件系统。
答案2
我推荐一个数据库会话处理程序而不是 memcached。您可能无论如何都会使用数据库，并且如果您的数据库宕机，那么您的网站也会宕机，因此您不会添加新的故障模式。
Memcached 不处理故障转移。任何系统中的此类多主环境中的缓存失效要么缓慢而复杂（同步），要么不可靠（异步）。因此，您会遇到这样的情况：您在一台服务器上设置某个会话变量，而下一个请求转到另一台服务器，该服务器具有此变量的旧值。