Qual é o armazenamento de sessão mais confiável no PHP: Memcache, banco de dados ou arquivos? [fechadas]


10

Qual é a melhor e mais segura maneira de lidar com sessões PHP. É a melhor maneira de armazenar sessões em:

  1. Banco de dados (mais confiável, mas com alto gargalo, velocidade lenta, não é bom para sites com alto uso de banco de dados)?

  2. Memcache (super rápido, mas distribuiu mais problemas de segurança, chances de perder dados quando o servidor reiniciou e chances de perder dados quando o cache está cheio)?

  3. Arquivos (opção padrão, acho lenta, pois lê e grava a partir de E / S de arquivos, menos segurança, etc.).

Qual método é o melhor? Quais são os problemas e as coisas boas de cada uma dessas abordagens?


2
Acredito que você deve especificar se está usando apenas uma máquina ou se o aplicativo é distribuído, pois isso influenciará fortemente as respostas.
Arseni Mourzenko 5/11

11
@haylem este é o lugar mais apropriado para fazer esta pergunta, a sua pergunta não programar a sua programação problema conceitual,
user1179459

3
Esta é realmente uma pergunta ruim, porque 'melhor' depende de sua circunstância específica. O 'melhor' para o Facebook provavelmente não é o mesmo 'melhor' para sua home page pessoal.
GrandmasterB

11
@GrandmasterB eu sei que é por isso que perguntei claramente "Quais são os problemas e as coisas boas de cada uma dessas abordagens?" para descobrir qual é o melhor para mim.
user1179459

Respostas:


6

O melhor é armazenar no Memcached, pois podemos resolver facilmente os outros problemas (tamanho do cache, segurança etc.)

o facebook é o consumidor número 1 do memcached. Por favor, leia se estiver interessado: http://www.facebook.com/note.php?note_id=39391378919

Como resolver os outros problemas?


4

Para a grande maioria dos aplicativos diários, manter as sessões nos bancos de dados é bom. O volume e o nível de simultaneidade que um servidor sql pode manipular será mais que suficiente. A chave é manter cada entrada pequena em tamanho e limpar as linhas desnecessárias com regularidade. E indexação adequada, é claro.

O sistema de arquivos - nunca vi a necessidade de fazer isso. Prefiro a simplicidade de gerenciar linhas em tabelas do que milhares de pequenos arquivos. Além disso, você não pode consultar os arquivos se quiser pesquisar as estatísticas da sessão.

Lembre-se, com o PHP, é fácil trocar os manipuladores de sessão. Assim, você pode começar com um formato de armazenamento e migrar para outro sem muito aborrecimento.


4

Que tal usar o mecanismo de armazenamento MEMORY no MySQL?

Não é tão rápido quanto o Memcache, mas tem a vantagem de poder usar SQL simples e também pode usar o mecanismo de armazenamento normal quando não for necessário e alternar para MEMORY quando o número de usuários / solicitações aumentar.

Estou usando-o para armazenar grandes quantidades de dados estatísticos em um aplicativo Web que muda frequentemente, para que não seja usado para lidar com sessões, mas acho que deve ser adequado para esse fim.


3

Esta postagem no blog mostra os resultados de uma comparação de desempenho de diferentes mecanismos de armazenamento de sessão com o Magento e eles parecem ter concluído que até 75 usuários simultâneos não há realmente uma diferença de desempenho entre eles.

Eu acho que nesses níveis (eles tinham cerca de 5 transações por segundo, o que seria cerca de 430k ocorrências em um período de 12 horas), a sobrecarga em todo o resto domina os números de desempenho que você vê, já que o arquivo / DB / Memcache / Redis lidará felizmente o tráfego sem suar se usado corretamente.

Isso deixa outros fatores, como escalabilidade, confiabilidade e segurança.

Gostaria de dizer primeiro que qualquer coisa que comprometa seu armazenamento de arquivos provavelmente comprometerá qualquer outra coisa, já que um invasor pode apenas modificar o código do aplicativo ou, pelo menos, descobrir chaves e protocolos / credenciais de acesso ao armazenamento, mesmo que tenham somente leitura Acesso. O armazenamento de arquivos funcionará bem em sites de baixo volume, é fácil de configurar e fácil de raciocinar. Por mais que você diga que atingiu o disco, uma leitura do banco de dados também atingirá o disco e, se o banco de dados puder armazená-lo em cache, provavelmente o sistema operacional também armazenará em cache o arquivo da sessão. Além disso, seu arquivo é lido, e seu sistema de arquivos é brilhante para alcançá-lo, se você já sabe o nome. Se você está usando PHP, sabe quantas leituras de arquivo o sistema precisa fazer apenas para atender seu aplicativo? A desvantagem é que você pode '

O Memcache é relativamente rápido e, se você considerar as soluções de classe do Memcache de maneira mais ampla (Redis, etc), há algumas que prometem persistência com leituras na memória para maior velocidade, para que você obtenha o máximo dos dois mundos. Eles também são relativamente simples de raciocinar e a natureza do valor-chave das sessões é exatamente o que elas foram projetadas para fazer. Você sabe quanto você precisaria colocar em uma sessão para preencher uma dessas? De qualquer maneira, todas as suas opções forçarão você a se comprometer se você atingir a capacidade delas. Os discos são preenchidos com arquivos (número e fator de tamanho aqui), os armazenamentos de cache possuem capacidade e os bancos de dados têm um número limitado de linhas e os mesmos limites de capacidade de disco que a abordagem de arquivo. Além disso, esses sistemas são distribuídos apenas se você os executar de maneira distribuída. A maioria funciona bem com uma única configuração de servidor. Se você os distribuir, provavelmente já terá servidores da Web / servidores de banco de dados, etc, para que os problemas do sistema distribuído certamente não apareçam na sua opção de armazenamento de sessão. No entanto, quando você deseja 10x o tráfego / capacidade etc, chegar lá é muito mais natural com isso do que com o esquema de armazenamento de arquivos. Alguns armazenamentos de chave / valor também permitem realizar análises simples dos dados da sessão com relativa facilidade, mas a maioria não o leva nem perto do que o SQL pode fazer.

