Redis를 배포하는 방법

1 Redis를 사용하는 이유

프로젝트에서 Redis를 사용할 때 성능과 동시성이라는 두 가지 주요 고려 사항이 있습니다. 단순히 분산 잠금 등 다른 기능을 위한 것이라면 대신 Zookpeer 등 다른 미들웨어가 있으므로 Redis를 사용할 필요는 없습니다.

성능:

아래 그림과 같이 실행 시간이 유난히 오래 걸리고 결과가 자주 바뀌지 않는 SQL을 접할 경우, 실행 결과를 캐시에 넣는 것이 특히 적합합니다. 이런 방식으로 후속 요청을 캐시에서 읽어오므로 요청에 신속하게 응답할 수 있습니다.

특히 플래시 세일 시스템에서는 거의 모든 사람들이 동시에 클릭하고 주문을 하고 있습니다. . . 데이터베이스에서 데이터를 쿼리하는 것과 동일한 작업이 수행됩니다.

상호작용 효과에 따라 응답 시간에 대한 정해진 기준은 없습니다. 이상적인 세상에서는 페이지 점프가 즉시 해결되어야 하고, 페이지 내 작업도 즉시 해결되어야 합니다.

동시성:

아래 그림과 같이 대규모 동시성의 경우 모든 요청이 데이터베이스에 직접 액세스하며 데이터베이스에는 연결 예외가 발생합니다. 이때 요청이 데이터베이스에 직접 접근하는 것이 아니라 먼저 Redis에 접근할 수 있도록 Redis를 이용하여 버퍼링 작업을 수행해야 합니다.

Redis 사용 시 자주 묻는 질문

• 캐시 및 데이터베이스 이중 쓰기 일관성 문제
• 캐시 눈사태 문제
• 캐시 분석 문제
• 캐시 동시성 경합 문제

초 단일 스레드 Redis가 필요한 이유 이렇게 빠른가요

이 질문은 Redis의 내부 메커니즘에 대한 조사입니다. 많은 사람들은 Redis에 단일 스레드 작업 모델이 있다는 사실을 모릅니다.

이유는 주로 다음 세 가지 때문입니다.

• 순수한 메모리 작업
• 단일 스레드 작업, 빈번한 컨텍스트 전환 방지
• 비차단 I/O 다중화 메커니즘 사용

에 대해 이야기해 보겠습니다. I/O 멀티플렉싱 메커니즘을 자세히 설명하자면 다음과 같습니다. 내 이름은 A 도시에서 패스트푸드 레스토랑을 열고 같은 도시에서 패스트푸드 서비스를 담당하고 있습니다. 재정적 제약으로 인해 Xiao Ming은 배달원 그룹을 고용했습니다. 그러다가 Xiao Qu는 자금이 충분하지 않아 특급 배송을 위해 자동차만 구입할 수 있다는 것을 알게 되었습니다.

비즈니스 방법 1

고객이 주문할 때마다 Xiao Ming은 배달원이 그것을 지켜보고 배달하도록 하는 것입니다. Xiaoqu는 이 비즈니스 방법에서 다음과 같은 문제점을 천천히 발견했습니다.

자동차를 잡는 데 시간이 소요되고 대부분의 배달원은 한가하며 자동차를 잡은 후에만 배달할 수 있습니다.

• 주문량이 늘어나면서 배달원도 점점 더 많아졌습니다. Xiao Ming은 택배 매장이 점점 더 혼잡해지고 새로운 배달원을 고용할 방법이 없다는 것을 알게 되었습니다.
• 배달 담당자 간의 조정에는 시간이 걸립니다.
• 샤오밍은 위의 단점을 토대로 경험을 통해 두 번째 사업 방식을 제안했습니다.

비즈니스 방법 2

샤오밍은 배달원을 한 명만 고용합니다. 고객이 주문을 하면 샤오밍이 배송 위치를 표시해 한 곳에 모아둔다. 마지막으로 배달원이 차를 운전해 물건을 하나씩 배달하고, 배달 후 다음 물건을 찾으러 다시 오도록 하세요. 위의 두 가지 비즈니스 방법을 비교하면 두 번째 방법이 더 효율적이라는 것은 분명합니다.

위 비유에서:

