적당한 박스가 생겨서 보드게임 "팬데믹: 더 큐어" 를 이사 시켰습니다.

바로 요 놈 인데요

열어볼까요~ 주사위 주머니가 보이네요

주사위 주머니를 치우면~ 주사위들을 넣어 둔 Angry Birds 틴케이스가 보입니다

아래로는 나머지 컴포넌트들이 살짝 보이네요

다 꺼내봤습니다.

"팬데믹: 더 큐어" 참 재밌는 게임인데 스플렌더 만큼이나 과대포장 이다보니 이렇게 턱박스를 만들어 가지고 다니네요 ^^

옮길 때 svn 저장소 위치를 file:// 를 이용해 표시하면 fs format 관련 에러가 발생할 수가 있다. 따라서 svn:// 를 이용해야 하는데, 만약 svn 서버를 로컬 PC 윈도우즈에 설치한 경우 해결 방법

1. SVN 저장소를 준비/확인 한다. 예를 들어 다음과 같다고 치자

  - repos 루트 경로 : d:\repos

  - 저장소1 경로 : d:\repos\gamesvr

  - 저장소2 경로 : d:\repos\someproject 

2. tortoisesvn 를 설치한 다음 cmd 창에서 다음과 같이 실행해 SVN 저장소를 svn:// 프로토콜로 읽을 수 있게 해준다. 

  svnserve -d -R --root d:\repos

위와 같이 실행하면, local pc 에서 다음과 같은 식으로 접근이 가능해진다.

 svn://localhost/gamesvr

 svn://localhost/someproject

3. Git Bash 실행 후 

 git svn clone 등 으로 저장소를 옮기는데 이 때 svn:// 를 이용한다.

ex) git svn clone svn://localhost/gamesvr -s ./gamesvr

별 수 없이, 해결을 위해 일단 Z-MAN Games 홈페이지에 접속 했습니다. 다행히 CONTACT US 라는 메뉴를 클릭하니 바로 AS 요청을 할 수 있는 페이지가 열리더군요. 아래 링크 클릭하시면 바로 이동 합니다.

뜯어보면, 지퍼백과 튼튼한 프로텍터에 쌓인 카드 한 장이 보입니다.

 도움 되시는 분이 계시면 좋겠네요. 읽어주셔서 감사합니다. ^^

저렴하고 쓸만한 카드 홀더를 구하기 위해 여기 저기 뒤져보다가, 좋은 정보를 발견했습니다.

정보 원문의 링크 입니다. "5분 이면 충분해요! 카드 목재 홀더 만들기" 

그래서 나도 직접 만들어 보기로 결정!!

일단 목재를 구해야 했는데, 직접 화방이나 큰 서점 뒤지고 다니기 귀찮아서, 그냥 에스엔티핸즈 에서 주문해버렸습니다. 쏘쿨~

- 정사각형 각재 15mm x 15mm 1개 3,200 원

- 직사각형 각재 15mm x 20mm 1개 3,750 원

- L자형 각재 7mm x 15mm 3개 6,900 원

- 배송비 4,000 원

배송비가 좀 비싸군요 ㅜㅜ

각재는 모두 길이 90cm 짜리구요. 각재들 구성이 좀 특이하게 보이실 수 있는데, 시험삼아 3가지 종류로 총 4개를 만들 계획이었거든요. 다음과 같이요~

- 30cm 길이 3단 2개 (3단은 카드를 3줄로 꽂을 수 있는 홀더 입니다)

- 30cm 길이 2단 1개

- 30cm 길이 1단 1개

우선 목공용 본드를 잘 발라서 붙여줍니다. 물론 모든 부분에 바르면 안 되고, 만들려고 하는 홀더 구성에 따라서 본드를 발라야 하는 구간들이 있습니다.

다음엔 본드를 말립니다. 클램프 가진게 있어서 적당한 힘으로 고정 시키고, 다른 부분들은 고무밴드로 묶어 줍니다. 급할 건 없어서 그냥 하루 동안 말렸습니다.

이제 잘 잘라 줍니다. 톱 으로 똑바로 자를 자신이 없는 관계로 가이드를 이용했습니다.

사포질로 마무리 하고 완성~

세로 방향으로도 한 장 찍어보고

여자친구와 카페에서 데이트 하면서 이용해 보았습니다.

와이어트어프, 여자친구의 자비심 없는 "하이드 아웃" 러쉬에 10,000$ 이상의 큰 차이로 졌습니다 ㅠㅠ

레이스 포 더 갤럭시, 훗 희귀 원소 생산-소비 위주로 달린 제가 이겼습니다. ^^V

감상 입니다.

- 30cm 길이가 휴대성은 좋은데 카드가 몇 장 안 올라가더군요. 팬데믹 카드 같은 경우 겹치지 않고는 카드 4장 밖에 못 올립니다. 휴대 목적이 아닌 경우는 45cm 로 만들어야 겠네요.

- 2단이나 3단 같은 경우 뒷 줄의 카드가 잘 보이지 않는 이슈가 있어서, 카드 제목만 보여도 되는 경우 아니면 그냥 1단 여러개가 더 사용하기 좋을거 같습니다.

Summary

• 이 문서는 predis 를 사용 복수개의 명령을 순차적으로 실행하는 경우와 Class Predis\Pipeline\PipelineContext 를 이용한 경우의 실행 속도에 대한 비교 테스트 이다.
• 접속은 "단일 redis 서버 접속" 인 경우와 "3대의 redis 서버로 이루어진 cluster" 에 접속한 경우를 각각 측정
• 테스트 항목은 접속 방법 별로 아래 3가지를 각각 5회씩 수행.
  • 단일 key 업데이트 테스트 : 단일 key 에 대하여 10000회의 incrby 실행
  • 복수 key 에 set 테스트 : 10000개의 새로운 key 에 set 하기
  • 복수 key 업데이트 테스트 : 3개의 key 의 값들을 구한후 변경하여 다시 set 하기 를 10000회 반복
• 각 테스트 시작 전에는 flushdb 를 실행하여 db 를 비웠다.
• 시간 측정은 php 의 microtime() 를 사용하였고 redis 서버 접속 직후 부터 시간을 측정했다.

pipeline 프로세스

• predis 에서 지원하는 pipeline 은 다음과 같이 구현된다.
  1. 클러스터를 이루는 redis 서버들 중에서 해당하는 key 들에 필요한 서버들에 모두 접속을 한다.( class Predis\Network\ConnectionBase 의 함수인 tcpStreamInitializer() 에서 실제 접속 처리를 한다. )
  2. 모든 명령들을 php 의 배열 변수에 저장한다. ( class Predis\Pipeline\PipelineContext 의 멤버변수인 $pipeline 에 저장됨)
  3. class Predis\Pipeline\PipelineContext 의 함수 flushPipeline 에 의해 redis 명령 실행기에 클러스터 접속 정보와 배열 $pipeline 을 전달한다.
  4. 여기서 명령 실행기는 class Predis\Pipeline\StandardExecutor 의 객체가 된다. 이 객체의 함수 execute 에 의해 배열의 명령들이 실행되게 된다.
• 위에서 살펴본 실행 구조상, 배열에 있는 명령들 실행중에 웹서버가 죽게되면 그 전까지의 명령들만 실행이 되고, 나머지 명령들은 실행이 되지 않게 된다.

단일 key 업데이트 테스트

• 소스

// pipeline 사용
$pipe = $m->predis->pipeline();
for($i=0;$i<10000;$i++) {
	$pipe->incrby('counter', 10);
}
$pipe->execute();


// 순차적 실행
for($i=0;$i<10000;$i++) {
	$m->predis->incrby('counter', 10);
}

• 결과(seconds)

복수 key 에 set 테스트

• 소스

// pipeline 사용
$pipe = $m->predis->pipeline();
for($i=0;$i<10000;$i++) {
	$pipe->set("testkey:" . $i, $i);
}
$pipe->execute();


// 순차적 실행
for($i=0;$i<10000;$i++) {
	$m->predis->set("testkey:" . $i, $i);
}

• 결과(seconds)

복수 key 업데이트 테스트

• 소스

