주절주절

* Redis protocol 이란 Redis client 와 Redis server 간 통신을 할때 사용되는 protocol 이다.
줄여서 RESP (Redis Serialization Protocol) 라고 부른다.

* 위 프로토콜의 장점은 무엇일까?

• 구현이 쉽다.
• 파싱이 빠르다.
• 인간이 읽기 쉽다.

위의 장점으로만 보면 엄청 좋아보인다. 그래서 얼마나 좋은지 직접 확인을 하였다.

일단 RESP 의 마지막은 \r\n (CRLF)  로 끝난다.

아래의 sample 을 확인 하겠다. 일단 string 로 변수 를 초기화 한다음. 변수에 값을 넣고 그 값을 file 로 write 한다. 이 부분에서 확인해야 하는부분은 바로 변수에 들어가는 값이다.

str_buf = str()
str_buf = '*3\r\n$3\r\nset\r\n$2\r\nab\r\n$2\r\n11\r\n'

with open('resp.fmt', 'w') as fp:
    fp.write(str_buf)

해당 값은 \r\n 으로 구분되며 각각의 설명은 아래와 같다.

*3 : 전체 명령 LINE 수 이다.

여기서는 set {command} / ab {key_name} / 11 {value} 의 개수가 3개 이므로 3 으로 표시

$3 : 다음 라인의 size 이다. set 이므로 숫자는 3 이다.

$2 : ab 이므로 2

위의 파일을 실행 후 생성된 resp.fmt 를 아래와 같이 실행 한다.

$ cat resp.fmt | redis-cli -h 127.0.0.1 --pipe
All data transferred. Waiting for the last reply...
Last reply received from server.
errors: 0, replies: 1

$ redis-cli get ab
"11"

redis-cli --pipe 명령어를 사용하여 replies: 1 이 표시되면 정상적으로 들어간것이다.

* 어떻게 사용할수 있을까?

나의 사용경험은 이렇다. 빠른 속도로 data 를 처리해야하는 웹서버 에서 redis 에 data 를 load 후 사용한 경험이 있었다.

이때, 기존은 data 들이 json 으로 되어 있어 json parsing 후 일일이 data 를 insert 하였는데 data 를 json file 로 생성하지 않고 resp format 형식으로 생성 후 필요할때마다 load 하고, load 된 key 를 expire 를 넣어 key 를  persistent 하게 보관하지 않아 memory over 가 발생되지 않게 한다. 이런식으로 사용을 하니 json load 및 parsing resource 를 감소할수 있었으며 client 가 redis command 를 resp 로 변환하는 resource 또한 줄일수 있다.

# 실행
./redis-server redis1.conf 

# 확인
ps -ef | grep redis
./redis-server 0.0.0.0:6379

# 접속
redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info Replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:104857600
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# redis slave conf
..
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379
..

# 실행
./redis-server redis2.conf

# 확인
ps -ef | grep redis
./redis-server 0.0.0.0:6379
./redis-server 0.0.0.0:6380

# 접속
redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:729
slave_priority:300
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:104857600
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# master 접속
redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info Replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1345,lag=1
master_repl_offset:1345
repl_backlog_active:1
repl_backlog_size:104857600
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1344

# Data Replication 확인
# master redis 에 abc key name 으로 123 값을 저장함

redis-cli -h 127.0.0.1 -p 6379 set abc 123
OK

# redis slave 접속 후 data 확인

redis-cli -h 127.0.0.1 -p 6380 get abc
"123"

* 정상적으로 master 에 입력한 data 를 slave 에서 확인이 가능 하다.
이러한 구성은 redis 의 traffic 을 분산 하는데 좋은 구성이 된다. 하지만 오직 master 만 write 를 할수 있기 때문에 redis master 가 down이 되면 master 를 못하는 문제점이 있다.
그래서 redis-sentinel 이라는 app 이 존재한다. redis-sentinel 은 redis master 를 감시하다가 master 가 down 이 되면 redis slave 를 master 로 승격하는 역활을 한다.

* Redis master / slave 란 ?

1. Redis Replication
1. Redis Replication 은 master / slave 구조로 되어 있다.
2. master 는 write / read 가 가능하며 slave 는 read 만 가능하다. ( slave 에서도 write 가 가능하지만 성능 저하가 발생하여 사용하지 않는다. )
3. master 는 n 개의 slave 를 가질수 있다.
4. Replication 은 non-blocking 으로 동작하기 때문에 master 의 operation 에는 영향이 적다

* Redis 란 무엇인가  ? 위키백과

1. Remote Directory Server의 약자
2. In-memory DB
3. 키-값 구조
4. 오픈소스