• 각 배달원→각 스레드
• 각 주문→각 소켓(I/O 스트림)
• 주문 배송 위치→소켓의 다양한 상태
• 고객 음식 배달 요청→ 클라이언트의 요청
• Mingqu의 비즈니스 방식—서버에서 실행되는 코드
• 자동차—CPU 코어 수

그래서 우리는 다음과 같은 결론을 얻었습니다.

• 비즈니스 방식 1은 전통적인 동시성 모델입니다. I/O 스트림(주문)은 새로운 스레드(배달 담당자)에 의해 관리됩니다.
• 두 번째 관리 방법은 I/O 다중화입니다. 각 I/O 스트림의 상태(각 전달자의 전달 위치)를 추적하여 여러 I/O 스트림을 관리하는 단일 스레드(한 명의 전달자)만 있습니다.

다음은 그림과 같이 실제 Redis 스레드 모델과 유사합니다.

Redis-client는 작업 중에 다양한 이벤트 유형으로 소켓을 생성합니다. 서버 측에는 이를 대기열에 넣는 I/O 멀티플렉서가 있습니다. 그런 다음 파일 이벤트 디스패처는 이를 대기열에서 차례로 가져와서 다른 이벤트 프로세서로 전달합니다.

세 가지 Redis 데이터 유형 및 사용 시나리오

자격을 갖춘 프로그래머는 이 다섯 가지 유형을 사용합니다.

String

가장 일반적인 설정/가져오기 작업으로, 값은 문자열 또는 숫자일 수 있습니다. 일반적으로 일부 복잡한 계산 기능이 캐시됩니다.

Hash

여기서 Value는 구조화된 객체를 저장하며 그 안에 특정 필드를 조작하는 것이 더 편리합니다. 저는 Single Sign-On을 할 때 CookieId를 키로 사용하고 캐시 만료 시간을 30분으로 설정하여 사용자 정보를 저장하는 데 이 데이터 구조를 사용했는데, 이는 세션과 유사한 효과를 매우 잘 시뮬레이션할 수 있습니다.

List

List 데이터 구조를 사용하면 간단한 메시지 대기열 기능을 수행할 수 있습니다. 또한 lrange 명령을 사용하여 뛰어난 성능과 우수한 사용자 경험을 제공하는 Redis 기반 페이징 기능을 구현할 수 있습니다. Set

세트는 고유한 값의 집합이기 때문입니다. 따라서 전역 중복 제거 기능을 구현할 수 있습니다. 우리 시스템은 일반적으로 클러스터로 배포되므로 JVM과 함께 제공되는 Set을 사용하는 것이 번거롭습니다. 또한

교집합, 합집합, 차이 등의 연산을 이용하여 공통선호, 전체선호, 나만의 고유선호 등을 계산할 수 있습니다.

Sorted Set

Sorted Set에는 추가

가중치 매개변수 Score

가 있으며, 세트의 요소는 Score에 따라 정렬될 수 있습니다. 순위 애플리케이션을 사용하여 TOP N 작업을 얻을 수 있습니다. 정렬된 세트는 지연된 작업을 수행하는 데 사용할 수 있습니다.

네 가지 Redis 만료 전략 및 메모리 제거 메커니즘

Redis가 집에서 사용되는지 여부는 여기에서 알 수 있습니다. 예를 들어 Redis는 5G 데이터만 저장할 수 있지만 10G를 쓰면 5G의 데이터가 삭제됩니다. 이 문제에 대해 어떻게 생각해보셨나요?

정답: Redis는 일반 삭제 + 지연 삭제 전략을 채택합니다.

예약 삭제 전략을 사용하면 어떨까요?

예약 삭제, 타이머를 사용하여 키를 모니터링하면 키가 만료되면 자동으로 삭제됩니다. 메모리는 제때 해제되지만 CPU 리소스를 많이 소모합니다.

대규모 동시 요청의 경우 CPU는 키를 삭제하는 대신 요청을 처리하는 데 시간을 사용해야 하므로

이 전략은 채택되지 않습니다.

일반 삭제 + 지연 삭제 작동 방식

