Redis에는 어떤 기능이 있나요?

Redis는 다양한 기능을 제공합니다. 이 기능은 무엇을 위해 사용되나요? 어떤 문제가 해결되었나요? 해당 기능은 어떤 상황에서 사용되나요? 단계별 설명부터 시작해 보겠습니다.

로컬 메모리 기반 캐시

API 호출이 여전히 2초가 걸리는 문제를 해결하기 위해 조사한 결과, 가장 큰 이유는 SQL을 사용하여 최신 뉴스를 얻는 과정이 거의 2초를 소비한다는 것입니다. 그래서 갑자기 우리는 SQL 쿼리 결과를 현재 API 서버의 메모리에 직접 캐시하는 간단하고 조잡한 솔루션을 생각했습니다(캐시 유효 시간을 1분으로 설정). 1분 이내의 후속 요청은 캐시를 직접 읽으며 더 이상 SQL을 실행하는 데 2초가 걸리지 않습니다. 이 API가 초당 100개의 요청을 받으면 분당 6,000개의 요청이 발생합니다. 즉, 처음 2초 동안 붐비는 요청만 2초가 걸리고 이후 58초 동안의 모든 요청은 즉시 응답할 수 있습니다. 2초만 더 기다리세요.

서버 측 Redis

API 서버의 메모리가 캐시로 가득 차자 우리는 다른 솔루션을 생각해야 한다는 것을 깨달았습니다. 가장 간단한 아이디어는 이러한 모든 캐시를 전용 서버에 배치하고 메모리를 크게 구성하는 것입니다. 그런 다음 Redis에 중점을 두었습니다. . . Redis를 구성하고 배포하는 방법에 대해서는 여기서 설명하지 않습니다. Redis 공식에서는 자세한 소개를 제공합니다. 그러다가 별도의 서버를 Redis 서버로 사용하여 API 서버의 메모리 압박을 해결했습니다.

Persistence

단일 Redis 서버는 한 달에 며칠 동안 항상 기분이 좋지 않습니다. 기분이 좋지 않으면 파업에 들어가 모든 캐시가 손실됩니다(Redis 데이터는 저장됨). 기억에 글쎄). Redis 서버를 다시 온라인 상태로 되돌릴 수는 있지만 메모리 데이터 손실로 인해 캐시 사태가 발생하고 API 서버와 데이터베이스에 대한 부담이 갑자기 증가했습니다. 따라서 이때 캐시 사태의 영향을 완화할 수 있는 Redis의 지속성 기능이 도움이 됩니다. Redis의 지속성은 Redis가 메모리의 데이터를 하드 디스크에 쓰고 Redis가 다시 시작될 때 데이터를 로드하여 캐시 손실의 영향을 최소화한다는 것을 의미합니다.

Sentinel and Replication

Redis 서버가 경고 없이 공격을 받는 것은 골치 아픈 일입니다. 그럼 무엇을 해야 할까요? 대답은 다음과 같습니다. 머신 하나를 백업하고 연결을 끊습니다. 그렇다면 특정 Redis 서버가 다운되었는지 어떻게 알 수 있고, 전환하는 방법과, 백업 머신이 원본 서버의 완전한 백업인지 확인하는 방법은 무엇일까요? 이때 Sentinel과 Replication이 나타나야 합니다. Sentinel은 여러 Redis 서버를 관리할 수 있으며 모니터링, 알림 및 자동 장애 조치 기능을 제공합니다. 복제는 Redis 서버에 여러 백업 서버가 장착되도록 하는 역할을 합니다. Redis는 또한 Redis의 고가용성을 보장하기 위해 이 두 가지 기능을 사용합니다. 또한 Sentinel 기능은 Redis의 게시 및 구독 기능을 활용한 것입니다.

Cluster

단일 서버의 리소스에는 항상 상한이 있습니다. 마스터-슬레이브 복제를 사용하여 읽기 및 쓰기 CPU 리소스와 IO 리소스를 분리하고 CPU 및 IO 부담의 일부를 서버에 전달할 수 있습니다. 슬레이브 서버. 하지만 메모리 리소스는 어떻게 해야 할까요? 마스터-슬레이브 모드는 동일한 데이터만 백업하고 메모리를 수평으로 확장할 수 없습니다. 단일 머신의 메모리는 늘릴 수만 있지만 항상 상한이 있습니다. 따라서 수평적으로 확장할 수 있는 솔루션이 필요합니다. 궁극적인 목표는 각 서버가 그 일부만 책임지게 하여 모든 서버가 전체를 형성하도록 하는 것입니다. 외부 소비자에게 이 분산 서버 그룹은 중앙 집중식 서버와 같습니다

위 내용은 Redis에는 어떤 기능이 있나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!