캐싱에 맵 대신 Redis를 사용하는 이유는 무엇입니까?

Question

캐싱에 Redis를 사용해야 하는 이유는 무엇인가요?
Redis는 키-값 형식이고, Map도 Redis를 대체할 수 있나요?
교체할 수 없는 경우도 있나요? 아니면 redis만이 달성할 수 있는 요구사항은 무엇인가요?

Answer 1

캐시는 로컬 캐시와 분산 캐시로 구분됩니다. Java를 예로 들면, 로컬 캐싱은 내장된 맵이나 구아바를 사용하여 구현됩니다. 주요 특징은 jvm이 소멸되면서 수명 주기가 종료된다는 것입니다. 인스턴스 각 캐시를 저장해야 하며 캐시가 일관성이 없습니다.

redis 또는 memcached를 사용하는 것을 분산 캐시라고 합니다. 여러 인스턴스의 경우 각 인스턴스는 데이터 캐시를 공유하며 캐시는 일관성이 있습니다. 단점은 redis 또는 memcached 서비스의 가용성을 높게 유지해야 하며 전체 프로그램 아키텍처가 상대적으로 복잡하다는 것입니다.

Answer 2

1. Redis는 캐싱에 수십 기가바이트의 메모리를 사용할 수 있지만 Map은 그렇지 않습니다. 일반적으로 JVM은 몇 기가바이트의 데이터만 있으면 충분합니다.

2. Redis의 캐시는 지속될 수 있고, Map은 메모리 개체이므로 프로그램을 다시 시작하자마자 데이터가 손실됩니다.

3. Redis는 분산 캐싱을 구현할 수 있으며 Map은 이를 생성한 프로그램에만 존재할 수 있습니다.

4. Redis는 초당 수백만 개의 동시성을 처리할 수 있는 전문 캐싱 서비스입니다. Map은 평범한 객체입니다

5. Redis 캐시에는 만료 메커니즘이 있으며, 맵 자체에는 이 기능이 없습니다

6. Redis에는 풍부한 API가 있고 Map은 훨씬 간단합니다

Answer 3

1. Redis 데이터는 지속적으로 저장될 수 있습니다. 프로그램을 다시 시작한 후에도 일부 캐시를 계속 사용하려는 경우에는 Map이 이를 달성할 수 없습니다.
2. Redis는 여러 머신과 프로세스를 포함하는 한 분산 배포를 달성할 수 있습니다. .Map을 구현할 수 없습니다
3. Redis에는 hash set list sort-set 등 조작하기 쉬운 데이터 구조가 많습니다. 일부 시나리오에서는 map보다 조작이 더 편리합니다

Answer 4

1. 캐시에 많은 양의 콘텐츠를 로드해야 하는 경우 시작 시 시간이 오래 걸립니다.
2. JVM 메모리가 너무 커서 중단되기 쉽습니다. redis는 C로 작성되어 안정성과 성능이 향상되었습니다.
4. 현재 Redis는 이미 클러스터 모드, 지속성 및 더 많은 기능을 지원합니다.
5. Redis의 API는 이미 매우 간단하고 사용하기 쉽습니다. >

Answer 5

Redis는 독립적으로 배포할 수 있으므로 웹사이트 코드가 업데이트된 후에도 Redis에 의해 캐시된 데이터는 그대로 유지되며 웹사이트가 업데이트될 때마다 로컬 메모리가 해제됩니다.
데이터는 Redis에 저장됩니다. , 캐시된 데이터는 여러 프로젝트 간에 공유할 수 있습니다. 로컬 메모리인 경우 프로젝트 간에 공유할 수 없습니다

로컬 캐시는 보기 및 수정이 쉽지 않습니다. Redis에는 캐시 데이터를 관리할 수 있는 풍부한 도구가 있습니다.