정기 삭제, Redis는 기본적으로 100ms마다 확인하고 만료된 키를 삭제합니다. Redis는 100ms마다 모든 키를 확인하지 않고 무작위로 선택하여 확인한다는 점에 유의해야 합니다. 일반 삭제 전략만 채택하면 그때까지 많은 키가 삭제되지 않습니다. 따라서 게으른 삭제가 유용합니다.

일반삭제 + 지연삭제를 사용하면 다른 문제는 없나요?

아니요, 일반삭제를 해도 Key가 삭제되지 않는다면요. 그리고 제때에 키를 요청하지 않았으므로 지연 삭제가 적용되지 않았습니다. 이런 식으로 Redis의 메모리는 점점 더 높아질 것입니다. 그런 다음 메모리 제거 메커니즘을 채택해야 합니다.

redis.conf에는 다음과 같은 구성 라인이 있습니다:

# maxmemory-policy 휘발성-lru

이 구성에는 메모리 제거 전략이 탑재되어 있습니다:

noeviction: 메모리가 새로 작성된 내용을 수용하기에 충분하지 않은 경우 데이터, 새 쓰기 작업에서 오류가 보고됩니다.

• allkeys-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 키 공간에서 가장 최근에 사용된 키를 제거합니다. (권장, 현재 프로젝트에서 사용 중) (가장 최근에 사용된 알고리즘)
• allkeys-random: 새로 작성된 데이터를 수용할 만큼 메모리가 부족할 경우 키 공간에서 Key를 무작위로 제거합니다. (아무도 사용하지 않을 것 같습니다. 키를 삭제하지 않을 경우에는 가장 최근의 키를 사용하여 임의로 삭제해 주세요.)
• 휘발성-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 부족할 때, 만료 시간이 설정된 키 공간에서 가장 최근에 사용된 키 공간을 제거합니다. 이 상황은 일반적으로 Redis가 캐시와 영구 저장소로 사용될 때 사용됩니다. (권장하지 않음)
• 휘발성-random: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 키를 무작위로 제거합니다. (아직 권장하지 않음)
• 휘발성-ttl: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 만료 시간이 더 빠른 키가 먼저 제거됩니다. (권장하지 않음)

5가지 Redis 및 데이터베이스 이중 쓰기 일관성 문제

일관성 문제는

최종 일관성과 강력한 일관성

으로 더 나눌 수 있습니다. 데이터베이스와 캐시가 이중으로 기록되면 필연적으로 불일치가 발생합니다. 전제는 데이터에 대한 강력한 일관성 요구 사항이 있으면 캐시할 수 없다는 것입니다. 우리가 하는 모든 일은 최종 일관성만 보장할 수 있습니다.

또한 근본적으로 우리가 만들어낸 솔루션은 불일치 가능성을 줄일 수 있을 뿐입니다. 따라서

강력한 일관성 요구 사항이 있는 데이터는 캐시할 수 없습니다

. 우선, 올바른 업데이트 전략을 채택하고 먼저 데이터베이스를 업데이트한 다음 캐시를 삭제하세요. 둘째, 캐시 삭제 실패 문제가 발생할 수 있으므로 메시지 큐를 활용하는 등의 보상 방안을 마련하면 된다.

Six 캐시 침투 및 캐시 눈사태 문제를 처리하는 방법

이 두 가지 문제는 일반적으로 중소 규모의 전통적인 소프트웨어 회사가 직면하기 어렵습니다. 수백만 명의 트래픽이 발생하는 대규모 동시 프로젝트가 있는 경우 이 두 가지 문제를 깊이 고려해야 합니다. 캐시 침투란 해커가 의도적으로 캐시에 존재하지 않는 데이터를 요청하여 모든 요청이 데이터베이스로 전송되어 데이터베이스 연결이 비정상적으로 되는 것을 의미합니다.

캐시 침투 솔루션:

• 캐시가 실패하면 먼저 잠금을 획득한 다음 데이터베이스를 요청하세요. 잠금을 획득하지 못한 경우 잠시 잠자기 상태가 된 후 다시 시도합니다.
비동기 업데이트 전략
• 을 채택하여 키가 값을 가져오든 받지 않든 직접 반환됩니다. 캐시 만료 시간은 값 값에 유지됩니다. 캐시가 만료되면 스레드가 비동기적으로 시작되어 데이터베이스를 읽고 캐시를 업데이트합니다. 캐시 예열(프로젝트 시작 전 캐시 로딩) 작업이 필요합니다. 요청이 유효한지 신속하게 확인할 수 있는 차단 메커니즘을 제공합니다. 예를 들어 Bloom 필터를 사용하여 일련의 합법적이고 유효한 키를 내부적으로 유지 관리합니다. 요청에 포함된 키가 합법적이고 유효한지 신속하게 확인합니다. 불법이라면 직접 반납하세요.

Cache Avalanche, 즉 넓은 영역에서 동시에 캐시가 실패하는 현상입니다. 이때 또 다른 요청의 물결이 들어오고 결과적으로 요청이 모두 데이터베이스로 전송되어 오류가 발생합니다. 비정상적인 데이터베이스 연결.

캐시 눈사태 솔루션:

전체 오류를 방지하려면 캐시 만료 시간에 임의의 값을 추가하세요.

• 뮤텍스 잠금
• 을 사용했지만 이 솔루션의 처리량이 크게 떨어졌습니다.
더블 캐시
• . 캐시 A와 캐시 B라는 두 개의 캐시가 있습니다. 캐시 A의 만료 시간은 20분이고, 캐시 B의 만료 시간은 없습니다. 캐시 준비 작업을 직접 수행하십시오. 그런 다음 다음 사항을 분석합니다. 캐시 A에서 데이터베이스를 읽고, A에 데이터가 없으면 직접 반환하고, B에서 직접 데이터를 읽고, 직접 반환하고, 비동기적으로 업데이트 스레드를 시작하면 업데이트 스레드가 업데이트됩니다. 캐시 A와 캐시 B를 동시에 수행합니다.

Eight Redis의 동시 경쟁 키 문제를 해결하는 방법

이 문제는 대략적으로

여러 하위 시스템이 동시에 키를 설정합니다. 이때 우리가 주의해야 할 점은 무엇입니까?

모든 사람은 기본적으로 Redis 트랜잭션 메커니즘 사용을 권장합니다.

그러나 Redis 트랜잭션 메커니즘을 사용하는 것은 권장되지 않습니다. 우리 프로덕션 환경은 기본적으로 Redis 클러스터 환경이고, 데이터 샤딩 작업이 수행되기 때문입니다. 트랜잭션에 여러 키 작업이 포함된 경우 이러한 여러 키가 반드시 동일한 redis 서버에 저장될 필요는 없습니다. 따라서 Redis의 트랜잭션 메커니즘은 매우 쓸모가 없습니다.

이 열쇠를 조작하시면

순서가 필요없습니다 이 경우에는

분산 자물쇠

를 준비하시면 누구나 자물쇠를 잡을 수 있고, 자물쇠를 잡은 후 그냥 설정작업을 하시면 됩니다. 비교적 간단합니다.

이 키를 조작하는 경우

순서가 필요합니다 key1이 있고 시스템 A는 key1을 valueA로 설정해야 하고 시스템 B는 key1을 valueB로 설정해야 하며 시스템 C는 key1을 valueB로 설정해야 한다고 가정합니다. key1을 valueC로 변경합니다.

key1의 값이 valueA > valueB > valueC의 순서로 변경될 것으로 예상합니다. 이때

데이터를 데이터베이스에 쓸 때

타임스탬프를 저장해야 합니다.

타임스탬프가 다음과 같다고 가정합니다

: System A key 1 {valueA 3:00}

System B key 1 {valueB 3:05}

System C key 1 {valueC 3:10}

그러므로 시스템 B가 먼저 잠금을 잡고 key1을 {valueB 3:05}로 설정한다고 가정합니다. 다음으로 시스템 A는 잠금을 획득하고 자신의 값 A의 타임스탬프가 캐시의 타임스탬프보다 이전임을 확인하므로 설정 작업을 수행하지 않습니다. 큐를 사용하여 설정 방법을 직렬 액세스로 전환하는 등의 다른 방법도 사용할 수 있습니다.

더 많은 Redis 관련 기술 기사를 보려면

Redis Tutorial

칼럼을 방문하여 알아보세요!

위 내용은 Redis를 배포하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!