// pipeline 사용
$m->predis->set("testkey:0", 10);
$m->predis->set("testkey:1", 10);
$m->predis->set("testkey:2", 10);
for($i=0;$i<10000;$i++) {
	
	$pipe = $m->predis->pipeline();
	
	$pipe->get("testkey:0");
	$pipe->get("testkey:1");
	$pipe->get("testkey:2");
	$replies = $pipe->execute();
		
	$testkey0 = $replies[0] + 5;
	$testkey1 = $replies[1] + 5;
	$testkey2 = $replies[2] + 5;
	
	$pipe->set("testkey:0", $testkey0);
	$pipe->set("testkey:1", $testkey1);
	$pipe->set("testkey:2", $testkey2);
	$pipe->execute();
}

// 순차적 실행
$m->predis->set("testkey:0", 10);
$m->predis->set("testkey:1", 10);
$m->predis->set("testkey:2", 10);
for($i=0;$i<10000;$i++) {

	$testkey0 = $m->predis->get("testkey:0");
	$testkey1 = $m->predis->get("testkey:1");
	$testkey2 = $m->predis->get("testkey:2");

	$testkey0 += 5;
	$testkey1 += 5;
	$testkey2 += 5;

	$m->predis->set("testkey:0", $testkey0);
	$m->predis->set("testkey:1", $testkey1);
	$m->predis->set("testkey:2", $testkey2);
}

• 결과(seconds)

정리

• predis 에서 제공하는 pipeline 은 다음과 같이 이루어진다.
  1. php 단에서 배열변수에 redis 명령들을 저장한다.
  2. redis 명령들의 저장이 끝나면, 소켓을 통해 명령을 순서대로 서버에 보내 실행한다.
  3. redis 명령들의 실행이 끝나면, 소켓을 통해 결과를 순서대로 읽어온다.
  • 즉, 명령이 모이는 곳은 웹서버(PHP) 단 이므로 배열에 저장된 명령들이 실행되는 중간에 웹서버가 crash 되버리거나 웹서버와 redis 서버와의 접속이 끊어지면 아직 실행되지 않은 명령들은 유실되어 버린다.
• 복수개의 redis 명령들을 pipeline 을 사용하여 실행하는 방법의 장단점은 (절차적으로 실행하는 경우에 비교할 때) 다음과 같다.
  • 장점 : 명령실행 속도가 조금이라도 빠르며, 특히 명령이 아주 많은 경우는 압도적으로 빨라진다. 이에 서비스 용으로 보다는 DB 관리등의 목적으로 쓰는것이 더 유용하다.
  • 단점 : 결과를 나중에 한꺼번에 받아오기 때문에 중간에 실행된 redis 명령의 결과를 이용하여 redis 명령을 실행하는 것은 불가능하다. 명령의 결과를 이용하기 위해서는 일단 pipeline 의 버퍼에 쌓인 명령들을 다 처리한 후 다시 pipeline 을 사용하던가 해야 한다.
• 약간 억지로 효율 계산
  • 홍콩 웹서버 5대에서 12/Jun/2012 하루 처리한 명령의 수가 대략 1,570,000 건
  • redis 멀티서버 접속으로 "복수 key 업데이트 테스트" 의 효율을 적용하면 API 명령 10,000 건당 10초의 시간을 아낄수 있음
  • API명령 10,000 건 : 10 sec = 1,570,000 : ? 하면 대충 1,570 sec 즉 26분 정도의 시간이 나옴
  • 파이프라인 사용시 (절자척 명령 실행에 비해) 일일 웹서버들 의 시간을 26분 정도 벌어줄수 있다는 계산이 나옴(조금 애매한 수치)

• 이 문서의 목적은 아파치 및 이클립스 등 에서 사용자 정의 확장자를 추가하는 방법을 다룬다.
• 아래 내용들은 모두 PHP 의 확장자로 .kp 를 추가로 등록하는 방법을 설명한다.

Apache Server 에서 추가하기

1. httpd.conf 파일을 vi 등의 에디터로 열어준다.
2. "AddType application/x-httpd-php .php" 라는 줄 밑에 "AddType application/x-httpd-php .kp" 를 추가해준다. (설마 큰따옴표 까지 넣는 사람은 없겠지?)
3. 아파치 서버를 재 시작 시켜주면 적용된다.

Eclipse 에서 추가하기

1. 메뉴중 Window -> Preferences 로 들어간다.
2. 좌측 트리에서 General -> Content Types 를 선택한다.
3. 우측 트리에서 Text -> PHP Content Type 를 선택한다.
4. "Add..." 버튼을 클릭한다.
5. "Add Content Type Association" 창이 열리면 "Content type:" 란에 "*.kp" 를 입력하고 OK 버튼 클릭
6. Preferences 창에서 OK 버튼 눌러주면 끝

근데 B 열과 D 열이 왜 없냐구요? 게임 메뉴얼에 보면 B와 D는 발음이 비슷해서 뺐다고 나와있군요 ^^;

이제 주사위를 굴리던 가위바위보를 하던 나이로 따지던 먼저 시작할 사람을 정합니다.(원래는 주사위였던가?)

본격 적인 던전 약탈 아니 탐험을 나서기 전에 우선 탐험 용지에 표기 하는 방법을 알아 봅시다. 기본적으로 가본 장소는 O 를 벽으로 막힌 곳은 X 를 표기 합니다. 게임을 처음 시작한 직후 라면 스타트 지점인 던전 1층 입구에만 O 가 그려져 있겠지요.

자 당신의 턴이 되었나요? 그럼 이제 상대방의 던전을 탐험 합니다. 물론 어디가 막혀있고 어디에 몬스터가 숨어있는지 보물상자와 공주의 위치등은 전혀 모르는 상태 입니다.

이동 방법은 간단 합니다. 탐험 용지에 쳐져 있는 O 들 중 아무 곳 이나 하나 를 골라 상하좌우 인접한 곳(대각선 방향은 안됩니다)들 중 아직 가보지 않은 좌표로 이동 하겠다고 상대방에게 알려주면 됩니다.
즉, S가 시작 지점이라고 할 때 현재 탐험 용지에 다음과 같이 그려져 있다면

이번 프로젝트에 REDIS 를 쓰기로 해서 어떤 놈인지 몇일 붙잡고 연구한 결과를 wiki 에 정리해보았다.

아래 내용은 단순 번역 뿐 아니라 직접 연구 및 파악한 내용으로 경우에 따라 잘못된 내용이 있을 수도 있다.(무책임;)

참고사이트 http://redis.io/

연구에 사용한 Redis버전 : 2.4.12

REDIS 소개

• memory db
• no-sql db 로 기본적으로 key 와 value 쌍의 형태로 데이타를 메모리에 저장한다.
• 메모리에 저장된 내용을 지속시키기 위해 파일로 싱크 하는 기능을 제공한다.

Data Types

• redis 에는 5가지 데이타형이 존재하며, 이 5가지 데이타 형을 다루는 명령이 모두 다르다. 예를들어 string 형의 데이타를 저장하는 명령으로 저장한 key 는 hashes 형을 읽는 명령으로 읽을 수 없다.

Strings

• redis 의 가장 기본적인 데이타형 으로 key 에 하나의 값을 저장한다.
• string 이라고 해서 문자열만 저장할 수 있는게 아니라, 이진 데이타도 저장이 가능하다.(참고로 redis 에는 정수형, 실수형 이 따로 없다.)
• 한 key 에 넣을 수 있는 데이타의 최대 크기는 512 megabytes 이다.
• 이 데이타형의 값은 정수인 경우는 int 로 아니면 raw 로 encoding 된다.

Lists

• 배열이라 보면 된다.
• 한 key 에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다. (2^32 - 1)
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 linkedlist 아니면 ziplist 로 encoding 된다.

Sets

• 정렬되지 않은 집합 형 이다.
• 말 그대로 집합 이기 때문에 한 key 에 중복된 데이타는 존재하지 않는다. 즉, 동일한 key 에 "abcd" 라는 값을 두 번 추가해도 sets 상에 "abcd" 라는 값은 하나만 존재하게 된다.
• 이 데이타형의 중요한 장점은 요소의 추가, 제거 및 존재체크 시 소모되는 시간이, sets 에 포함된 요소의 수에 관계없이 일정하다는 것이다.
• 한 key 에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다. (2^32 - 1)
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 intset 로 encoding 된다.

Hashes

