Redis

개요

대충 레디스 캐시 관련하여 많이들 이야기를 들었을 것이다.

하지만 막상 레디스 관련 명확하게 정리된 서적이나 글이 많지 않고, (내용이 많지 않아서 일까?)

유용한 정보들은 유투브에 관련 내용이 많은 것을 보았다.

따라서 오늘 내용은 레디스 지식을 간단히 글로 정리해보려고 한다.

 

Redis

Remote dictionary server

DB의 역할도 하고(No sql DB), 캐시의 역할도 하고, 메세지 브로커의 역할도 한다(!)

메세지 브로커가 생소할 수 있지만, 흔히 알고 계시는 Rabit MQ, Kafka 같은 친구들과 묶인다고 생각하면 된다.

왜 Redis를 사용할까?

인메모리 기준으로 정보를 가져오는 경우 쓸 수 있다.

컴터의 Main memory는 휘발성인데, 레디스는 여기에 저장하는 개념이다.

그러면 다른 인메모리 저장 엔진도있는데 redis를 사용하는 이유는 무엇일까?

비교가 많이 되는 엔진은 Mem cached 가 있는데, 이것은 레디스에 비하여 단순하다고 생각하면 된다.

보통 레디스를 많이 사용하는 이유는 Redis에서 제공하는 라이브러리의 수가 많기 때문이다.

우리가 흔히 개발에서 사용하는 Collection (소팅이나 집계 등)의 기능을 제공한다.

• 자료구조가 Atomic 하다. 동시성 문제를 피할 수 있다 (그래도 문제는 염두에 두자.)
• 여러대의 서버에서 데이터를 아토믹하게 공유할 때 사용한다.
  
  • 한대의 서버에서만 쓰더라도 전역변수를 쓰는것보다 싱글 쓰레드라 Race condition문제를 막을 수 있다.
    • Race condition 이란 ? 여러 개의 쓰레드가 경합되어서 Context Switcing에 따라 원치 않는 결과가 발생하는 경우를 말한다. 

 

Redis의 Collection 기능

Key value 형태의 자료 저장

List는 종단간 데이터를 삽입 할 경우는 괜찮지만 (링크드 리스트를 생각해보자) 중간에 데이터를 넣는 경우는 비효율적이다. 

 

그렇다고 무조건 레디스를 선택해야하는가에 대하여서는

다음의 주의사항이 있다.

우선 앞서 설명했듯 레디스는 싱글스레드 방식이기 때문에(이것의 장점도 있었지만,,), 1번에 1개의 명령어만 수행이 가능하다. 그래서 명령어를 쓸때, O(N) 이 소요되는 명령어 Keys(모든 키 완전 탐색), flushall (데이터 모두 삭제) 등은 매우 느리다. 이때는 memchached를 사용하는것이 더 나을 수 있다.

그리고 이러한 문제 때문에,스냅샷을 생성하는 경우 자식 프로세스를 복사해서 사용한다. 따라서 실제 필요한 메모리 양 보다 더 많은 메모리를 사용하며, 메모리 파편화로 인해 더욱 메모리를 많이 사용하게 된다. 

 

그렇지만....

실제 memcached나 redis의 성능 차이가 크지 않다. 따라서 두개 다 사용하는것보다는 redis로 통일하여 사용하는것이 나을 수 있다. 저장할 데이터 (메모리)가 날라가서 서비스 장애가 발생하는 경우는 Redis 를 사용하는것이 더 나을 수 있다.