(1) 캐시가 방금 만료되었습니다. (2) A에게 데이터베이스를 쿼리하고 이전 값을 가져오도록 요청합니다. (3) B에게 데이터베이스에 새 값을 쓰도록 요청합니다. (4) B에게 캐시 삭제 요청 (5) A에게 발견된 이전 값을 캐시에 쓰도록 요청합니다.

그러나 2와 3 중 3이 2보다 빠른 경우에만 B는 캐시를 먼저 삭제하고 A는 이전 값으로 캐시를 씁니다.

실제로 데이터베이스에 쓰는 것은 읽는 것보다 훨씬 느리므로 느린 SQL을 피하십시오.

(1) 캐시를 먼저 제거하세요 (2) 데이터베이스를 다시 작성합니다. (이 두 단계는 이전과 동일합니다.) (3) 1초간 Sleep 후 캐시를 다시 제거합니다.

비동기 이중 삭제 사용

개수와 길이를 확인하세요.

키 또는 키 아래의 특정 필드가 존재하는지, 포함하는지, 추가하는지, 증가 또는 감소하는지 여부

삭제, 지정된 위치 삭제, 삭제 및 가져오기

무료 테마

열쇠

세트

목록

주문한 컬렉션

거래

해시시

무료 테마

문자열 크기를 확장해야 하는 경우 1M보다 작으면 두 배로 늘어납니다. 1M보다 크면 매번 1M씩만 확장됩니다. 최대 길이는 512M입니다.

자체 증가 값이 최대값을 초과하면 오류가 보고됩니다.

컨테이너형 데이터 구조의 경우 컨테이너가 없으면 생성하고, 요소가 더 이상 존재하지 않으면 컨테이너를 삭제합니다.

잠금 받기

터놓다

a) Redis에서 마스터-슬레이브 전환이 발생하면 일부 잠금이 손실될 수 있습니다.

실제로 Zookeeper가 구현하는 분산 잠금에는 단점이 있습니다. 즉, 성능이 캐시 서비스만큼 높지 않을 수 있다는 것입니다. 잠금 기능을 구현하려면 잠금을 생성하고 해제하는 과정에서 매번 임시 노드를 동적으로 생성하고 삭제해야 하기 때문입니다. ZK에서 노드 생성 및 삭제는 Leader 서버를 통해서만 수행할 수 있으며, 해당 데이터는 모든 Follower 시스템과 공유되지 않습니다. 동시성 문제에는 네트워크 지터가 포함될 수 있으며, 클라이언트와 ZK 클러스터 간의 세션 연결이 끊어집니다. ZK 클러스터는 클라이언트가 다운되었다고 생각하고 이때 다른 클라이언트가 분산 잠금을 얻을 수 있습니다.

Redis는 공정성을 달성하기 어렵습니다.

알고리즘의 분산 버전에서는 N개의 Redis 호스트가 있다고 가정합니다. 노드는 완전히 독립적이므로 복제나 기타 암시적 조정 시스템을 사용하지 않습니다. 단일 인스턴스 내에서 잠금을 안전하게 획득하고 해제하는 방법을 설명했습니다. 우리는 알고리즘이 이 방법을 사용하여 단일 인스턴스에서 잠금을 획득하고 해제하는 것을 당연하게 여깁니다. 이 예에서는 합리적인 값인 N = 5를 설정했으므로 서로 다른 컴퓨터 또는 가상 머신에서 5개의 Redis 마스터 서버를 실행하여 대부분 독립적인 방식으로 실패하도록 해야 합니다. 잠금을 획득하기 위해 클라이언트는 다음 작업을 수행합니다. 1. 현재 시간을 밀리초 단위로 가져옵니다. 2. 모든 인스턴스에서 동일한 키 이름과 임의의 값을 사용하여 모든 N 인스턴스에서 순서대로 잠금을 획득하려고 시도합니다. 2단계에서 각 인스턴스에 잠금이 설정되면 클라이언트는 잠금을 획득하기 위해 총 잠금 자동 해제 시간에 비해 작은 시간 제한을 사용합니다. 예를 들어, 자동 릴리스 시간이 10초인 경우 제한 시간은 ~5~50ms 범위일 수 있습니다. 이렇게 하면 클라이언트가 오랜 시간 동안 차단되어 Redis 노드와의 통신을 시도하거나 실패하는 것을 방지할 수 있습니다. 인스턴스를 사용할 수 없는 경우 가능한 한 빨리 다음 인스턴스와 통신해야 합니다. 3. 클라이언트는 현재 시간에서 1단계에서 얻은 타임스탬프를 빼서 잠금을 획득하는 데 필요한 시간을 계산합니다. 클라이언트가 대부분의 인스턴스(최소 3개)에서 잠금을 획득할 수 있고 잠금을 획득하는 데 경과된 총 시간이 잠금 유효 시간보다 짧은 경우에만 잠금이 획득된 것으로 간주됩니다. 4. 잠금이 획득되면 해당 유효 시간은 3단계에서 계산된 대로 초기 유효 시간에서 경과 시간을 뺀 것으로 간주됩니다. 5. 클라이언트가 어떤 이유로 잠금 획득에 실패하면(N/2 1 인스턴스를 잠글 수 없거나 유효 시간이 음수) 모든 인스턴스의 잠금을 해제하려고 시도합니다(잠글 수 없다고 생각하더라도).