• 암호화에서 설명한 그 hash 와는 전혀 상관 없다.
• 객체를 나타내는데 사용 가능한 데이타 형이다.
• 형태는 lists 와 비슷한데 "필드명", "필드값" 의 연속으로 이루어져 있다.
• redis 에서는 최대 100개 정도의 필드를 가지고 있는 hashes 형의 데이타를 저장할 때 매주 작은 메모리 공간을 사용하는 방법을 사용하고 있다.
  • 이 얘기는 메모리 상에 서로 다른 hash key 들이 동일한 필드명 을 공유하는 방법을 사용한다는 것일까?
• 한 key 에 포함할 수 있는 field-value 쌍의 최대 개수는 4,294,967,295 개이다. (2^32 - 1)
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 zipmap 로 encoding 된다.

Sorted sets

• 일단 형태로만 보면 sets 의 각요소마다 score 라는 실수 값을 가지고 있는 형태이다.
• 요소들은 정렬된 형태로 보여지는데 이때 정렬하는 기준이 score 이다. (오름차순)
• sets 와 마찬가지로 동일한 key 에서 각 요소들의 값은 유일하다. 하지만, score 값은 중복될 수 있다.
• 요소의 추가, 제거, 업데이트는 매우 빠른 방법으로 진행되는데 이는 "요소의 개수의 로그" 에 비례하는 시간이 사용된다. 이런 특징으로 이 데이타 형은 다음과 같은 활용에 유용하다.
  • score 에 승수 를 넣는다던지 해서 랭킹 시스템 등에 사용하기 좋다.
  • 다른 데이타 형의 정렬을 위한 index 값으로 활용할 수 있다. 예를 들어 hashes 로 사용자 데이타를 저장하는데 나이에 따른 정렬이 필요하다 할 경우, sorted sets 에 요소의 값은 사용자ID 를 score 는 나이 값을 넣어주면 된다.
• sorted sets 는 가장 진보한 redis 데이타 형이라고 한다.
• 이 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 skiplist 아니면 ziplist 로 encoding 된다.

Expires

• redis 의 각 key 에는 만기시각을 설정해줄 수 있다. 이는 redis 명령 중 expire 명령으로 설정해줄 수 있다.
• 만기시각이 지난 key 는 자동적으로 메모리에서 제거된다.
• 메모리가 full 된 상태에서 LIMITS 설정에서 선택한 정책에 따라 만기시각이 지정되지 않거나 만기시각이 남은 key 라도 삭제될 경우가 있다.

Persistence (지속성)

• redis 는 메모리 기반 DB 이기 때문에 전원이 꺼지면 데이타가 모두 날라가게 된다. 이에 파일에 메모리상의 데이타를 저장해두고 redis 서버 실행시 다시 그 파일에서 데이타를 읽어와 메모리상에 올리는 기능을 제공하는데 이를 Persistence (지속성) 라고 한다.
• redis 는 RDB 와 AOF 의 두가지 지속성을 제공한다.
  • 두 가지 지속성은 하나만 선택해야 하는 것은 아니고 두 가지를 모두 사용 가능하다.
  • 두 가지 지속성을 모두 사용하도록 설정한 상태에서 redis-server 를 실행하면 AOF 를 이용해 메모리에 데이타를 올리게 된다.
  • 보통 두 가지 지속성을 다 쓰는게 좋다고 한다. 복구가 필요한 시점에 더 적합하고 안전한 방법을 선택해 복구 하면 될 듯 하다.

RDB

• 메모리상의 데이타를 모조리 파일로 덤프를 뜨게 된다.
• command 중 bgsave(비동기적) or save(동기적) 를 실행하면 이 지속성으로 파일을 쓰게할수 있다.
• 설정파일에서 SNAPSHOTTING 부분이 이 지속성과 관련된 부분이다.
• 저장 파일은 보통 .rdb 를 확장자로 쓴다.
• 프로세스
  1. redis 는 fork 로 자식 프로세스를 생성한다.
  2. 자식 프로세스는 임시 rdb 파일에 data 를 쓴다.
  3. 자식 프로세스가 임시 rdb 파일에 data 쓰기를 마치면, 임시 rdb 파일로 옛날 rdb 파일을 덮어 씌운다.
• 장점
  • 특정 시점의 백업 및 복구에 유리하다.
  • redis-server 디스크에 저장하는 시점까지 disk i/o 가 일어나지 않으므로 성능을 극대화 할수 있다.
  • AOF 에 비해 더 빨리 메모리 에 data 를 올리고 redis-server 를 시작 할수 있다.
• 단점
  • 사고 발생시 백업이 일어나는 시점들 사이에 일어나는 변경사항이 손실된다.
  • 백업시 fork() 로 자식 프로세스를 생성해서 백업 작업을 시행하는데 이때 데이타가 크다면 순간적으로 많은 cpu 부하가 발생할 수 있다.

AOF

• 실행한 명령들을 계속 파일에 추가해나가는 방식. mysql 의 바이너리로그 와 비슷하다고 볼 수 있다.
• command 중 BGREWRITEAOF 을 실행하면 이 지속성으로 파일을 쓰게할 수 있다.
• 설정파일에서 APPEND ONLY MODE 부분이 이 지속성과 관련된 부분이다.
• 저장 파일은 보통 .aof 를 확장자로 쓴다.
• AOF 는 설정파일에서 파일을 쓰는 시점에 대해 3가지 옵션을 제공하는데 보통 기본값인 everysec 를 사용하면 된다.(자세한 것은 설정파일의 appendfsync 부분 참고)
• Log rewriting
  • 쓰기 내용이 많아져서 불필요할정도로 aof 파일이 커진 경우 BGREWRITEOF 명령의 실행에 의해 데이타 내용을 살릴수 있는 짧은 명령을 쓰게 된다.
  • redis 2.2 버전에선 수동으로 BGREWRITEAOF 명령을 실행해야했지만, 2.4 버전 부터는 자동으로 실행된다고 한다. * 자세한내용은 설정파일을 확인하도록
• AOF 손상 확인 방법 : aof 파일을 쓰는 중 정전등의 문제로 파일이 손상될 수 있다. 이 때 redis-check-aof 툴로 복구가 가능하다.
  1. aof 파일을 복사한다.
  2. redis-check-aof --fix <aof복사본파일> 을 실행해 복사본 파일을 수정(복구)한다.
  3. (옵션사항)diff -u 명령으로 두 파일을 비교한다.
  4. 수정된 파일을 이용해 redis-server 를 다시 시작한다.
• 장점
  • 사고 발생시 손실되는 데이타가 최소화된다.
  • 정전등의 문제로 aof 파일에 문제가 생긴다 해도 redis-check-aof 로 aof 파일의 복구가 가능하다.
  • aof 파일은 포맷이 단순하여, 문제가 있는 쿼리만 삭제하고 복구에 사용한다던가 하는 작업이 가능하다.
• 단점
  • rdb 파일에 비해 보통 사이즈가 커지게 된다.
  • AOF 는 fsync 정책에 따라 RDB 보다 느릴수 있다.(아무래도 RDB 보다 쓰기가 많이 일어나게 되므로)
  • "과거에 우리(redis 개발진)는 aof 파일을 이용 동일한 data 로 복구하지 못하는 버그를 발견한적이 있는데, 아직 사용자들로부터 해당 버그가 발생한 경우를 보고 받은적은 없다." 라고 한다.

REDIS protocol specification

