Redis를 사용하는 일반적인 방법은 무엇입니까?

1. 일반적인 사용 방법

Redis의 여러 가지 일반적인 사용 방법은 다음과 같습니다.

2. Redis Sentinel(마스터-슬레이브)

4 .Redis 클러스터;

5.Redis 자체 개발.

2. 다양한 사용 방법의 장단점

1. Redis 단일 복사본

Redis 단일 복사본은 단일 Redis 노드 배포 아키텍처를 채택하고, 실시간으로 데이터를 동기화하는 백업 노드가 없으며, 데이터 지속성을 제공하지 않습니다. 백업 전략은 안정성 요구 사항이 낮은 데이터 순수 캐싱 비즈니스 시나리오에 적합합니다.

이점:
간단한 아키텍처 및 손쉬운 배포

높은 비용 성능: 캐시를 사용할 때 백업 노드가 필요하지 않습니다(단일 인스턴스 가용성은 감독자 또는 crontab에서 보장할 수 있음). 비즈니스의 높은 가용성도 희생될 수 있습니다. 대기 노드이지만 동시에 외부 서비스를 제공하는 인스턴스는 하나뿐입니다.

고성능.

단점:

데이터의 신뢰성을 보장하지 않습니다.

캐시를 사용하고 프로세스를 다시 시작한 후에는 고가용성을 해결하기 위한 백업 노드가 있어도 여전히 캐시 예열 문제를 해결할 수 없습니다. , 따라서 높은 성능을 요구하는 비즈니스에는 적합하지 않습니다.

고성능은 단일 코어 CPU의 처리 능력에 의해 제한되며(Redis는 단일 스레드 메커니즘) CPU가 주요 병목 현상입니다. 따라서 간단한 조작 명령과 정렬 및 계산이 적은 시나리오에 적합합니다. 대신 Memcached 사용을 고려할 수도 있습니다.

2. Redis 다중 복사(마스터-슬레이브)

Redis 다중 복사는 단일 복사에 비해 마스터-슬레이브(복제) 배포 구조를 채택하며, 가장 큰 특징은 마스터와 슬레이브 인스턴스 간의 실시간 데이터 동기화입니다. 데이터 지속성 및 백업 전략을 제공합니다. 회사의 기본 환경 구성을 통해 마스터-슬레이브 인스턴스를 서로 다른 물리적 서버에 배포하여 동시 외부 서비스 제공 및 읽기-쓰기 분리 전략을 달성할 수 있습니다.

이점:
높은 신뢰성: 한편으로는 기본 데이터베이스에 오류가 발생하면 자동으로 활성 및 대기 사이를 전환할 수 있는 이중 시스템 활성-대기 아키텍처를 채택하고 슬레이브 데이터베이스는 다음으로 승격됩니다. 서비스의 원활한 운영을 보장하기 위해 기본 데이터베이스에 서비스를 제공합니다. 반면에 데이터 지속성 기능을 켜고 합리적인 백업 전략을 구성하면 데이터 오작동 및 비정상적인 데이터 손실 문제를 효과적으로 해결할 수 있습니다. 분리 전략: 슬레이브 노드는 기본 데이터베이스 노드의 읽기 용량을 확장하여 대규모 동시 읽기 작업에 효과적으로 대처할 수 있습니다.

단점:

RedisHA 시스템이 없는 경우(개발 필요), 메인 데이터베이스 노드에 장애가 발생하면 비즈니스 당사자가 슬레이브 노드를 수동으로 마스터 노드로 승격해야 합니다. 구성을 변경하려면 알림을 받아야 하며 다른 슬레이브는 이를 수행해야 합니다. 라이브러리 노드는 새 기본 라이브러리 노드를 복제해야 합니다. 전체 프로세스에는 사람의 개입이 필요하며 상대적으로 번거롭습니다.

기본 라이브러리의 쓰기 용량은 단일로 제한됩니다. 머신이므로 샤딩을 고려할 수 있습니다.

메인 라이브러리의 저장 용량은 단일 머신으로 제한되므로 Pika를 고려할 수 있습니다.

네이티브 복제의 단점은 이전 버전에서도 더욱 두드러집니다. Redis 복제가 중단되면 슬레이브가 pync를 시작합니다. 이때 동기화가 실패하면 기본 라이브러리가 동시에 전체 백업을 수행할 수 있습니다. 이로 인해 밀리초 또는 두 번째 수준의 정지가 발생합니다. COW 메커니즘을 사용하면 극단적인 경우 메인 라이브러리 메모리가 오버플로되고 프로그램이 비정상적으로 종료되거나 충돌하게 되어 메인 라이브러리 노드가 백업 파일을 생성하여 서버 디스크 IO 및 CPU(압축) 리소스를 소비하게 됩니다. 몇 GB로 인해 서버의 송신 대역폭이 급격히 증가하고 요청이 차단됩니다. 최신 버전으로 업그레이드하는 것이 좋습니다.