노드가 중단되면 잠금이 선점될 위험이 없습니다.

집단적 실패를 방지하기 위해 실패 시간에 임의의 값을 설정합니다.

사용자 게시물 ID 목록을 기록합니다.

핫리스트 게시물 ID 목록을 전체 핫리스트, 카테고리 핫리스트로 기록합니다.

일대다 녹음에 사용되며 다수가 참여하는 경우 엄격하게 반복할 수 없습니다.

사용자 또는 전체 시스템과 관련될 수 있는 특정 컬렉션을 기록합니다.

게시물에 대한 좋아요, 댓글, 클릭 수를 기록합니다.

게시물 제목, 초록, 저자, 표지 정보 등을 기록합니다.

최근 핫 게시물 콘텐츠를 캐시합니다. (게시물 콘텐츠가 너무 커서 DB에서 가져오기에 적합하지 않습니다.)

해당 게시물의 관련 글 목록을 기록하고, 해당 내용을 바탕으로 관련 게시물을 추천해 드립니다.

주로 메모리를 절약하기 위해 부울 배열 또는 사용자 정의 비트 배열로 사용됩니다.

중복제거 후 통계값을 대략적으로 계산하는데 사용됩니다.

총 개수만 더하고 얻을 수 있지만, 특정 값이 존재하는지 아니면 모든 요소가 존재하는지를 얻을 수는 없습니다.

중복 항목을 제거하는 데 사용됩니다. 목록에 요소가 존재하는지 확인합니다.

프로젝트 규모가 크지 않고 유지 관리 비용이 높지 않은 경우 redsi-cell을 직접 사용할 수 있습니다. 그렇지 않으면 각 서비스 노드에 대한 세밀한 제어를 고려하여 흐름을 제한하고 해당 로드 밸런싱 전략으로 구현할 수 있습니다.

zset 및 점수를 사용하여 시간 창에 동그라미를 치고 해당 시간 창 내에서 동일한 사용자에 대해 동일한 동작이 발생한 횟수를 계산합니다. 현재 제한 수가 너무 많으면 초당 1,000회와 같이 적용되지 않을 수 있습니다. .

CL.스로틀 테스트 100 400 60 3

1: 성공 여부, 0: 성공, 1: 거부 2: 토큰 버킷의 용량, 크기는 초기값 1입니다. 3: 현재 토큰 버킷에서 사용 가능한 토큰 4: 요청이 거부된 경우 이 값은 토큰이 퍼널 버킷에 다시 추가되기까지 걸리는 시간을 나타냅니다. 단위는 초이며, 이는 재시도 시간으로 사용될 수 있습니다. 5: 토큰 버킷의 토큰이 가득 차는 데 걸리는 시간을 나타냅니다.

깔때기 알고리즘

일반 연결 목록의 추가 메모리 오버헤드를 피하기 위해 압축된 연결 목록 또는 배열로 구성됩니다.

메모리를 최대한 절약하도록 설계된 이중 연결 목록

문자열 또는 정수 저장

값 저장을 위해 가변 길이 인코딩을 사용하여 세부적으로 메모리를 절약합니다.

해시, 목록, zset의 기본 데이터 구조 구현

특징

1) 고성능 요구사항이 있는 시나리오에서 ziplist를 사용할 경우 길이는 1000을 초과하지 않고 각 요소의 크기는 512바이트 이내로 제어하는 ​​것이 좋습니다.

스킵 리스트는 O(logN) 평균 검색과 최악의 O(N) 복잡도 검색을 지원합니다.

점프 테이블 대신 나무나 균형 잡힌 나무를 사용하면 어떨까요?

압축된 연결리스트는 포인터를 사용하여 연결되어 연결리스트가 됩니다.

각 ziplist의 기본값은 8k입니다(구성 가능).