• redis 클라이언트와 서버간에 주고 받는 명령 및 응답의 규약 을 설명한다.
• 요청 프로토콜
  • AOF 파일의 포맷 역시 이 규약이 사용된다.
  • 간단하고, 컴퓨터에서 빠른 처리(파싱)이 가능하며, 사람이 충분히 이해할수 있는 쉬운 형태다
  • network layer 에서 client 에서 server 로 보내는 각 명령은 \r\n (CRLF) 로 끝나야 한다.
  • 형식 (아래서 < > 는 실제 입력하는게 아니라 키워드를 구분하기 위해 넣은 값임. 아래는 한 command 에 대한 포맷이다.

*<number of arguments><CR><LF>
$<number of bytes of argument 1><CR><LF>
<argument data><CR><LF>
$<number of bytes of argument 2><CR><LF>
<argument data><CR><LF>
...
$<number of bytes of argument N><CR><LF>
<argument data><CR><LF>
실제 형태는 아래와 같은 식이 된다.
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n

• 응답
  • 첫 문자 : 응답문은 5가지 형태가 있는데, 5가지 형태에 따라 첫 문자가 다음과 같이 결정된다.
    • "+" status reply (한줄로 끝나는 응답인 경우)
    • "-" error reply (에러 메시지인 경우)
    • ":" integer reply (하나의 정수로 답하는 경우)
    • "$" bulk reply 인 경우. 요청 프로토콜 참고
    • "*" 여러줄의 bulk reply 인 경우. 요청 프로토콜 참고

pipe 입력

• 텍스트 파일안의 명령들을 pipe 를 이용 redis-cli 에보내고 싶을때 방법. 주로 텍스트 파일 상의 대량의 명령들을 효율적으로 실행할 때 사용한다.
• 텍스트 파일은 다음 예제 샘플 처럼 명령들을 쭉 써주면 되는데 중요한건 줄바꿈이 \r\n 로 되야 한다는 것이다.

set key0 value0
set key1 value1
set key2 value2
set key3 value3
set key4 value4

• redis 2.6-rc4 와 redis 2.4.14 이상 일때 redis-cli 에서 자체적으로 pipe 입력 기능을 지원한다.
  • cat data.txt | redis-cli --pipe
• 버전이 낮은 경우는 아래와 같이 편법으로 가능하지만, 실패코드 등을 알수 없다는 단점이 있음.
  • (cat data.txt; sleep 10) | nc localhost 6379 > /dev/null

설정파일

기본 설정

• daemonize no
  • redis 서버를 데몬으로 실행하려면 daemonize yes 로 바꿔줘야 한다.

• pidfile /var/run/redis.pid
  • 이 설정파일을 이용해 띄운 redis 서버 의 pid(process id) 가 위 경로에 텍스트 파일 형태로 저장된다. 이를 이용
    • kill -9 `cat /var/run/redis.pid`
  • 같은 식으로도 redis server 를 강제 종료 시킬수 있다.(사고 상황 테스트 등)
  • redis 서버를 여러개 띄울 수 있으니 경로에서 redis.pid 란 파일 이름 부분을 적당히 수정해 주자.

• port 6379
  • redis-server 는 기본적으로 6379 포트를 쓰도록 되어 있다. 위 부분을 수정하면 다른 포트 번호로 실행할 수 있다.

• bind 127.0.0.1
  • 샘플상태에서 위 줄은 주석처리 되어 있을 것이다. 랜카드가 하나인 환경이라면 그냥 주석 상태로 두면 된다.
  • 랜카드가 2개 이상인 경우 어느 랜카드(ip)에서 서버가 대기할지 설정해주면 된다.

• timeout 0
  • 클라이언트에서 서버에 접속할 때 timeout 값으로 초 단위다. 일단 0 으로 놔두고 환경에 따라 값을 바꿔주면 될듯.

• loglevel verbose
  • 남기는 로그의 단계 설정
  • debug > verbose > notice > warning 순으로 더 많은 정보를 남긴다(debug 가 가장많은 정보 남김).
  • 기본값인 verbose 정도로 하는게 적당하다.

• logfile stdout
  • 로그파일의 위치를 나타냄.
  • 기본값인 stdout 로 할 경우 표준출력으로 로그를 남기기되는데 만약 이 설정에서 데몬 모드로 서버 실행시 /dev/null 로 출력되어 로그는 어디에도 안 남게된다.
  • stdout 를 적당한 파일 경로로 수정해서 로그가 파일에 남도록 하는게 좋다. 다만 이 설정만으로는 로그 파일을 일자별로 못 만들고 통짜 파일 하나로 만들어야 한다.
  • 로그 파일을 날자별로 만드는 간한단 아이디어 (문득 떠오른건데 잘 될지는 해봐야 한다.)
    1. 설정한 로그파일의 경로가 /data/logs/redis/redis.log 라고 할때
    2. /data/logs/redis/redis.log 를 실제 파일로 만드는 것이 아니라 날자가 붙은 로그파일 의 심볼릭링크로 만든다. (ex: ln -s /data/logs/redis/redis_20120515.log /data/logs/redis/redis.log)
    3. crontab 을 이용 매일 0 시에 redis.log 의 심볼릭 링크의 원본 파일을 해당 날자가 붙은 로그파일로 바꿔버린다. 이때 심볼릭 파일이 유실되는 순간을 위해 다음과 같은 식으로 처리한다.
       • ln -s /data/logs/redis/redis_20120516.log /data/logs/redis/redis_tmp.log
       • mv /data/logs/redis/redis_tmp.log /data/logs/redis/redis.log

• databases 16
  • redis 는 select 명령으로 DB 를 변경할 수 있는데 이때 DB 는 문자로 된 이름을 가지는게 아니라 0 부터 시작하는 index 값을 가지게 된다.
  • 이 DB 를 최대 몇 개 가질수 있는지 설정해주는 부분이다. 16 이라면 0 ~ 15 까지의 DB 를 가지게 된다.
  • 따로 select 명령을 사용하지 않을 경우 0 번 DB 가 선택되며 만약 7번 DB 를 선택하려면 다음과 같이 명령을 실행하면 된다.
    • select 7

SNAPSHOTTING (RDB 지속성 설정)

• save 60 10000
  • redis 서버가 메모리의 내용을 rdb 파일로 자동으로 덤프 하는 시점과 관련된 설정이다.
  • 위 줄은 60초 동안 10000 건 이상의 keys 가 변경되었다면 메모리 상의 데이타를 모두 rdb 파일로 덤프 하라는 뜻 이다.
  • save <초> <변경된key수> 는 여러 줄로 설정 가능하다. 이를 이용 자동 rdb 덤프 정책을 설정해줄수 있다.
  • save <초> <변경된key수> 설정을 아예 안해줄 경우 서버는 rdb 파일로 덤프를 자동으로 뜨지 않게 된다.(클라이언트 단에서 bgsave 나 save 명령을 내려야 덤프를 뜨게 된다.)
  • rdb 파일로 덤프하는 것은 메모리의 내용을 통째로 파일로 복사하는 것으로 순간적인 부하를 주게 되므로 위 설정을 조절해줘야 한다.
  • 테스트나 개발시 덤프 파일이 빨리 써지는 것을 보려면 저 값을 줄이면 되고 (save 10 1 같은 식으로)
  • 실제 서비스에서는 너무 자주 동기화가 일어나게 되면 안된다.

• rdbcompression yes
  • rdb 파일로 덤프할 때 텍스트 부분을 압축하여 rdb 파일의 사이즈를 줄인다. 사용하지 않으려면 no 를 설정해준다.
  • 압축을 하는 만큼 약간의 부하가 걸리지만 요즘 장비의 성능에서는 허용할 만한 수준으로 가능하면 사용하는것이 좋다.(서비스가 커지면 덤프 파일 크기가 장난 아니게된다)
  • 시스템 부하가 걱정된다면 일단 yes 로 쓰다가 부하가 걸린다면 no 로 변경하는것이 좋을듯 하다.

• dbfilename dumb.rdb
  • 덤프할 때 rdb 파일의 경로.
  • 또한 redis 서버를 실행할 때 이 부분이 설정되어 있다면, 이 파일에 있는 내용을 메모리에 올리게 된다.
  • 설사 save 설정을 사용하지 않는 상태라 해도 이 줄은 사용이 가능하다. 즉 레플리카 셋을 구성했을 경우 다음과 같은 활용이 가능하다.
    1. 마스터노드 에서 쓴 내용이 슬레이브노드에 복제됨
    2. 슬레이브노드에서 save 를 통해 rgb 파일을 덤프함
    3. 마스터노드에서 서버를 다시 실행할 때 슬레이브노드에서 덤프한 rgb 파일을 이용 메모리 에 db 내용을 살림

• dir ./
  • dbfilename 로 설정해준 rdb 파일이 저장되는 디렉토리. 이걸 왜 분리시켜놨는지 모르겠다는 -_-;
  • 어쨓든 기본값은 서버를 실행한 경로에 rdb 파일이 남게 되어 있는데, 이대로 두지 말고 rdb 파일을 저장하는 디렉토리를 따로 만들어서 절대 경로로 써주도록 하자.

REPLICATION (레플리카 셋 구성 설정)

• 레플레카 셋과 관련, 마스터노드 쪽 설정파일에서는 SECURITY 영역의 requirepass 부분 설정 말고는 해줄게 없다.(물론 방화벽 설정은 다른 차원의 문제). 즉 아래 내용들은 모두 슬레이브노드 에서만 설정해주면 되는 부분이다.
• slaveof
  • 마스터노드의 ip 와 포트번호를 적어주면된다. 레플리카 셋을 구성하지 않거나 마스터노드라면 그냥 주석처리된 채로 두면 된다.
• masterauth <master-password>
  • 마스터노드의 설정파일에서 requirepass 부분이 설정되어 있는 경우, 슬레이브노드의 설정파일에선 이 부분에 마스터노드의 패스워드를 적어줘야 한다.
• slave-serve-stale-data yes
  • 마스터노드와의 연결이 끊겼을 경우 슬레이브노드로 들어오는 명령에 어떻게 대처할지 설정해주는 부분
    • yes : 슬레이브노드에서 읽기나 쓰기 명령을 모두 받고 처리해준다.
    • no : 슬레이브노드로 들어오는 모든 명령에 에러상태를 되돌려준다. 쉽게 말해 읽기 쓰기 모두 처리 안해준다.
• repl-ping-slave-period 10
  • 슬레이브노드에서는 주기적으로 마스터노드에 ping 명령을 날려 마스터노드와의 접속상태를 확인하는데 그 주기(초단위)를 설정하는 부분. 기본값은 10초 이다.
• repl-timeout 60
  • 이 값은 대량의 I/O 와 data 에 대한 timeout 을 설정해주는 부분인데, repl-ping-slave-period 값 보다 크게 설정해줘야 한다.
  • 단위는 초단위 이고 기본값은 60초 이다.

SECURITY (보안 관련 설정)

• requirepass foobared
  • 패스워드를 설정해주는 부분. foobared 를 원하는 패스워드로 변경하면 된다.
  • 패스워드를 사용하지 않으려면 이 줄을 주석 처리 하면된다.
  • 패스워드가 설정된 경우 redis 서버에 접속한 후에 다음 명령으로 인증을 받아야 명령 사용이 가능하다
    • auth <패스워드>
• rename-command CONFIG ""
  • redis 명령을 다른 이름으로 바꿔주거나 아예 사용을 못하도록 설정하는 부분이다.
  • 예를 들어 SET 라는 명령을 SET2 라고 변경하려면 다음과 같이 하고
    • rename-command SET "SET2"
  • CONFIG 라는 명령을 아예 못 쓰게 막으려면 다음과 같이 해준다.
    • rename-command CONFIG ""

LIMITS (접속 및 메모리 사용 설정)

• maxclients 128
  • redis 서버에서 클라이언트의 접속을 동시에 몇 개 까지 받아들일지 설정하는 부분.
  • 0 으로 할 경우 무제한으로 접속을 받아들인다.
  • 설정된 수를 초과하여 클라이언트 접속이 시도되는 경우 에러를 반환해준다.
• maxmemory
  • 서버에서 사용할 물리적 메모리 양을 결정한다. 이 메모리양에는 실제 데이타는 물론 각종 설정 상태를 기억하는 부분 까지 포함된다.
  • 그냥 숫자만 쓰면 바이트 단위가 되며, 다음과 같은 표기도 가능하다.
    • 1k : 1000 bytes
    • 1kb : 1024 bytes
    • 1m : 1000000 bytes
    • 1mb : 1024*1024 bytes
    • 1g : 1000000000 bytes
    • 1gb : 1024*1024*1024 bytes
• maxmemory-policy volatile-lru
  • maxmemory 에서 설정한 메모리 를 초과해서 데이타를 쓰려고 할 경우의 정책 설정 부분으로 아래와 같은 옵션이 있다.
    • volatile-lru : (기본값) 만기시각이 설정된 key 들 중에서 LRU algorithm 에 의해 key 를 골라 삭제
    • allkeys-lru : LRU algorithm 에 의해 key 를 골라 삭제
    • volatile-random : 만기시각이 설정된 key 들 중에서 랜덤하게 key 를 골라 삭제
    • allkeys-random : 랜덤하게 key 를 골라 삭제
    • volatile-ttl : 만기시각이 설정된 key 들 중에서 만기시각이 가장 가까운 key 를 골라 삭제
    • noeviction : 어떤 key 도 삭제하지 않고 error on write operations 를 돌려준다.
  • LRU algorithm : Least Recently Used 로 최근에 가장 적게 사용한 메모리 공간을 비워버리고 활용하는 오라클 메모리 관리 방법

• maxmemory-samples 3
  • LRU algorithm 이나 만기시각으로 key 를 골라낼때 정확하게 조건에 맞는 key 를 골라내는게 아니라, 효율을 위해 몇개인가 key 들을 선택해 그 중에 최근에 덜 사용한 key 를 골라내는 방식을 사용한다. 이때 그 몇개인가 골라내는 key 들의 수를 설정해주는 부분.
  • 내 예상으로는 값이 클 수록 더 빨리 버릴 키를 골라낼수 있을 것 같다. 정확히 확인하려면 엄청 많은 데이타를 메모리에 올려 메모리를 풀 상태로 만든 뒤 이 값이 1일 때와 큰값(10000000 정도?) 인 경우에 새 key 값이 설정되는 시간을 비교해야 알 수 있을거 같다.

APPEND ONLY MODE (AOF 지속성 설정)

• RDB 지속성 설정과는 달리, AOF 지속성 설정은 메모리->파일 쓰기 와 파일->메모리 읽기를 따로 설정할 수 없다.
• appendonly no
  • aof 모드를 쓸지 여부를 설정. 사용할 경우는 yes 로 바꿔준다.
• appendfilename /usr/local/redis/dump/master_appendonly.aof
  • aof 파일의 풀 경로. rdb 설정과는 달리 경로와 파일명을 따로 쓰지 않는다.
• appendfsync everysec
  • aof 파일에 쓰는 주기를 결정하는 설정. 다음과 같이 3가지가 있다.
    • always : 매 명령마다 파일에 쓴다. 이는 너무 잦은 I/O 로 시스템에 부하를 줄 수 있다.
    • everysec : 매 초마다 파일에 쓴다. 기본값이며 가장 무난하다.
    • no : 파일에 쓸 내용들을 OS 의 출력버퍼에 집어 넣고, 파일에 쓰는 시점은 OS 에 맡겨버린다.
  • 그냥 everysecond 쓰고 1초안에 손실되는 내용 포기하는게 갑 인듯 하다. always 는 성능에 문제를 줄 수 있다.
• no-appendfsync-on-rewrite no
  • redis 서버의 동작 중 디스크에 큰 파일을 쓰는 작업이 두가지 있는데 Log rewritng 과 bgsave 이다.
  • apendfsync 옵션으로 always 나 everysec 를 사용중인 상태에서 "Log rewritng" 이나 "bgsave" 를 하게 되면 서로 disk I/O 에 방해가 될 수 있게 된다.
  • 이를 방지하는 옵션이 이 설정인데 yes 로 할 경우 "Log rewritng" 이나 "bgsave" 을 하는 중에는 aof 파일에 쓰기를 하지 않게된다.
  • 지연 문제가 발생하지 않으면 그냥 기본값인 no 로 쓰고, 문제가 생기면 yes 를 쓰라고 한다.
  • yes 로 할경우 최악의 시나리오일때 30초 이상의 변경내용을 잃어버릴 수 있다고 한다.(보통은 사고가 발생해도 aof 지속성 사용시 1초 미만의 변경내용을 잃게된다)
• auto-aof-rewrite-percentage 100
  • 최근 Log rewriting 이 일어났을때 aof 파일 크기에 비해 현재 aof 파일 크기가 여기서 설정해준 % 보다 커야 Log rewriting 이 일어난다고 한다.
  • 이 설정에 앞서 최소한 aof 파일의 크기가 auto-aof-rewrite-min-size 에 설정해준 값보다는 큰게 우선조건이다.
  • 근데 여러가지로 테스트 해보았지만 이 수치가 어떻게 적용되는지 정확하게 모르겠다. 그냥 기본설정으로 써도 무리는 없을 듯.
  • Log rewritng 을 사용하지 않으려면 이 값을 0 으로 하면 된다.
• auto-aof-rewrite-min-size 64mb
  • Log rewriting 이 일어나기 위한 aof 파일의 최소 크기. 일단은 그냥 써보자

SLOW LOG

• 연구 안함
• slowlog-log-slower-than 10000
• slowlog-max-len 128

VIRTUAL MEMORY (가상메모리 설정)

• 연구 안함
• vm-enabled no
• vm-max-memory 0
• vm-page-size 32
• vm-pages 134217728
• vm-max-threads 4
• set-max-intset-entries 512

ADVANCED CONFIG

• string 형을 제외한 4개의 데이타형은 포함하고 있는 요소의 개수나, 가장 긴 요소의 길이에 따라 인코딩방식(key 의 값을 저장하는 방식)이 달라진다. 이에 관한 설정을 해주는 부분이다.
• hash-max-zipmap-entries 512
  • hash 에 포함된 필드의 종류가 이 값보다 크면 hashtable 로 아니면 zipmap 으로 encoding 된다.
• hash-max-zipmap-value 64
  • hash 에 포함된 필드의 값중 가장 긴 값의 길이가 이 값보다 크면 hashtable 로 아니면 zipmap 으로 encoding 된다.
• list-max-ziplist-entries 512
  • list 에 포함된 요소의 개수가 이 값보다 크면 linkedlist 로 아니면 ziplist 로 encoding 된다.
• list-max-ziplist-value 64
  • list 에 포함된 요소중 가장 긴 요소의 길이가 이 값보다 크면 linkedlist 로 아니면 ziplist 로 encoding 된다.
• set-max-intset-entries 512
  • set(집합 형) 에 포함된 요소의 개수가 이 값보다 크거나 정수가 아닌 요소가 하나라도 포함되어 있다면 hashtable 로 아니면 intset 으로 encoding 된다.
• zset-max-ziplist-entries 128
  • zset(정렬된집합 형) 에 포함된 요소의 개수가 이 값보다 크면 skiplist 로 아니면 ziplist 로 encoding 된다.
• zset-max-ziplist-value 64
  • zset(정렬된집합 형) 에 포함된 요소중 가장 긴 요소의 길이가 이 값보다 크면 skiplist 로 아니면 ziplist 로 encoding 된다.
• activerehashing yes
  • hash table 의 rehashing 을 돕기위해 CPU 시간 100 밀리초 마다 1 밀리초를 사용하도록 설정하는 옵션. 이라고 하는데 잘 모르겠다.
  • CPU 시간 1%을 이용해 메모리의 반환을 조금 더 빨리 해주도록 하는 옵션인거 같다. 일단 yes 로 두자.

INCLUDES

• 설정파일을 통짜로 하지 않고 여러 조각의 파일로 나누어 쓸 경우 include 를 사용한다.
• include /path/to/local.conf
  • 포함시킬 설정 파일의 경로

redis command

Keys 관련

DEL key [key ...]

• 설명 : key 들을 삭제해준다.
• 파라미터
  • key : 삭제할 key 들을 공백으로 구분해 써준다.
• 리턴값 : 실제로 삭제한 키들의 개수를 반환

DUMP key

• 설명 : redis 2.6.0. 이상부터 지원되는 명령. key 에 저장된 값을 redis 에서 사용하는 포맷으로 직렬화 시켜 출력해준다. 이 직렬화된 값은 RESTORE 명령으로 다시 원래 값으로 되돌릴 수 있다.
• 파라미터
  • key : 값을 직렬화 시킬 key
• 리턴값 : 직렬화된 값

EXISTS key

• 설명 : 메모리에 key 가 존재하는지 체크
• 파라미터
  • key : 체크할 key
• 리턴값 : key 가 존재하면 1, 아니면 0

EXPIRE key seconds

• 설명 : key 에 만기시각을 설정해준다.
• 파라미터
  • key : 만기시각을 설정해줄 key
  • seconds : 지금부터 몇 초후에 만기시킬지 값
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

EXPIREAT key timestamp

• 설명 : key 에 만기시각을 설정해준다.
• 파라미터
  • key : 만기시각을 설정해줄 key
  • timestamp : 만기시킬 unixtimestamp
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

KEYS pattern

• 설명
  • 패턴에 맞는 키를 찾아서 출력해준다.
  • 노트북 정도의 성능에서 100만개 키를 가진 DB 를 검색하는데 40밀리초 정도가 소요된다고 한다.(즉 충분히 빠르다)
  • 그렇다고 해도 이 명령을 서비스 상에서 사용하려면 극도로 주의해야 한다. 예상할 수 있겠지만 아주 큰 DB 에서 패턴에 맞는 key 들을 찾아내면 성능에 영향을 줄 수 있다.
  • 서비스 에서 key 들을 검색해야 하는 명령이 필요하다면 차라리 sets 등을 활용하는게 나을 것이다.
• 파라미터
  • pattern : key 를 검색할 패턴으로 아래 예들을 참고
    • h?llo matches hello, hallo and hxllo
    • h*llo matches hllo and heeeello
    • h[ae]llo matches hello and hallo, but not hillo
• 리턴값 : 찾은 key 들의 목록

MIGRATE host port key destination-db timeout

• 설명
  • 이 명령은 한 redis 서버 에서 다른 redis 서버로 한 key 를 옮기는 명령이다.
  • 2.6.0 부터 지원한다.
  • 내부적으로 다음과 같은 액션이 일어난다.
    • 출발지 redis 서버에서 DUMP+DEL
    • 목적지 redis 서버에서 RESTORE
• 파라미터
  • host : 목적지 redis 서버 host
  • port : 목적지 redis 서버 port 번호
  • key : 옮길 key
  • destination-db : 목적지 redis 서버 의 DB index
  • timeout : timeout
• 리턴값 : status reply 참고. 성공시는 OK 를 리턴한다.

MOVE key db

• 설명 : key 를 다른DB(다른 index의 DB) 로 옮긴다.
• 파라미터
  • key : 옮길 key
  • db : 목적지 DB 의 index
• 리턴값 : 옮기는데 성공하면 1, 아니면 0

OBJECT subcommand [arguments [arguments ...]]

• 설명 : key 와 관련된 redis 객체의 내부를 검사 해주는 명령. 이라고 되어 있는데 key 에 저장된 데이타에 대한 row 한 레벨의 정보 몇 가지를 확인하는 명령으로 보인다. 일단 이런 명령이 있다는 정도만 알아두면 될 듯.
• 파라미터 : subcommand 에 따라 용도가 다르다.
  • OBJECT REFCOUNT key : key 의 값을 참조하는 수를 구해준다는데 아직까진 1 밖에 못 본 상태.
  • OBJECT ENCODING key : key 의 값이 인코딩 방식.
    • Strings : raw or int
    • Lists : ziplist orlinkedlist
    • Sets : intset or hashtable
    • Hashes : zipmap or hashtable
    • Sorted Sets : ziplist or skiplist
  • OBJECT IDLETIME key : key 가 유휴 상태였던 시간. 아마 메모리상에서 읽히지 않았던 시간 같은데 정확한 내부 구현이나 값은 모르겠다.
• 리턴값 :

PERSIST key

• 설명 : 만기시각을 없애 버림
• 파라미터
  • key : 만기시각을 없앨 key
• 리턴값 : 성공하면 1, 아니면 0

PEXPIRE key milliseconds

• 설명 : key 에 만기시각을 밀리초 단위로 설정해준다.(2.6.0 이상 지원)
• 파라미터
  • key : 만기시각을 설정해줄 key
  • milliseconds : 지금부터 몇 밀리초후에 만기시킬지 값
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

PEXPIREAT key milliseconds-timestamp

• 설명 : key 에 밀리초 단위로 만기시각을 설정해준다.(2.6.0 이상 지원)
• 파라미터
  • key : 만기시각을 설정해줄 key
  • milliseconds-timestamp : 만기시킬 unixtimestamp 의 밀리초 환산값
• 리턴값 : 만기시각 설정에 성공하면 1, 실패하면 0

PTTL key

• 설명 : 해당 key 가 만기되기까지 남은 밀리초 값(2.6.0 이상 지원)
• 파라미터
  • key : 체크할 key
• 리턴값 : 구한 밀리초 값. 못 구한경우 -1

RANDOMKEY

• 설명 : 현재 DB 에서 랜덤하게 key 를 하나 구해준다.
• 파라미터 : 없음
• 리턴값 : 구한경우 구한 key, 빈 DB 인 경우 nil

RENAME key newkey

• 설명 : key 이름을 변경해준다. 만약 newkey 가 이미 존재하는 key 라면 덮어씌워 버리게 된다.
• 파라미터
  • key : 원래 key 이름
  • newkey : 새 key 이름
• 리턴값 : 성공하면 OK, 실패하면 에러메시지

RENAMENX key newkey

• 설명 : key 이름을 변경해준다. 만약 newkey 가 이미 존재하는 key 라면 실패한다.
• 파라미터
  • key : 원래 key 이름
  • newkey : 새 key 이름
• 리턴값 : 성공시 1, 실패시 0

RESTORE key ttl serialized-value

• 설명 : DUMP 명령으로 구한 직렬화된 값을 다시 메모리 상에 올림
• 파라미터
  • key : 직렬화된 값을 복구해서 넣을 key 이름
  • ttl : 만기시각 초단위 값. 0으로 하면 만기시작 설정안함
  • serialized-value : DUMP 명령으로 구한 직렬화된 값
• 리턴값 : 성공하면 OK, 실패하면 에러메시지

SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC|DESC] [ALPHA] [STORE destination]

