Redis는 Memcached가 제공하는 모든 작업을 수행 할 수 있습니다 (LRU 캐시, 항목 만료 및 현재 버전 3.x +, 현재 베타 버전에서 클러스터링) 또는 twemproxy와 같은 도구로. 성능도 비슷합니다. 또한 Redis는 서버를 다시 시작하는 경우 캐시 워밍을 수행 할 필요가없는 지속성을 추가합니다.

Redis와 Memcache를 비교하는 일부 오래된 답변에 대한 참조, 그중 일부는 Memcache의 대체품으로 Redis를 선호합니다 (이미 스택에있는 경우).

• Memcached 대 Redis?

• Memcached는 Redis에 비해 공룡인가요?

• Redis 및 Memcache 또는 Redis?

그럼에도 불구하고 Instagram, Pinterest, Twitter 등과 같은 대규모 웹 규모 회사의 스택을 연구하면서 그들이 기본 캐싱에 Redis를 사용하지 않고 Memcached와 Redis를 서로 다른 목적으로 사용한다는 것을 발견했습니다. 기본 캐시는 여전히 Memcached이며 Redis는 데이터 구조 기반 논리적 캐싱에 사용됩니다.

2014 년 현재, memcached가 할 수있는 모든 작업을 수행 할 수있는 Redis 구성 요소가 이미있는 경우에도 memcached가 스택에 추가 구성 요소로 추가되는 데 어려움을 겪을 가치가있는 이유는 무엇입니까? 이미 기존 Redis와 별도로 memcached를 포함하도록 설계자 / 엔지니어가 유리하게 생각하는 점은 무엇입니까?

업데이트 :

플랫폼의 경우 Memcached를 완전히 폐기했으며 일반 및 논리적 캐싱 요구 사항에 redis를 사용합니다. 뛰어난 성능, 유연성 및 신뢰성.

몇 가지 예제 시나리오 :

• 캐시 된 모든 키를 특정 패턴으로 나열하고 해당 값을 읽거나 삭제합니다. redis에서는 매우 쉬우 며 memcached에서는 수행 할 수 없습니다 (쉽게).
• redis에서 쉽게 수행 할 수있는 1MB 이상의 페이로드를 저장하려면 자체 성능 부작용이있는 memcached에서 슬래브 크기 조정이 필요합니다.
• 현재 캐시 콘텐츠의 간편한 스냅 샷
• Redis 클러스터는 언어 드라이버와 함께 프로덕션 준비가되어 있으므로 클러스터 배포도 쉽습니다.

내가 오늘 Redis를 통한 memcached의 사용 사례로 보는 주된 이유는 일반 HTML 조각 캐싱 (또는 유사한 응용 프로그램) 으로 얻을 수있는 뛰어난 메모리 효율성 때문 입니다. 다른 memcached 키에 객체의 다른 필드를 저장해야하는 경우 Redis 해시는 메모리 효율성이 더 높지만 키-> simple_string 쌍이 많은 경우 memcached는 당 더 많은 항목을 제공 할 수 있습니다. 메가 바이트.

memcached에 대해 좋은 점은 다음과 같습니다.

• 매우 간단한 코드 조각이므로 제공하는 기능 만 필요하면 합리적인 대안이라고 생각하지만 프로덕션에서는 사용하지 않았습니다.
• 다중 스레드이므로 단일 박스 설정으로 확장해야하는 경우 좋은 방법이며 하나의 인스턴스와 만 대화하면됩니다.

사람들이 지능형 캐싱으로 이동하거나 Redis 데이터 구조를 통해 캐시 된 데이터의 구조를 보존하려고 할 때 캐시로서의 Redis가 점점 더 의미가 있다고 생각합니다.

Redis LRU와 memcached LRU의 비교.

memcached와 Redis는 모두 실제 LRU 제거를 수행하지 않고 근사치 만 수행합니다.

Memcache 제거는 크기별 클래스이며 해당 슬랩 할당 자의 구현 세부 정보에 따라 다릅니다. 예를 들어 주어진 크기 클래스에 맞는 항목을 추가하려는 경우 memcached는 해당 클래스에서 만료되었거나 최근에 사용되지 않은 항목을 제거하려고 시도합니다. 대신 객체가 무엇인지 이해하기 위해 전역 시도를 시도합니다. 가장 좋은 후보입니다.

Redis는 대신 maxmemory크기 등급에 관계없이 모든 개체를 살펴보고 제한에 도달 하면 제거 후보로 좋은 개체를 선택하려고 하지만 유휴 상태가 더 큰 최상의 개체 가 아닌 대략 좋은 개체 만 제공 할 수 있습니다. 시각.

