Redis를 선택해야 하는 경우

1. 복잡한 데이터 구조에는 redis를 선택하는 것이 더 적합합니다.

값이 hash, list, set,ordered set과 같은 복잡한 데이터 구조인 경우 mc가 이러한 요구를 충족할 수 없기 때문에 redis를 선택합니다.

가장 일반적인 시나리오, 사용자 주문 목록, 사용자 메시지, 게시물 댓글 목록 등

둘째, 지속성, redis가 더 적합합니다

mc는 지속성 요구를 충족할 수 없으므로 Redis를 선택해야 합니다. 그러나 한 가지 주목해야 할 점은 Redis의 지속성 기능을 올바르게 사용하고 있는지 정말로 확인하셨나요?

Redis를 데이터베이스로 사용하지 마세요.

• redis의 일반 스냅샷은 데이터가 손실되지 않는다고 보장할 수 없습니다.

• redis의 AOF는 효율성을 저하시키고 너무 많은 양의 데이터를 지원할 수 없습니다. Redis가 견고한 스토리지에서 mysql보다 더 나은 성능을 발휘할 것이라고 기대하지 마십시오. Redis를 데이터베이스로 사용하는 것은 80% 잘못된 것입니다.

캐싱 시나리오에서 치료 기능을 켜면 장단점이 무엇인가요?

단순한 캐싱 시나리오라면 데이터가 데이터베이스에 저장되고 이때 치료 기능을 켜면 Redis에 캐시됩니다. on:

redis가 중단된 후 다시 시작되는 경우 메모리가 데이터베이스에 즉시 부담을 주지 않고 핫 데이터를 빠르게 복원할 수 있다는 장점이 있습니다. 캐시 워밍업 프로세스가 없습니다.

단점은 Redis 정지 과정에서 데이터베이스의 데이터 수정이 있는 경우 Redis를 다시 시작한 후 데이터베이스와 Redis 데이터가 일치하지 않을 수 있다는 것입니다.

따라서 읽기 전용 시나리오의 경우 또는 일부 일관되지 않은 비즈니스 시나리오를 허용하려면 Redis의 강화 기능을 활성화해 볼 수 있습니다.

3. 고가용성을 위해서는 redis를 선택하는 것이 더 적합합니다

redis는 클러스터링 기능을 자연스럽게 지원하며 활발한 복제와 읽기와 쓰기의 분리가 가능합니다. Redis는 또한 마스터-슬레이브 서비스 모니터링 및 자동 장애 조치를 실현할 수 있는 센티넬 클러스터 관리 도구를 공식적으로 제공합니다. 이 모든 것은 프로그램 변경이나 수동 개입 없이 클라이언트에게 투명합니다.

Voiceover: Memcache는 고가용성을 달성하기 위해 클라이언트에서의 이중 읽기 및 이중 쓰기 또는 서버에서의 클러스터 동기화와 같은 보조 개발이 필요합니다.

그러나 여기서 제가 상기시키고 싶은 점은 대부분의 비즈니스 시나리오에서 캐시가 실제로 고가용성이어야 한다는 것입니다.

캐싱 시나리오에서는 DB에서 데이터를 읽는 경우 캐시 누락이 허용되는 경우가 많습니다. 따라서 비즈니스 시나리오를 신중하게 분석해야 합니다. 고가용성이 실제로 캐시의 주요 요구 사항입니까?

음성 해설: 인스턴트 메시징 비즈니스에서는 사용자의 온라인 상태에 대한 고가용성 요구 사항이 있습니다.

• 4. 저장되는 내용이 상대적으로 크기 때문에 redis를 선택하는 것이 더 적합합니다.

• memcache의 저장 값은 최대 1M까지입니다.

물론 Memcache와 비교할 때 Redis에는 기본 구현 메커니즘의 차이로 인해 몇 가지 "단점"도 있습니다.

시나리오 1: 메모리 할당 메커니즘의 차이로 인해 redis는 메모리 조각화를 일으킬 수 있습니다.

memcache는 사전 할당된 메모리 풀을 사용하여 메모리를 관리하므로 메모리 할당 시간을 절약할 수 있습니다. redis는 일시적으로 공간에 적용되므로 조각화가 발생할 수 있습니다.

이제부터 MC가 빨라집니다.

시나리오 2: 가상 메모리 사용량의 차이로 인해 redis는 디스크를 플러시하여 성능에 영향을 미칠 수 있습니다.

memcache는 모든 데이터를 물리적 메모리에 저장합니다.

Redis에는 이론적으로 물리적 메모리보다 더 많은 데이터를 저장할 수 있는 자체 VM 메커니즘이 있습니다. 데이터가 초과되면 스왑이 트리거되어 콜드 데이터를 디스크로 플러시합니다. 이 시점부터 데이터의 양이 많으면 mc가 더 빨라집니다.

음성 해설: Redis의 새 버전이 최적화되었습니다.

사례 3: 네트워크 모델의 차이로 인해 redis는 CPU 계산으로 인해 IO 스케줄링에 영향을 미칠 수 있습니다.

memcache는 비차단 IO 다중화 모델을 사용하고 Redis도 비차단 IO 다중화 모델을 사용합니다.

그러나 Redis는 KV 스토리지 이외의 일부 정렬 및 집계 기능도 제공하므로 이러한 기능을 실행할 때 복잡한 CPU 계산으로 인해 전체 IO 스케줄링이 차단됩니다.

이 시점부터 redis가 더 많은 기능을 제공하므로 mc가 더 빨라질 것입니다.

시나리오 4: 스레드 모델의 차이로 인해 Redis가 멀티 코어 특수 효과를 사용하여 성능을 향상시키기가 어렵습니다.

memcache는 멀티 스레드를 사용하고, 기본 스레드는 수신 대기하며, 작업자 하위 스레드는 요청을 수락합니다. 이 과정에서 잠금 충돌이 발생할 수 있습니다.

Redis는 단일 스레드를 사용하지만 잠금 충돌이 없지만 전체 처리량을 향상시키기 위해 멀티 코어의 특성을 사용하기는 어렵습니다.

이제부터 MC가 빨라집니다.

시나리오 5: 자동 샤딩이 없기 때문에 redis는 수동으로만 수평 확장이 가능합니다

redis이든 memcache이든 서버 클러스터는 기본적으로 수평 확장을 지원하지 않으며 클라이언트에서 샤딩해야 합니다. 이는 실제로 발신자에게 좋지 않습니다. 서버 클러스터가 수평 확장을 지원할 수 있다면 더욱 완벽할 것입니다.

마지막으로 이것이 많은 사람들이 Redis를 좋아하는 이유 중 하나일 수 있습니다. 소스 코드는 읽기 쉽고 코드 품질이 매우 높습니다.

저는 redis와 memcache의 소스 코드를 보았습니다. 가독성 측면에서 redis는 제가 본 것 중 가장 깔끔한 코드를 가진 소프트웨어일 것입니다. 아마도 단순성은 컴파일을 위해 구성이 필요하지 않을 것입니다. redis. 타사 라이브러리를 사용하면 한 번만 만들면 됩니다.

Memcache 소스 코드는 확장성과 다중 시스템 호환성을 너무 많이 고려했을 수 있습니다. 코드가 명확하지 않고 힘들어 보입니다.

예를 들어 네트워크 IO 부분의 경우 redis 소스 코드 중 1~2개 파일을 해결할 수 있습니다. MC는 libevent를 사용합니다. FD는 파이프와 스레드를 통해 앞뒤로 전달되므로 특히 사람들이 혼동하기 쉽습니다.

위 내용은 Redis를 선택해야 하는 경우의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!