• 설명 : list, set, sorted set 형의 key 에 포함된 요소들을 파라미터들로 정해준 조건대로 정렬해서 보여준다.
• 파라미터
  • key : 요소들을 보여줄 key
  • [BY pattern] : (이 key 외의) 다른 key 값들을 이용해서 이 key 의 요소들을 정렬하고 싶을때 사용. 예를 들어
    • mylist 라는 list 형의 key 에 "kweok", "kim", "park", "jung", "lee" 라는 요소들이 있고
    • count_kim 이라는 string 형의 key 에 100 이라는 값이 있고
    • count_lee 이라는 string 형의 key 에 82 이라는 값이 있고
    • count_park 이라는 string 형의 key 에 55 이라는 값이 있고
    • count_jung 이라는 string 형의 key 에 47 이라는 값이 있을 때,
    • mylist 의 요소들을 count_* 에 해당하는 key 들의 값에의해 정렬하고 싶다면
    • sort mylist by count_* 라고 실행 해주면 된다.
    • 정렬안하기 : 정렬에 대한 오버헤드 없이 SORT 명령을 쓰기 위해서는 BY nosort 라고 해주면 된다.
  • [LIMIT offset count] : 정렬 결과에서 일부만 보고 싶을때 offset count 값을 넣어준다.
  • [GET pattern [GET pattern ...]] : 요소의 값 말고 해당 요소를 key 이름에 포함하고 있는 key 의 값을 출력하고 싶을때 사용. GET 은 여러 필드를 표현하기 위해 여러번 사용 가능한데, GET # 이라 할 경우 원래 요소의 값이 보여진다. 예를 들어
    • userids 라는 list 형의 key 에 "10", "17", "21", "22", "27" 이라는 요소들이 있고
    • string 형인 username_10, username_17, username_22 라는 key 들에 각각 "Huni Kim", "Suwon Lee", "James Park" 라는 값들이 있으며
    • string 형인 age_10, age_21, age_22, age_27 라는 key 들에 각각 34, 27, 16, 24 라는 값들이 있다면
    • sort userids get # get username_* get age_* 같이 실행하면 다음과 같이 구해진다.
      1. "10" <-- userids 의 첫번째 요소
      2. "Huni Kim" <-- username_10 의 값
      3. "34" <-- age_10 의 값
      4. "17"" <-- userids 의 두번째 요소
      5. "Suwon Lee" <-- username_17 의 값
      6. (nil) <-- age_17 의 값
      7. "21"" <-- userids 의 세번째 요소
      8. (nil) <-- username_21 의 값
      9. "27" <-- age_21 의 값
      10. "22"" <-- userids 의 네번째 요소
      11. "James Park" <-- username_22 의 값
      12. "16" <-- age_22 의 값
      13. "27"" <-- userids 의 다섯번째 요소
      14. (nil) <-- username_27 의 값
      15. "24" <-- age_27 의 값
  • [ASC|DESC] : 정렬결과를 오름차순으로 보려면 ASC(기본값), 내림차순으로 보려면 DESC 를 넣어준다.
  • [ALPHA] : 정렬은 기본적으로 수(정수 와 실수) 기준으로 하게 되며 수가 아닌경우 0 으로 처리 된다. 이때 문자열 기준으로 정렬하고 싶으면 ALPHA 를 포함시키면 된다.
  • [STORE destination] : 정렬 결과를 출력하지 않고 destination 로 정해준 key 에 넣어준다.
