Redis 메시지 큐가 데이터 손실을 방지하는 방법

Redis는 두 가지 형식으로 메시지 대기열을 구현합니다.

Broadcast 구독 모드: Redis의 Pub/Sub 메커니즘을 기반으로 클라이언트가 특정 키에 메시지를 게시하면 모든 구독 클라이언트가 이벤트를 트리거합니다. 클러스터 구독 모드 : Redis List 양방향 + 원자성 + BRPOP 기반(권장 학습: Redis 비디오 튜토리얼)

Redis 메시지 큐, Redis가 다운되면 메시지가 손실될 수 있습니다(지속성 전략에 따라 다름). 메시지 수신자에게 재전송 및 확인 메커니즘이 없으면 Redis의 데이터가 손실됩니다. 그래서 Redis를 메시지 대기열로 사용하는 것은 일반적으로 메시지의 정확성이 특별히 높지 않은 시나리오입니다.

데이터의 최종 일관성을 절대적으로 보장하고 메시지가 100% 손실되지 않도록 보장할 수 있는 경우 다음이 필요합니다.

1.쓰기가 성공할 수 있도록 쓰기 시 트랜잭션 처리를 활성화합니다.

2.Redis는 모든 변경 사항이 실시간으로 유지되도록 구성됩니다. 예를 들어 저장소 끝이 디스크인 경우 각 변경 사항은 완료되기 전에 디스크에 동기적으로 기록됩니다. Redis는 이러한 구성을 지원하지만, 그렇게 하면 인메모리 데이터베이스 기능이 완전히 사라지고 성능이 매우 저하됩니다.

3.

소비자 측에서도 처리가 완료된 후 돌아와서 실제로 메시지를 삭제해야 합니다.

4.

잠금을 통해 여러 스레드 또는 여러 터미널의 동시 처리를 피할 수 있습니다.

3과 4의 요구 사항은 직접 구현해야 합니다. 다른 대기열을 사용하여 구현할 수도 있지만 더 좋은 방법은 대기열 내부에 카운터를 구현하는 것입니다. 해시 형식의 경우 필드를 추가하고 값을 추가하여 기준으로 삼습니다. 문자열 머리 부분에 값과 구분 기호를 추가하면 간단하지만 간단하게 카운터를 만들 수 있습니다. , 충분히 실용적입니다.

특정 시스템을 제외하면 일반적으로 이러한 강력한 일관성이 필요하지 않습니다. 구현하기는 어렵지 않지만 성능은 매우 낮습니다.

은행 결제 비즈니스는 엄격한 거래 일관성을 요구하는 반면, 인터넷 비즈니스는 일반적으로 높은 성능을 대가로 매우 짧은 시간에 소량의 데이터 손실을 허용하는 까다로운 접근 방식을 사용합니다.

예를 들어 위의 redis 처리는 1000개의 데이터가 변경될 때 실제로 디스크에 쓰도록 변경될 수 있습니다. 갑작스러운 정전 등 극단적인 경우에는 1,000개의 데이터가 손실될 위험이 있습니다. 물론 이런 일이 발생할 확률도 매우 낮으므로(Lanxiang 굴삭기에서 멀리 떨어져 계십니까?) 대부분의 시나리오에서 허용됩니다.

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

Redis 시작 튜토리얼 칼럼을 방문하여 알아보세요!

위 내용은 Redis 메시지 큐가 데이터 손실을 방지하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!