Redis가이를 수행하는 방법은 몇 개의 개체를 샘플링하여 가장 오랫동안 유휴 (액세스되지 않은) 개체를 선택하는 것입니다. Redis 3.0 (현재 베타 버전) 이후로 알고리즘이 개선되었으며 제거 과정에서 좋은 후보자 풀을 가져 오므로 근사치가 향상되었습니다. 에서 레디 스 문서 당신이 어떻게 작동하는지에 대한 세부 설명과 그래프를 찾을 수 있습니다 .

memcached가 간단한 문자열-> 문자열 맵에서 Redis보다 더 나은 메모리 공간을 갖는 이유.

Redis는 더 복잡한 소프트웨어 조각이므로 Redis의 값은 고급 프로그래밍 언어의 객체와 더 유사한 방식으로 저장됩니다. 메모리 관리를위한 관련 유형, 인코딩, 참조 계수가 있습니다. 이것은 Redis 내부 구조를 훌륭하고 관리하기 쉽게 만들어 주지만, 문자열 만 다루는 memcached에 비해 오버 헤드가 있습니다.

Redis가 메모리 효율성을 높이기 시작할 때

Redis는 특별한 메모리 절약 방식으로 작은 집계 데이터 유형을 저장할 수 있습니다. 예를 들어 개체를 나타내는 작은 Redis Hash는 내부적으로 해시 테이블이 아니라 바이너리 고유 Blob으로 저장됩니다. 따라서 객체 당 여러 필드를 해시로 설정하는 것이 N 개의 분리 된 키를 memcached에 저장하는 것보다 효율적입니다.

실제로 memcached에 단일 JSON (또는 이진 인코딩) blob으로 객체를 저장할 수 있지만 Redis와는 반대로 독립 필드를 가져 오거나 업데이트 할 수 없습니다.

지능형 캐싱의 맥락에서 Redis의 장점.

Redis 데이터 구조로 인해 캐시가 무효화 될 때 객체를 파괴하는 memcached와 함께 사용되는 일반적인 패턴은 나중에 DB에서 다시 생성하기 위해 Redis를 사용하는 원시적 인 방법입니다.

예를 들어, 사이트의 "최신"섹션을 채우기 위해 Hacker News에 게시 된 최신 N 뉴스를 캐시해야한다고 가정 해보십시오. Redis로하는 일은 최신 뉴스가 삽입 된 목록 (M 개 항목으로 제한됨)을 가져 오는 것입니다. 데이터에 대해 다른 저장소를 사용하고 Redis를 캐시로 사용하는 경우 새 항목이 게시 될 때 두 뷰 (Redis 및 DB)를 모두 채우는 것 입니다. 캐시 무효화가 없습니다.

그러나 응용 프로그램은 항상 논리를 가질 수 있으므로 예를 들어 시작 후 Redis 목록이 비어있는 경우 DB에서 초기보기를 다시 만들 수 있습니다.

지능형 캐싱을 사용하면 memcached에 비해 더 효율적인 방식으로 Redis로 캐싱을 수행 할 수 있지만 모든 문제가이 패턴에 적합한 것은 아닙니다. 예를 들어 HTML 조각 캐싱은이 기술의 이점을 얻지 못할 수 있습니다.

습관은 깨지기 어렵다 :)

진지하게도 Memcached가 여전히 사용되는 두 가지 주요 이유가 있습니다.

1. 레거시-Memcached와이를 지원하는 애플리케이션에 익숙하고 익숙한 개발자가 있습니다. 이것은 또한 그것이 성숙하고 잘 테스트 된 기술임을 의미합니다.
2. 확장-표준 Memcached는 쉽게 수평 확장이 가능하지만 Redis (곧 출시 될 v3까지 및 제외)는이를 위해 더 많은 작업 (예 : 샤딩)이 필요합니다.

하나:

1. 레. 레거시-Redis의 견고성 (데이터 구조, 명령, 지속성 ...)을 감안할 때, 적극적으로 개발되고 있으며 가능한 모든 언어의 클라이언트- 일반적으로 새로운 응용 프로그램이 함께 개발됩니다.
2. Re scaling-곧 출시 될 v3 외에도 확장을 훨씬 쉽게 할 수있는 솔루션이 있습니다. 예를 들어 Redis Cloud 는 데이터 손실이나 서비스 중단없이 원활한 확장을 제공합니다. Redis 확장 / 분할에 대한 또 다른 인기있는 접근 방식은 twemproxy 입니다.