3. Redis Sentinel(Sentinel)

Redis Sentinel은 커뮤니티 버전에서 출시된 기본 고가용성 솔루션으로, 배포 아키텍처는 주로 Redis Sentinel 클러스터와 Redis 데이터 클러스터로 구성됩니다.

Redis Sentinel 클러스터는 오류 검색, 자동 장애 조치, 구성 센터 및 클라이언트 알림을 실현할 수 있는 여러 Sentinel 노드로 구성된 분산 클러스터입니다. Redis Sentinel을 만족시키는 노드 수는 홀수여야 하며, 그 수는 2n+1(n≥1)입니다.

이점:

Redis Sentinel 클러스터 배포는 간단합니다.
Redis 마스터-슬레이브 모드의 고가용성 전환 문제를 해결할 수 있습니다.

Redis의 선형 확장을 구현하는 것이 매우 편리합니다. 데이터 노드 및 Redis를 쉽게 돌파 자체 단일 스레드 병목 현상은 Redis의 대용량 또는 고성능 비즈니스 요구 사항을 크게 충족할 수 있습니다.

Redis 데이터 노드 그룹 또는 여러 데이터 그룹을 모니터링하는 Sentinel 세트를 실현할 수 있습니다. 노드.

단점:

배포가 Redis 마스터-슬레이브 모드보다 더 복잡하고 원리 이해가 더 까다롭습니다.

리소스 낭비, Redis 데이터 노드의 슬레이브 노드는 백업 노드 역할을 하며 그렇지 않습니다.

Redis Sentinel은 주로 Redis 데이터 노드를 위한 것입니다. 마스터 노드의 고가용성 전환을 위해 Redis 데이터 노드의 실패 판단은 주관적 오프라인과 객관적인 오프라인으로 구분됩니다. 노드는 주관적으로 오프라인 상태이며 장애 조치가 수행되지 않습니다.

읽기와 쓰기 분리 문제를 해결할 수 없으며 구현하기가 상대적으로 복잡합니다.

권장 사항:

동일한 비즈니스를 모니터링하는 경우 Sentinel 클러스터를 선택하여 Redis 데이터 노드의 여러 그룹을 모니터링할 수 있습니다. 그렇지 않으면 Sentinel 클러스터를 선택하여 Redis 데이터 노드 그룹을 모니터링할 수 있습니다.

Sentinel 모니터 구성에서 권장되는 설정은 Sentinel 노드의 절반에 1을 더한 값입니다. Sentinel이 여러 IDC에 배포되는 경우 단일 IDC에 배포되는 Sentinel 수는 (Sentinel 수 – 정족수)을 초과하지 않는 것이 좋습니다.

우발적인 절단을 방지하고 전환 감도 제어를 제어하려면:

a.quorum

b.down-after-milliseconds 30000

c.maxclient

d. 배포된 각 노드의 서버 시간은 최대한 동기화되어야 합니다. 그렇지 않으면 로그 타이밍이 혼동됩니다.

Redis는 RTT 수를 줄이고 요청 효율성을 높이기 위해 파이프라인 및 다중 키 작업을 사용할 것을 권장합니다.

인스턴스 링크에 대한 클라이언트 액세스를 용이하게 하기 위해 구성 센터(zookeeper)를 직접 구성하세요.

4. Redis 클러스터

Redis 클러스터는 커뮤니티 버전에서 출시된 Redis 분산 클러스터 솔루션입니다. 예를 들어 단일 머신 메모리, 동시성 및 트래픽과 같은 병목 현상이 발생할 때 Redis 클러스터입니다. 이는 좋은 로드 밸런싱의 목적을 달성할 수 있습니다.

Redis Cluster 클러스터 노드의 최소 구성은 6개 노드(마스터 3개, 슬레이브 3개) 이상입니다. 마스터 노드는 읽기 및 쓰기 작업을 제공하고, 슬레이브 노드는 백업 노드 역할을 하며 요청을 제공하지 않습니다. 장애 조치에만 사용됩니다.

Redis 클러스터는 가상 슬롯 파티셔닝을 사용합니다. 모든 키는 해시 함수에 따라 0~16383 정수 슬롯에 매핑됩니다. 각 노드는 슬롯의 일부와 슬롯에 매핑된 키 값 데이터를 유지 관리합니다.

장점:
중앙 아키텍처가 없습니다.

데이터는 슬롯에 따라 여러 노드에 저장 및 배포되고, 노드 간에 데이터가 공유되며, 데이터 배포는 동적으로 조정될 수 있습니다.

확장성: 더 많은 노드로 선형 확장 가능 1,000개 이상의 노드를 동적으로 추가하거나 삭제할 수 있습니다.