Não sei por que você propõe que o banco de dados seja mais confiável do que as outras opções, mas recebo o apelo do banco de dados, pois seu aplicativo PHP provavelmente já o utiliza. Isso significa que você não adiciona outra dependência do servidor e provavelmente pode reutilizar a mesma conexão usada para buscar dados da sessão para obter dados do usuário, para não precisar estabelecer uma para dados, uma para Memcache, etc. Se você indexar o tabela, ele também terá um desempenho razoavelmente rápido e fornece semânticas bastante simples com as quais você já está familiarizado para colher sessões antigas ou até mesmo analisar dados de sessão (não sei por que você gostaria e se não o é, provavelmente isso não significa ' importa tanto). Escalar para escalas maciças não é tão trivial quanto em algo como Redis,

Eu acho que essa escolha não é tão importante no começo. Cada abordagem tem desafios e vantagens e coisas em que você deve pensar. De um modo geral, você provavelmente pode usar apenas os padrões do PHP / qualquer estrutura que você use ou mesmo a coisa mais fácil de seguir. Se a escolha for ruim posteriormente, suas análises de desempenho informarão e você estará armado com os dados necessários para fazer as escolhas apropriadas, dada a natureza específica do tráfego recebido. Na frente, tudo o que você pode razoavelmente ter é especulação geral.


0

Isso depende de suas necessidades.

Existem algumas diferenças entre arquivos e armazenamento de banco de dados. Veja esta pergunta .

No entanto, você pode fazer o que é feito no Rails 3 por padrão e usar apenas cookies criptografados para sua sessão. Assim, você criptografa todos os valores de uma maneira que somente você pode descriptografar mais tarde (por exemplo, chaves privadas / públicas) e deixa o cliente fazer o estado mantendo você.

Por um lado, limita-o a 4Kb, o que geralmente é suficiente (já que você geralmente deseja armazenar IDs, não objetos inteiros), mas o benefício realmente bom que você obtém é que não precisa se preocupar com a limpeza da sessão. Você deixa isso para o cliente, onde realmente deveria estar.


2
A menos que você tenha separado seus recursos estáticos para ficar fora do caminho dos cookies, os cookies são um imposto fixo que você deve pagar a cada solicitação.
Joeri Sebrechts

O jQuery e o Bootstrap têm cerca de 150kb combinados, e isso sem outras bibliotecas. O cookie máximo é de 4kb e geralmente abaixo de 1Kb. A menos que o OP esteja perguntando sobre circunstâncias extremas - quem se importa com esse tipo de tributação?
Yam Marcovic

@YamMarcovic existem alguns problemas 1) os cookies também estão no servidor (os usuários costumam fazer o download mais rápido do que o upload) 2) geralmente as páginas têm centenas de solicitações de arquivos estáticos (imagens, js, css) para que ele atinja 100kb em cada solicitação indo para cima
Miro Svrtan

@MiroSvrtan Se você está fazendo com que seus usuários enviem centenas de solicitações por página (onde isso aconteceu?), A otimização claramente não é um problema para você.
Yam Marcovic

Eu tinha um cliente cujo site estava fazendo ~ 170 solicitações HTTP para carregar a primeira página antes de me consultar para obter otimizações de velocidade, por isso, confie em mim. Por outro lado, chaves públicas / privadas são um conceito da criptografia assimétrica, que geralmente não seria aplicada nesse cenário em que é equivalente a uma cifra simétrica, apenas mais complexa de implementar. Além disso, a maioria das implementações de armazenamento de sessão depende de alguns cookies gerenciados pelo cliente; portanto, o benefício descrito no último parágrafo da resposta se aplica a todos eles.
jeteon

0

Para minha situação específica, posso dizer que as sessões em um banco de dados são a causa número um de travamentos de servidores por uma boa margem. nossa tabela de sessões é corrompida com frequência suficiente para que possamos truncá-la preventivamente.

O memcache parece atraente, mas temos muitos processos que limpam todo o memcache, para que as sessões do usuário sejam cortadas com muita frequência. e as sessões mais antigas seriam limpas à medida que a memória se tornasse cheia ... para que não haja mais logins permanentes.

Em breve, tentaremos as sessões baseadas em arquivo padrão.

Se você está preocupado com a segurança dos dados da sua sessão, não deve colocá-los na sessão - e não confiar nela - validar o usuário em todas as solicitações.


0

Você pode tentar salvar sua sessão no Redis . O Redis é rápido como o Memcached, mas também possui várias opções de persistência de dados. Além disso, vários clientes PHP são suportados.

Além disso, você pode experimentar serviços de terceiros, como o Memcached Cloud, que possui recursos internos de replicação e mecanismo de armazenamento

Divulgação, Sou Co-Fundador e CTO do Garantia Data.


2
Obrigado pela divulgação! Certifique-se de participar deste site além das postagens em que você pode mencionar seus próprios produtos; queremos que você como pessoa contribua, não sua empresa.
precisa
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.