• 리턴값 :

TTL key

• 설명 : 해당 key 가 만기되기까지 남은 초 값
• 파라미터
  • key : 체크할 key
• 리턴값 : 구한 초 단위값. 못 구한경우 -1

TYPE key

• 설명 : 해당 key 의 데이타 형을 구해준다.
• 파라미터
  • key : 데이타형을 구할 key
• 리턴값 : key 의 데이타 형을 구한 경우 "string", "list", "set", "zset" or "hash". 못 구한 경우 "none"

Strings Data Type 관련

APPEND key value

• key 의 값 뒤에 value 를 추가해준다.

SETRANGE key offset value

• key 에 저장된 문자열의 offset 부분부터 value 값을 덮어 씌워버린다.

GETRANGE key start end

• key 에 저장된 문자열의 start ~ end 범위의 부분 문자열을 구해준다.(substring 이라는 함수와 비슷하다.)

STRLEN key

• key 에 저장된 문자열의 길이를 구해준다.

DECR key

• key 에 저장된 정수 값에서 정수 1을 빼준다.

DECRBY key decrement

• key 에 저장된 정수 값에서 정수 decrement을 빼준다.

INCR key

• key 에 저장된 정수 값에 1을 더해준다.

INCRBY key increment

• key 에 저장된 정수 값에 정수 increment 를 더해준다.

