PHP em vários servidores com compartilhamento de sessão

Question

há certanly outros tópicos sobre isso, mas eu tenho mais uma pergunta.

Estamos prestes a dimensionar o site no trabalho para ter mais de um servidor. E nós precisamos compartilhar as sessões entre os servidores.

Nós estamos procurando por diferentes soluções, uma em memcached e usando o Memcached como manipulador de sessão em PHP. Isso provavelmente funcionará.

E a idéia seria executar o memcached em cada máquina e permitir que todos os servidores da Web acessem todos os outros servidores de memcached e, em seguida, compartilhemos as sessões entre as máquinas, yay. (ainda não temos recursos para configurar com sessões persistentes, esse é um projeto posterior. Precisamos disso em execução e precisamos disso agora. e faremos o balanceamento de carga com o DNS para um iniciante)

Mas então ... Se eu quiser derrubar um servidor, por exemplo, para manutenção, ou um servidor falhar, ou qualquer outra razão. Eu não quero que os usuários apenas percam suas sessões e tenham que começar do começo ... É por isso que precisamos de algum tipo de replicação, que o Memcached não suporta.

Então eu encontrei o link - que tem replicação multi-mestre do memcached, o que é ótimo, e é o que eu quero . Mas funciona com 2 máquinas? Diga 3, 5, 10? Para escalonamento futuro.

Eu também olhei para o link - que também parece ótimo, mas é um pouco mais "instável" com o manipulador de sessão-php suporte, e não multi-master-replicação.

A coisa é que eu gosto de usar memcached, mas eu quero poder desligar uma das duas caixas sem perder metade das sessões. Alguma sugestão?

    

Answer 1

Você pode querer dar uma olhada no couchdb que implementa o repositório de chaves replicadas com uma API memcache. Ele também gerencia o estouro do armazenamento de memória mais facilmente do que a maioria das implementações do memcache (um resultado provável durante o failover). Devo admitir que não estou familiarizado com os detalhes de como isso implementa a replicação.

Todas as implementações de sessões "fixas" que vi ligam a solicitação a um dispositivo explícito - o que não faz um bom failover - e com o PHP a afinidade de sessão é relevante apenas para o substrato de armazenamento (diferente de Java onde geralmente precisa estar no nível lógico). Portanto, usar sessões fixas na camada HTTP é irrelevante.

Certamente, usar a replicação assíncrona do MySQL no substrato não é trivial devido ao atraso de replicação e operações de gravação de thread único - eu uso um broker de conexão no PHP (que implementa preferências e bloqueia durante failover) para resolver isso. Embora o MySQL não seja a solução mais eficiente para manipulação de sessão, se seus aplicativos já estão contando com um banco de dados relacional de alta disponibilidade, faz muito sentido usá-lo para armazenamento de sessão. Existem implementações de replicação multimestre para o MySQL - por exemplo, Percona.

O MongoDB também usa replicação assíncrona, mas sem a dependência de um único segmento do MySQL.

Você terá que gastar algum tempo pensando em como você delimita os nós. O controle de endereço virtual (se implementado corretamente) deve tornar a operação transparente, mas o IME pode ser difícil de acertar e precisa assumir o endereço arp, bem como o endereço IP, para evitar grandes pausas durante o failover.

Say 3, 5, 10? For future scaling

Se você planeja escalar até esse ponto, provavelmente deveria estar pensando em vários datacenters - o que implica em um método de sincronização que pode lidar com baixa largura de banda / maior latência, ou seja, não um sistema de arquivos compartilhado.

    

Answer 2

Eu recomendaria um gerenciador de sessão de banco de dados em vez do memcached. Você provavelmente usa um banco de dados de qualquer maneira e, se seu banco de dados estiver inativo, seu site também estará inativo, portanto, você não adicionará novos modos de falha.

O Memcached não processa o failover. A invalidação de cache em vários ambientes principais em qualquer sistema é lenta e complicada (síncrona) ou não confiável (assíncrona). Assim, você terá situações em que definirá uma variável de sessão em um servidor e a próxima solicitação irá para outro servidor, que tem o valor antigo dessa variável.