2) info Commandstats 명령을 사용하여 각 명령에 대한 호출 수를 포함한 평균 명령 시간을 얻습니다. , 소요된 총 시간, 소요된 평균 시간(마이크로초)입니다.

Redis의 복제 기능은 동기화(sync)와 명령 전파(command propagate)라는 두 가지 작업으로 나뉩니다.

읽기와 쓰기의 분리는 대규모 액세스(단일 Redis 시스템이 매우 느리게 느껴질 정도로 큰 액세스)에 적합하며 쓰기 작업은 읽기 작업보다 훨씬 작습니다.

읽기 요청 수가 쓰기 요청을 훨씬 초과하는 경우 클러스터 데이터 복사 비용은 읽기 요청 비용보다 훨씬 적습니다. 동시에 데이터 불일치를 어느 정도 수용할 수 있다면 읽기와 쓰기를 분리할 수 있습니다.

1. 모든 Redis 노드는 서로 상호 연결되어 있으며(PING-PONG 메커니즘), 내부적으로 바이너리 프로토콜을 사용하여 전송 속도와 대역폭을 최적화합니다.

2. 노드 장애는 클러스터 내 노드 중 절반 이상이 장애를 감지한 경우에만 적용됩니다.

3. 클라이언트는 중간 프록시 계층이 필요 없이 Redis 노드에 직접 연결됩니다. 클라이언트는 클러스터의 모든 노드에 연결할 필요가 없으며 클러스터에서 사용 가능한 노드에 연결하기만 하면 됩니다.

4. redis-cluster는 모든 물리적 노드를 [0-16383] 슬롯에 매핑하며(반드시 균등하게 분산될 필요는 없음) 클러스터는 노드<->슬롯<->값을 유지하는 역할을 담당합니다.

5. Redis 클러스터는 16384개의 버킷으로 사전 분할되어 있습니다. Redis 클러스터에 키-값을 배치해야 할 경우 키를 배치해야 하는 CRC16(key) mod 16384 값에 따라 결정됩니다.

각 Redis 인스턴스는 다른 노드의 존재를 인식합니다.

1. 클라이언트가 기본 서버 노드 B에 씁니다. 2. 메인 서버 노드 B는 클라이언트에게 확인 응답을 보냅니다. 3. 마스터 서버 노드 B는 슬레이브 서버 B1, B2 및 B3에 쓰기를 전파합니다.

2단계 이후 슬레이브 서버에서 데이터가 전송되지 않고 B가 전화를 끊으면 키가 손실됩니다. (실패 시 키는 반드시 손실됩니다.)

선택 프로세스에는 클러스터의 모든 마스터가 참여합니다. 마스터 노드의 절반 이상이 실패한 노드와 (cluster-node-timeout) 이상 통신하는 경우 해당 노드는 결함이 있는 것으로 간주되며 자동으로 장애 조치 작업이 수행됩니다. 트리거되었습니다.

(2): 언제 전체 클러스터를 사용할 수 없게 됩니까(cluster_state:fail)? a: 클러스터의 마스터 중 하나가 종료되고 현재 마스터에 슬레이브가 없는 경우 클러스터는 실패 상태로 진입합니다. 이는 클러스터의 슬롯 매핑[0-16383]이 완료되지 않은 경우 실패 상태로 진입하는 것으로 이해될 수도 있습니다. b: 실패 상태로 진입하는 슬레이브 클러스터가 있는지 여부에 관계없이 클러스터의 마스터 중 절반 이상이 죽는 경우.

클러스터를 사용할 수 없으면 클러스터의 모든 작업을 사용할 수 없으며 ((error) CLUSTERDOWN The Cluster is down) 오류가 수신됩니다.

1. 오프라인 마스터 노드의 모든 슬레이브 노드가 선출되어 새로운 마스터 노드가 선출됩니다. 2. 선택한 슬레이브 노드는 슬레이브 no one 명령을 실행하고 새로운 마스터 노드가 됩니다. 3. 새 마스터 노드는 오프라인 마스터 노드에 대한 모든 슬롯 할당을 취소하고 이러한 슬롯을 자신에게 할당합니다. 4. 새로운 마스터 노드는 퐁 메시지를 클러스터에 브로드캐스트합니다. 이 퐁 메시지를 통해 클러스터의 다른 노드는 해당 노드가 슬레이브 노드에서 마스터 노드로 변경되었으며, 마스터 노드가 서버를 인수했음을 즉시 알 수 있습니다. 원래 오프라인이었던 슬롯입니다. 5. 새로운 마스터 노드는 처리를 담당하는 슬롯과 관련된 명령 요청을 수락하기 시작하고 장애 조치 작업이 완료됩니다.