INCRBYFLOAT key increment

• key 에 저장된 실수 값에 increment 를 더해준다. (2.6.0 이상 지원)

SET key value

• key 에 value 를 저장한다.

SETNX key value

• key 에 value 를 저장한다. 단 key 에 이미 값이 저장되어 있는 경우 실패한다.

SETEX key seconds value

• key 에 value 를 저장하면서 만기시각을 seconds 초 후로 설정한다.

PSETEX key milliseconds value

• key 에 value 를 저장하면서 만기시각을 milliseconds 밀리초 후로 설정한다. (2.6.0 이상 지원)

MSET key value [key value ...]

• 복수개의 key 들에 각각의 value 를 저장해준다.

MSETNX key value [key value ...]

• 복수개의 key 들에 각각의 value 를 저장해준다. 단 나열한 key 중에 이미 값이 저장되어 있는 key 가 하나라도 있다면 모든 set 은 실패한다.

GETSET key value

• key 에 value 를 저장하고, 원래 있던 값을 구해준다.

GET key

• key 의 값을 구해준다.

MGET key [key ...]

• 복수개의 key 들의 값들을 구해준다.

SETBIT key offset value

• key 의 offset 번째 비트에 value(0 or 1) 을 셋해준다.
• offset 과 해당하는 bit 의 값의 관계이다.

GETBIT key offset

• SETBIT 명령으로 값이 정해진 key 의 offset 번째 bit 값(0 or 1) 을 구해준다. 자세한건 SETBIT 명령 참고

Hashes Data Type 관련

Lists Data Type 관련

Sets Data Type 관련

Sorted Sets Data Type 관련

Pub/Sub 관련

• 이기능은 대화방 이나 메신저를 만들때 사용하는 부분 같다.(예상임)
• 다음과 같은 테스트를 해보았다.
  • 동일한 redis 서버에 3개의 클라이언트를 접속 시켰다. 편의상 1번 2번 3번 클라이언트라 칭하겠다.
  • 1번 클라이언트에는 subscribe ch1 ch2 ch3 이라는 명령을 실행했다. (ch1, ch2, ch3 이라는 채널에서 들어오는 메시지를 기다리란 뜻)
  • 2번 클라이언트에는 subscribe ch1 ch4 라는 명령을 실행했다. (ch1, ch4 라는 채널에서 들어오는 메시지를 기다리란 뜻)
  • 3번 클라이언트에서 publish ch1 "hi hi hi" 라고 하자 1번, 2번 클라이언트에 "hi hi hi" 라는 메시지가 떴다.
  • 3번 클라이언트에서 publish ch2 "hello~" 라고 하자 1번 클라이언트에만 "hello~" 라는 메시지가 떴다.
  • 3번 클라이언트에서 publish ch3 "world" 라고 하자 1번 클라이언트에만 "world" 라는 메시지가 떴다.
  • 3번 클라이언트에서 publish ch4 "good !!" 라고 하자 2번 클라이언트에만 "good !!" 라는 메시지가 떴다.