고가용성: 일부 노드를 사용할 수 없어도 클러스터를 계속 사용할 수 있습니다. 슬레이브를 대기 데이터 복사본으로 추가하면 노드가 가십 프로토콜을 통해 상태 정보를 교환하고 투표 메커니즘을 사용하여 슬레이브에서 마스터로 역할 승격을 완료할 수 있습니다.

운영 및 유지 관리 비용을 줄이고 확장성을 향상시킵니다. 그리고 시스템의 가용성.

단점:

클라이언트 구현이 복잡하고 드라이버에서 슬롯 매핑 정보를 캐싱하고 적시에 업데이트하는 스마트 클라이언트 구현이 필요하므로 클라이언트의 미성숙이 비즈니스 안정성에 영향을 미칩니다. 현재 JedisCluster만이 상대적으로 성숙하고 일반적인 "최대 리디렉션 예외"와 같은 예외 처리 부분은 아직 완벽하지 않습니다.

어떤 이유로 인해 노드가 차단되며(차단 시간이 clutser-node-timeout보다 큼) 오프라인 상태로 판단됩니다. 이러한 장애 조치는 필요하지 않습니다.

데이터는 비동기식으로 복제되며 데이터의 강력한 일관성이 보장되지 않습니다.

여러 기업이 동일한 클러스터를 사용하는 경우 통계 기반의 핫 데이터와 콜드 데이터를 구분하는 것이 불가능하며, 리소스 격리가 불량하고 상호 영향이 발생하기 쉽습니다.

슬레이브는 클러스터에서 "콜드 대기" 역할을 하며 읽기 부담을 완화할 수 없습니다. 물론 SDK의 합리적인 설계를 통해 슬레이브 리소스의 활용도를 향상시킬 수 있습니다.

mset 및 mget 사용과 같은 주요 일괄 작업 제한은 현재 일괄 작업을 수행하기 위해 동일한 슬롯 값을 가진 키만 지원합니다. 다른 슬롯 값에 매핑된 키의 경우 키는 슬롯 간 쿼리를 지원하지 않으므로 mset, mget, sunion과 같은 작업을 수행하는 것이 사용자에게 친숙하지 않습니다.

키 트랜잭션 작업 지원은 제한되어 있습니다. 동일한 노드에 있는 여러 키의 트랜잭션 작업만 지원합니다. 여러 키가 서로 다른 노드에 분산된 경우 트랜잭션 기능을 사용할 수 없습니다.

큰 키 값 개체(예: 해시, 목록 등)가 포함된 데이터는 다른 노드에 매핑될 수 없습니다. 데이터 분할에서는 키가 가장 작은 단위이기 때문입니다.

여러 데이터베이스 공간은 지원되지 않습니다. 독립형 모드의 Redis는 최대 16개의 데이터베이스를 지원할 수 있습니다. 클러스터 모드에서는 db 0인 1개의 데이터베이스 공간만 사용할 수 있습니다.

복제 구조는 한 레벨만 지원합니다. 슬레이브 노드는 마스터 노드만 복제할 수 있으며 중첩 트리 복제 구조는 지원되지 않습니다.

기본 라이브러리 노드가 시스템의 단점이 되도록 단축키 생성을 피하세요.

네트워크 카드 과부하, 쿼리 속도 저하 등을 초래할 수 있는 큰 키 생성을 피하세요.

재시도 시간은 클러스터 노드 시간 시간보다 커야 합니다.

Redis 클러스터는 최대 리디렉션 시나리오를 줄이기 위해 파이프라인 및 다중 키 작업을 사용하는 것을 권장하지 않습니다.

JVM, 잠금, 높은 동시성, 반사, Spring 원칙, 마이크로서비스, Zookeeper, 데이터베이스, 데이터 구조 등을 다루는 인터뷰 가이드 "Java 핵심 지식 포인트 편집.pdf"와 Java208 인터뷰 질문(포함)을 공유합니다. 답변)은 (Java Advanced Architecture) 705127209에 가입하면 무료로 얻을 수 있습니다!

5. Redis 자체 개발

Redis의 자체 개발 고가용성 솔루션은 주로 구성 센터, 오류 감지 및 장애 조치 처리 메커니즘에 반영되며 일반적으로 기업 비즈니스의 실제 온라인 환경에 따라 사용자 정의해야 합니다. .

장점:

높은 안정성과 고가용성,

높은 자율성과 제어 가능성,

실제 비즈니스 요구 사항에 적합, 우수한 확장성 및 우수한 호환성.

단점:

복잡한 구현 및 높은 개발 비용

모니터링, 도메인 이름 서비스, 메타데이터 정보 저장을 위한 데이터베이스 등 지원 주변 시설 구축 필요

높은 유지 관리 비용.

위 내용은 Redis를 사용하는 일반적인 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!