O Redis pode fazer tudo o que o Memcached fornece (cache LRU, expiração de item e agora clustering na versão 3.x +, atualmente em beta) ou por ferramentas como twemproxy. O desempenho também é semelhante. Além disso, o Redis adiciona persistência devido à qual você não precisa fazer o aquecimento do cache em caso de reinicialização do servidor.

Referência a algumas respostas antigas que comparam o Redis e o Memcache, algumas das quais favorecem o Redis como substituto do Memcache (se já estiver presente na pilha):

• Memcached vs. Redis?

• Memcached é um dinossauro em comparação ao Redis?

• Redis e Memcache ou apenas Redis?

Apesar disso, ao estudar pilhas de empresas de grande escala na web como Instagram, Pinterest, Twitter etc., descobri que elas usam Memcached e Redis para finalidades diferentes, não usando Redis para cache primário. O cache primário ainda é Memcached e o Redis é usado para seu cache lógico baseado em estruturas de dados.

Em 2014, por que o memcached ainda vale a pena ser adicionado como componente adicional em sua pilha, quando você já tem um componente Redis que pode fazer tudo o que o memcached pode? Quais são os pontos favoráveis ​​que inclinam os arquitetos / engenheiros a ainda incluir memcached separado do Redis já existente?

Atualização:

Para nossas plataformas, descartamos completamente o Memcached e usamos o redis para requisitos de cache simples e lógicos. Alto desempenho, flexível e confiável.

Alguns cenários de exemplo:

• Listar todas as chaves em cache por um padrão específico e ler ou excluir seus valores. Muito fácil no redis, não é possível (facilmente) no memcached.
• Armazenar uma carga útil de mais de 1 MB, fácil de fazer no redis, requer ajustes no tamanho da placa no memcached, o que tem seus próprios efeitos colaterais de desempenho.
• Instantâneos fáceis do conteúdo do cache atual
• O cluster Redis também está pronto para a produção junto com os drivers de idioma, portanto, a implantação em cluster também é fácil.

O principal motivo que vejo hoje como um caso de uso para memcached em relação ao Redis é a eficiência de memória superior que você deve ser capaz de obter com o cache de fragmentos HTML simples (ou aplicativos semelhantes). Se você precisa armazenar diferentes campos de seus objetos em diferentes chaves do memcached, então os hashes do Redis serão mais eficientes na memória, mas quando você tem um grande número de pares chave -> simple_string, o memcached deve ser capaz de fornecer mais itens por megabyte.

Outras coisas que são pontos positivos sobre o memcached:

• É um trecho de código muito simples, então se você só precisa da funcionalidade que ele oferece, é uma alternativa razoável, eu acho, mas nunca usei em produção.
• É multi-threaded, portanto, se você precisar dimensionar em uma configuração de caixa única, é uma coisa boa e você precisa falar com apenas uma instância.

Acredito que o Redis como um cache faz cada vez mais sentido conforme as pessoas mudam para o cache inteligente ou quando tentam preservar a estrutura dos dados em cache por meio das estruturas de dados do Redis.

Comparação entre Redis LRU e memcached LRU.

Memcached e Redis não executam despejos de LRU reais, mas apenas uma aproximação disso.

A remoção do Memcache é por classe de tamanho e depende dos detalhes de implementação de seu alocador de bloco. Por exemplo, se você deseja adicionar um item que se encaixa em uma determinada classe de tamanho, o memcached tentará remover itens expirados / não usados ​​recentemente nessa classe, em vez de tentar uma tentativa global de entender o que é o objeto, independentemente de seu tamanho, que é o melhor candidato.

Em vez disso, o Redis tenta escolher um objeto bom como candidato a despejo quando o maxmemorylimite é atingido, olhando para todos os objetos, independentemente da classe de tamanho, mas só é capaz de fornecer um objeto aproximadamente bom, não o melhor objeto com a maior ociosidade Tempo.

A maneira como o Redis faz isso é amostrando alguns objetos, escolhendo aquele que ficou ocioso (não acessado) por mais tempo. Desde o Redis 3.0 (atualmente em beta), o algoritmo foi aprimorado e também leva um bom pool de candidatos em despejos, portanto, a aproximação foi aprimorada. Na documentação do Redis você pode encontrar uma descrição e gráficos com detalhes sobre como funciona .

Por que o memcached tem uma pegada de memória melhor do que o Redis para strings simples -> mapas de strings.

O Redis é um software mais complexo, portanto, os valores no Redis são armazenados de uma forma mais semelhante aos objetos em uma linguagem de programação de alto nível: eles têm tipo, codificação e contagem de referência associados para gerenciamento de memória. Isso torna a estrutura interna do Redis boa e gerenciável, mas tem uma sobrecarga em comparação ao memcached, que lida apenas com strings.

Quando o Redis começa a ser mais eficiente em termos de memória

O Redis é capaz de armazenar pequenos tipos de dados agregados de uma maneira especial para economizar memória. Por exemplo, um pequeno Hash do Redis que representa um objeto é armazenado internamente não com uma tabela de hash, mas como um blob binário exclusivo. Portanto, configurar vários campos por objeto em um hash é mais eficiente do que armazenar N chaves separadas em memcached.

Você pode, na verdade, armazenar um objeto no memcached como um único blob JSON (ou codificação binária), mas ao contrário do Redis, isso não permitirá que você busque ou atualize campos independentes.

A vantagem do Redis no contexto de cache inteligente.

Por causa das estruturas de dados do Redis, o padrão usual usado com memcached de destruir objetos quando o cache é invalidado, para recriá-lo do banco de dados posteriormente, é uma maneira primitiva de usar o Redis.

Por exemplo, imagine que você precise armazenar em cache as N notícias mais recentes postadas no Hacker News para preencher a seção "Mais recentes" do site. O que você faz com o Redis é obter uma lista (limitada a itens M) com as notícias mais recentes inseridas. Se você usar outro armazenamento para seus dados e o Redis como um cache, o que você faz é preencher ambas as visualizações (Redis e DB) quando um novo item é postado. Não há invalidação de cache.

No entanto, a aplicação pode sempre ter lógica de forma que se a lista do Redis estiver vazia, por exemplo, após uma inicialização, a visualização inicial pode ser recriada a partir do banco de dados.

Usando o cache inteligente, é possível realizar o cache com o Redis de uma forma mais eficiente em comparação com o memcached, mas nem todos os problemas são adequados para esse padrão. Por exemplo, o armazenamento em cache de fragmentos de HTML pode não se beneficiar dessa técnica.

Hábitos são difíceis de quebrar :)

Sério, existem duas razões principais - no meu entendimento - pelas quais o Memcached ainda é usado:

1. Legado - há desenvolvedores que se sentem confortáveis ​​e familiarizados com o Memcached, bem como aplicativos que o suportam. Isso também significa que é uma tecnologia madura e bem testada.
2. Escalonamento - o Memcached padrão é facilmente escalonável horizontalmente, enquanto o Redis (até e excluindo o v3 a ser lançado em breve) requer mais trabalho para esse fim (ou seja, fragmentação).

Contudo:

1. Ré. legado - dada a robustez do Redis (estruturas de dados, comandos, persistência ...), sendo ativamente desenvolvido e clientes em todas as linguagens concebíveis - normalmente novas aplicações são desenvolvidas com ele.
2. Reescalonamento - além da próxima v3, existem soluções que podem tornar o dimensionamento muito mais fácil. Por exemplo, o Redis Cloud oferece escalonamento contínuo sem perda de dados ou interrupção do serviço. Outra abordagem popular para dimensionar / fragmentar o Redis é o twemproxy .