Redis(1)--redis 소개

레디스란 무엇인가요?

Redis는 현재 여러 데이터 구조를 포함하고 높은 동시성과 강력한 요청 압력 하에서 관계형 데이터베이스를 지원하는 데 사용되는 가장 인기 있는 오픈 소스 캐시 데이터베이스입니다.
Redis는 일반적으로 사용되는 관계형 데이터베이스와 완전히 다릅니다.

1. 관계형 데이터베이스(Mysql, Oracle 등)의 저장공간은 서버의 하드디스크인 반면, Redis는 서버의 메모리를 사용한다는 점에서 Redis의 장점과 단점도 발생합니다. (쿼리 속도는 빠르지만 저장 용량이 작음)
2. 또한, 데이터를 조회하는 방식도 달라 기존 관계형 데이터베이스는 sql 명령어를 통해 조회하는 반면, redis는 운영체제 명령줄을 통해 조회한다.
3. 관계형 데이터베이스는 테이블과 레코드 형식으로 데이터를 저장하지만 Redis에서는 모든 것이 데이터 구조에 데이터를 저장합니다.
4. 관계형 데이터베이스에는 외래 키, 기본 키와 같은 관련 필드가 있지만 Redis에는 존재하지 않습니다.

Redis 및 memcached와 같은 다른 캐시 데이터베이스도 다릅니다.

https://blog.csdn.net/weixin_42295141/article/details/81380633 의 텍스트는 여기에 인용되어 있습니다 . 형님 덕분에 "어쩔 수 없지만-"

1. 네트워크 IO 모델 측면에서: Memcached는 다중 스레드로 구성되어 수신 스레드와 작업자 스레드로 구분되며 잠금 도입으로 인해 성능이 저하됩니다. Redis는 단일 스레드 IO 다중화 모델을 사용하여 속도 이점을 극대화하고 더 간단한 컴퓨팅 기능도 제공합니다.
2. 메모리 관리 측면에서 Memcached는 미리 할당된 메모리 풀을 사용하는데, 이는 어느 정도 공간 낭비를 초래하며, 아직 메모리에 공간이 많이 남아 있으면 새로운 데이터도 제거될 수 있지만 Redis는 다음과 같은 방법을 사용합니다. 데이터를 저장하기 위해 현장에서 메모리를 적용하면 임시가 아닌 데이터는 제거되지 않습니다. Redis는 캐시보다 저장에 더 적합합니다.
3. 데이터 일관성 측면에서 Memcached는 이를 보장하기 위해 cas 명령을 제공하고 Redis는 중간 작업에 의해 중단되지 않고 일련의 명령의 원자성을 보장할 수 있는 트랜잭션 기능을 제공합니다.
4. 저장 방식 측면에서: Memcached는 단순 키-값 저장만 지원하고 열거를 지원하지 않으며 지속성, 복제 등의 기능을 지원하지 않습니다.

Redis의 장점?

1. Redis는 메모리를 기반으로 실행되며 I/O 읽기 및 쓰기 속도가 빠릅니다. Redis는 초당 100,000개 이상의 읽기 및 쓰기 빈도를 지원할 수 있습니다.
2. 분산형, 이론적으로 무제한 확장 지원
3. 풍부한 데이터 유형(문자열, 비트맵, 해시, 목록, 집합 및 zset)
4. 지원 트랜잭션, 작업은 원자적입니다.
5. 지구화

Redis의 단점?

1. 서버가 충돌하면 redis 실행이 중지되고 여기에 저장된 데이터가 손실될 수 있습니다. (끈질김 없이)
2. 메모리 제한으로 인해 Redis는 대용량 데이터의 저장 매체로 사용할 수 없습니다.
3. Redis 마스터-슬레이브 복제 성능 문제 마스터-슬레이브 복제 속도와 연결 안정성을 위해서는 슬레이브와 마스터가 동일한 LAN에 있는 것이 가장 좋습니다.

Redis는 무엇을 위한 것인가요?

1. seckill 시스템의 요청 처리와 같이 동시 요청 차단 처리가 높습니다.
2. 세트 데이터 유형의 SRANDMEMBER 함수와 같은 데이터 처리 및 장면 애플리케이션은 세트에서 하나 이상의 키(예: 사용자 ID)를 무작위로 획득하여 복권 활동에 사용할 수 있습니다. set 데이터 유형의 SINTERCARD 함수는 공개 친구 또는 공통 즐겨찾기 항목 등을 처리하는 데 사용되는 두 세트의 교집합을 얻을 수 있습니다. 또 다른 예는 해시 데이터 유형을 사용하여 장바구니의 데이터를 저장하고 처리할 수 있다는 것입니다.

Redis의 기본 용어:

1. 마스터(host)/슬레이브(slave)
   a) 호스트 : 데이터 복제의 대상이 되는 서버인 마스터 서버
   b) 슬레이브 : 슬레이브 서버, 즉 데이터 복제의 대상이 되는 서버
2. 보초
3. 클러스터: 여러 개의 서버로 구성된 서버 그룹으로, 그 중 일반 선거(호스트 선택)를 위해서는 최소 3대의 서버가 필요합니다. 그리고 마스터-슬레이브 서버 클러스터를 구축하려면 최소 3개의 호스트와 3개의 슬레이브가 필요합니다.
4. 심장 박동 감지
5. 캐시 고장, 캐시 사태, 캐시 침투
   a) 캐시 고장: Redis에 만료되거나 삭제된 핫스팟 데이터가 있지만 현재 전송된 데이터와 관련된 요청이 많은 경우 높은 동시성 상황에서 자주 발생합니다. 시간이 지나면 Redis는 요청을 가로채는 역할을 할 수 없으며 많은 수의 요청이 데이터베이스에 직접 도달하게 되어 캐시가 손상되거나 심지어 데이터베이스 충돌이 발생할 수 있습니다. 해결 방법: setnx(존재하지 않는 경우 설정)를 사용하여 뮤텍스를 설정합니다(자세한 내용은 후속 기사에서 설명).
   b) 캐시 사태: 대량의 핫 데이터가 특정 순간에 만료되거나 삭제되면 여기에 많은 수의 요청이 도착합니다. 시간 데이터베이스는 데이터베이스에 많은 부담을 줍니다. 해결책: 캐시 무효화 시간이 분산되거나 데이터베이스 액세스가 잠기고 메시지 큐가 사용됩니다.
   c) 캐시 침투: 쿼리한 데이터(키)가 Redis에서 발견되지 않으면 요청이 데이터베이스에 직접 액세스하게 되며, 이때 Redis 캐시는 쓸모가 없으므로 데이터베이스에 일정한 압력을 가하게 됩니다. 해결책은 Bloom 필터를 사용하여 요청된 데이터가 존재하는지 확인하는 것입니다. (다음 기사에서 자세히 설명하겠습니다)

Redis의 기본은 무엇입니까?

1. 센티널 메커니즘
   센티널(Sentinel): 모니터라고도 하며 센티널(sentinel), 마스터(host), 슬레이브(slave)의 상태를 모니터링하는데 사용된다.
   모니터링하는 방법?
   1) 센티널(sentinel)은 일정한 간격으로 다른 센티널(sentinels), 마스터(host), 슬레이브(slave)에게 메시지(ping 명령)를 보내고 상대방 인스턴스의 응답을 기다린다. 2) 현재 시간이 상대방 서버가 마지막 유효한 응답
   퐁과 멀리 떨어져 있는 경우 명령 시간 차이가 down-after-milliseconds 옵션에 지정된 값을 초과하는 경우 해당 서버는 주관적 다운(SDOWN – 주관적 다운)으로 표시됩니다.
   3) 마스터(호스트)가 주관적으로 오프라인으로 표시되면 서버를 모니터링하는 모든 Sentinel은 서버가 실제로 주관적인 오프라인 상태(SDOWN – 주관적인 다운)에 진입했는지 여부를 1초에 한 번씩 확인해야 합니다.
   4) 충분한 수의 센티넬(Sentinel)이 호스트가 주관적인 오프라인 상태(SDOWN – 주관적인 다운)에 있음을 발견한 경우. 그런 다음 마스터(호스트)를 목표 다운(ODOWN - 목표 다운)으로 표시합니다.
   5) 호스트가 주관적 오프라인 상태(SDOWN - 목표 다운)에 있음을 확인할 수 있는 센티넬(센티넬)이 충분하지 않거나 서버가 유효한 pong 응답이 발생하고 서버의 SDOWN 상태가 제거됩니다.
   구체적인 내용은 추후 업데이트될 예정이니 많은 관심 부탁드립니다.
2. 마스터-슬레이브 복제(동기화)의 원리
   마스터에서 슬레이브로 데이터를 백업하는 과정
   구체적인 내용은 추후 업데이트될 예정이니 지켜봐주세요
3. Redis 지속성 원칙
   Redis 지속성은 Redis에 데이터를 정기적으로 파일 형식으로 저장하는 것이므로 어머니는 서버가 다운될 때 Redis 데이터 손실에 대해 걱정할 필요가 없습니다. 특정 지속성 방법에는 RDB와 AOF라는 두 가지가 있습니다.
   구체적인 내용은 추후 업데이트될 예정이니 많은 관심 부탁드립니다.

더 많은 링크

Redis 설치 https://blog.csdn.net/qq_31236027/article/details/121879741
Redis 데이터 구조 소개 https://blog.csdn.net/qq_31236027/article/details/121894713