1. 슬레이브 노드가 자신이 복제하는 마스터 노드가 오프라인 상태가 된 것을 발견하면 슬레이브 노드(여기서 요청하는 슬레이브 노드가 여러 개 있을 수 있음)는 클러스터에 Cluster_type_failover_auth_request 메시지를 브로드캐스트하여 투표 권한(슬롯 처리 담당)을 요구합니다. 마스터 노드가 이 노드에 투표합니다. 2. Cluster_type_failover_auth_request 메시지를 수신한 마스터 노드는 자신의 조건에 따라 슬레이브 노드와 새로운 마스터 노드가 되는 데 동의하는지 여부를 판단합니다(개시 투표 노드의 현재 에포크가 투표 노드의 현재 에포크보다 낮지 않음). ) 동의하면 Cluster_type_failover_auth_ack 메시지가 반환됩니다. 3. 노드로부터 Cluster_type_failover_auth_ack 메시지를 수신하면 투표 수가 1 증가합니다. 4. 슬레이브 노드의 투표가 클러스터에 있는 마스터 노드의 절반 이상(N/2 1 이상)인 경우 이 노드가 새로운 마스터 노드가 됩니다. 구성 주기 동안 슬레이브 노드가 충분한 투표를 받지 못하면 클러스터는 새로운 구성 주기에 들어가고 새 마스터 노드가 선출될 때까지 여기에서 선거가 진행됩니다.

모든 슬레이브 노드는 자신이 마스터가 될 수 있는지에 대한 의견을 구할 수 있으며(투표하는 사람은 자신의 더 큰 노드에만 투표합니다) 그 중 절반 이상이 (n 1)/2가 될 수 있습니다.

어쩌면 난 선택할 수 없을지도 몰라

1. 현재는 동일한 슬롯에 있는 키의 일괄 작업만 지원됩니다. 2. 현재는 동일한 슬롯의 주요 트랜잭션만 지원됩니다. 3. 데이터베이스 0만 사용할 수 있습니다(각 redis 인스턴스에는 16개의 데이터베이스가 있으며, 이는 select {index} 명령을 통해 전환할 수 있음). 4. 큰 키(예: 해시, 목록)는 다른 노드에 매핑될 수 없습니다. 5. 현재 클러스터 마스터-슬레이브 복제는 한 수준만 지원하며 중첩 트리 구조는 지원하지 않습니다.

단계

각 노드는 각 슬롯에 해당하는 클러스터 노드를 알고 있습니다.

노드는 명령 요청을 받으면 자체적으로 처리할 수 있는지 쿼리하고 그렇지 않으면 이동 오류를 반환합니다. 클라이언트는 이를 실행하도록 안내합니다. 그리고 클라이언트의 모든 후속 작업은 키가 실행되면 이동된 오류가 제공하는 노드로 이동합니다.

Codis의 Codis Dashbord가 슬롯 정보를 변경하면 다른 Codis 노드가 ZooKeeper 슬롯 변경 사항을 모니터링하고 시간에 맞춰 동기화합니다. 그림과 같이:

zk는 슬롯 정보 동기화를 담당합니다.

여러 대기열을 사용하여 우선순위 대기열을 구현합니다. 서로 다른 우선순위 작업은 서로 다른 대기열에 들어갑니다.

동시에 소비자가 대기열에서 데이터를 가져올 때 우선순위에 따라 여러 대기열에서 데이터 가져오기를 지원합니다.

여러 소비자를 시작한다는 것은 데이터를 검색하기 위해 여러 클라이언트를 시작한다는 의미입니다.

사용

위험

1. 주어진 목록에 팝업할 요소가 없으면 대기 시간이 초과되거나 팝 가능한 요소가 발견될 때까지 BRPOP 명령에 의해 연결이 차단됩니다. 2. 여러 키 매개변수가 제공되면 각 목록은 매개변수 키에 따라 순서대로 검사되고 비어 있지 않은 첫 번째 목록의 꼬리 요소가 나타납니다. 또한 팝업 요소의 위치가 BLPOP과 다른 점을 제외하면 BRPOP은 동일하게 동작합니다.

목록에 작업이 없으면 연결이 차단됩니다. 연결 차단에 대한 시간 초과가 있습니다. 시간 초과를 0으로 설정하면 메시지가 나타날 때까지 무선으로 기다릴 수 있습니다.

A와 B 사이의 두 비즈니스 간의 구독 및 출판에 적합합니다. 여러 비즈니스 라인이 서로 다른 소비자를 의미하는 경우 더 어렵습니다.

확인 구현