• redis-cli 에서는 subscribe 나 psubscribe 실행한 후에 더이상 명령을 입력받지 않게 되므로 unsubscribe 나 punsubsribe 를 어떻게 입력하는가 하는 의문이 들 수 있다. telnet 등으로 해당 redis 서버에 접속해서 subscribe 명령을 입력해보면 listen 상태가 되어서도 unsubscribe 명령이 입력가능한 것을 확인할 수 있다.

SUBSCRIBE channel [channel ...]

• 나열한 channel 들에 해당하는 채널들로 들어오는 메시지를 대기(listen) 하는 명령.

PSUBSCRIBE pattern [pattern ...]

• 나열한 pattern 들에 일치하는 채널들로 들어오는 메시지를 대기(listen) 하는 명령.

PUBLISH channel message

• channel 이라는 채널에 message 를 메시지로 보낸다. channel 에 해당하는 채널에서 listen 중인 클라이언트 들 모두에게 메시지가 전달된다.

UNSUBSCRIBE [channel [channel ...]]

• channel 들 에서의 listen 을 취소한다.

PUNSUBSCRIBE [pattern [pattern ...]]

• pattern 에 매칭되는 채널 들에서의 listen 을 취소한다.

Transactions 관련

• redis 에서 제공하는 트랜잭션은 좀 쓰기가 애매하다.
  • 일단 트랜잭션 에 대한 롤백이 되지 않는다.
  • 트랜잭션 실행 중에 어떤 명령이 실패해도 뒤에 명령들은 그대로 실행이 되어버린다.

MULTI

• 트랜잭션의 준비를 알리는 명령. MULTI 명령 후에 입력한 명령 들은 EXEC 명령이 실행되기 전까지 실행되지 않고 큐에 쌓인다.

EXEC

• 트랜잭션을 실행시키는 명령. MULTI 명령 후에 입력한 명령들은 EXEC 명령이 실행되면 차례대로 실행된다.

DISCARD

• MULTI 명령 후, EXEC 실행전에 이 명령을 실행하면 큐에 쌓인 명령들을 지워버린다. MULTI 역시 실행안한 상태가 된다.

WATCH key [key ...]

• ????

UNWATCH

• watch 중인 key 들의 watch 를 취소함.

Scripting 관련

• Lua Script 를 실행해주는 명령 들인데 redis 2.6.0 에서부터 지원한다.

Connection 관련

AUTH password

• 접속한 redis 서버에 패스워드가 걸려있는 경우, 이 명령으로 인증을 받아야 명령 사용이 가능하다.
• 패스워드 설정은 설정파일의 requirepass 부분을 변경해주면 된다.

ECHO message

• message 를 그대로 출력해준다. 접속이 정상적으로 되었는지 등을 확인할 때 사용.

PING

• 접속상태를 확인하게 입력해보는 명령. 정상적으로 접속되어있다면 PONG 이라는 문자열을 출력해준다.

QUIT

• redis 서버와의 접속을 끊는다.

SELECT index

• 사용할 DB 의 index 를 선택한다. index 의 시작은 0 이며, 따로 SELECT 명령을 사용하지 않을 경우 0 번 DB 가 선택되어 있게 된다.
• DB 의 index 로 사용가능한 최대 값은 설정파일의 databases 부분의 값을 변경하면 된다.

Server 관련

SAVE

• 동기적으로 RDB 파일을 쓰게한다.

BGSAVE

• 비동기적으로 RDB 파일을 쓰게한다.

BGREWRITEAOF

• 비동기적으로 AOF 파일을 쓰게한다.

CONFIG GET parameter

• 설정 parameter 의 값을 보여준다.
• parameter 에 패턴도 입력이 가능하다. 즉 CONFIG GET * 라고 실행하면 모든 설정값들을 확인할 수 있다.

CONFIG SET parameter value

• 설정 parameter 의 값을 value 로 설정한다.

CONFIG RESETSTAT

• INFO 명령에 의해 구해진 통계를 재설정 하는 명령. 이라는데 뭐에 쓰는건지 모르겠다.

DEBUG OBJECT key

• key 의 디버깅 정보를 보여주는데, 문서에 보면 클라이언트 단에서 사용하면 안된다고 되어 있다(그럼 왜 만들어둔거야;) 이 명령 대신 OBJECT 명령을 사용하라고 한다.

DEBUG SEGFAULT

• 잘못된 메모리 접근을 통해 접속해 있는 redis 서버를 crash 시켜 버린다.
• 말그대로 접속해 있는 redis 서버를 죽여버리게 된다. 서버 프로세스가 kill 되어버린다.
• 버그 상황을 테스트 하기 위해 제공되는 명령으로 당연히 서비스 중인 서버에 사용하면 안된다.

MONITOR

• 접속한 redis 서버에 들어오는 모든 명령들을 실시간으로 확인할 수 있게 된다.

INFO

• 현재 redis 서버의 정보 및 통계 를 알려준다.
• 메모리 사용량, redis 서버 작동시간, key 들에 대한 정보, 최근 파일 동기화(지속성) 관련 정보 등을 알 수 있다.
• 모니터링 툴을 만든다면 이 명령 결과를 이용해야 할 것이다.

LASTSAVE

• 마지막으로 save 나 bgsave 가 일어난 시각을 unix timestamp 값으로 알려준다.
• 즉 RDB 지속성 에 의해 파일 쓰기가 일어난 최근 시각을 알려주는 명령

DBSIZE

• 현재 사용중인(select 명령으로 선택된) DB 에 저장되어 있는 모든 key 의 개수를 알려준다.

FLUSHALL

• 모든(select 된것만이 아니라) database 에서 모든 key 를 삭제해버린다.
• 당연한 얘기지만 사용에 주의하자

FLUSHDB

• 현재 select 된 DB 의 모든 key 들을 삭제해버린다.

SHUTDOWN [NOSAVE] [SAVE]

• 데이타 손실 없이 redis 서버를 안전하게 종료시킨다. 구체적으로 다음과 같은 일이 일어난다.
  1. 모든 클라이언트를 stop 시킨다.
  2. (설정파일에 save 설정이 한 줄 이라도 있다면)RDB 파일을 쓴다.
  3. (설정파일에 aof 사용이 활성화 되어 있다면)AOF 파일을 쓴다.
  4. redis 서버를 종료시킨다.
• 문서에는 NOSAVE 나 SAVE 를 파라미터로 쓸수 있다고 되어 있는데, redis-cli 상에서 써보면 파라미터 개수 자체가 안 맞다면서 에러가 난다. 어쨓든 문서상에 설명은 다음과 같다.
  • SHUTDOWN NOSAVE : 설정파일에 RDB 나 AOF 설정이 어떻게 되어있던간에 디스크에 쓰는 과정 생략하고 종료해버린다.
  • SHUTDOWN SAVE : 설정파일에 save 설정이 전혀 없더라도(물론 dbfilename 설정은 되어 있어야하겠지?) RDB 파일 쓰기를 하고 종료한다.

SLAVEOF host port

• 현재 접속한 redis 서버를 다른 redis 서버(host 와 port 로)의 (레플리카셋의)slave 로 만든다.
• 만약 이미 다른 master node 의 slave node 로 있는 서버에서 이 명령을 실행하면, 옛날 master node 와의 연결은 끊어지고 새로 입력한 node 를 master 로 삼게 된다.
• SLAVEOF 명령은 현재 연결되어 있는 master node 와의 연결을 끊는데도 사용할 수 있는데 다음처럼 실행하면 된다.
  • SLAVEOF NO ONE

SLOWLOG subcommand [argument]

• 확인못함

SYNC

• 복제에 사용되는 내부 명령어(즉 건들필요 없단 건데, 그럼 뭐하러 외부에 꺼내놨나 --;)

TIME

• 현재 서버의 시간을 구해준다. (2.6.0 이상 지원)