redis.conf

##
# 이 파일은 2.8.19 버전을 지준으로 작성되었습니다.
# 저장소에서 구하실 수 있습니다. https://github.com/HyunSeungBum/sbhyun_config.git
# 직역자: [email protected]

## Generated by install_server.sh ##
# Redis configuration file example

# 단위에 대해: 메모리 크기가 필요할때, 일반적인 1k 5GB 4M 형식이나 다음과 같은 형식을 지정할 수 있다.
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# 단위들은 대소문자 구분을 하지 않기 때문에 1GB 1Gb 1gB 는 모두 같다.

# 이 설정파일은 "CONFIG REWRITE" 로 재작성 되어진다. 문제는 "CONFIG REWRITE" 명령어는
# 값을 변경한 것을 이 설정파일 맨 아래에 추가한다는 것이다. 이 말은 이전의 설정은 다 필요없고
# 이 설정파일에 맨 마지막으로 읽은 설정을 Redis에 적용한다는 것을 말한다.
# 줄여서 말하면 중복해서 사용된 설정은 항상 마지막의 설정만 적용된다는 것이다.

################################## INCLUDES ###################################

# Include 는 하나 혹은 그 이상의 다른 설정 파일들을 여기에 포함된다. 이것은
# 모든 Redis 서버들에 표준적인 템플릿이 있지만 각 서버마다 몇개의 커스터마이징이 필요할때에 유용하다.
# Include 파일들은 또 다른 파일들을 포함할 수 있어 아주 넗게 사용된다.
#
# 주의해야할 옵션 "include" 은 admin 이나 Redis Sentinel 로부터
# "CONFIG REWRITE" 명령어로 재작성될 수 없다. Redis 는 설정 지시어의 값으로 항상
# 마지막으로 처리한 라인을 사용하기 때문에, 런타임에 변경된 설정을 덮어쓰는걸 피하기위해서
# 파일의 시작 부분에 포함시키는게 좋다.
#
# 만약 설정 옵션을 덮어쓰기위한 include 를 사용한것에 관심이 없다면 마지막 라인에 include 를
# 사용하는 것이 좋다.
#
# include /path/to/local.conf
# include /path/to/other.conf

################################ GENERAL  #####################################

# 기본적으로 Redis 는 데몬으로 동작하지 않는다. 만일 데몬으로 동작시키고 싶다면 'yes' 를 사용해라.
# 한가지 주의해야할 것은 데몬일때에 Redis 는 /var/run/redis.pid 에 pid 파일을 적는다.
daemonize yes

# 데몬으로 동작할때, Redis 는 기본적으로 /var/run/redis.pid 에 pid 파일을 적는다.
# 여기서 당신은 커스텀 pid 파일 위치를 지정할 수 있다.
pidfile /var/run/redis_6379.pid

# 지정된 포트에 접속을 허용하는데, 기본적으로 6379 다.
# 만약 port 0 으로 지정된다면 Redis 는 TCP 소켓이 listen 하지 않는다.
port 6379

# TCP listen() backlog.
#
# 초당 높은 요청이 있는 환경에서 클라이언트의 느린 접속 이슈를 피하기 위해서는 높은 backlog 가
# 필요하다. 주의할 것은 리눅스 커널은 /proc/sys/net/core/somaxconn 값을 자동적으로
# 비우게되는데, 원하는 효과를 얻기 위해서는 somaxconn 과 tcp_max_syn_backlog 값 두가지를
# 높여줘야 한다. 
tcp-backlog 511

# 기본적으로 Redis는 서버에서 활용할 수 있는 모든 network 인터페이스로부터 접속을 열어놓는다.
# 이것은 "bind" 설정 지시어를 사용해 다음과 같이 하나 혹은 여러개의 IP 주소를들을 하용해
# 하나 혹은 여려개의 인터페이스를 열어놓을 수 있다.
#
# Examples:
#
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1

# 들어오는 접속에 대해 listen 을 위해서 사용되어질 Unix socket 의 패스를 지정해라.
# 이것은 기본값이 없으며, 그래서 Redis 는 지정하지 않으면 Unix socket 을 열어놓지
# 않는다. 
#
# unixsocket /tmp/redis.sock
# unixsocketperm 700

# 클라이언트가 N 초동안 idle 후에 접속을 차단하라. (0 은 비활성화)
timeout 0

# TCP keepalive.
#
# 만약 0이 아니면, 커뮤니케이션의 부재중일때에 클라이언트에 TCP ACK 를 보내기 위해서
# SO_KEEPALIVE 를 사용해라. 이것은 두가지 이유에서 유용하다.
#
# 1) 죽은 피어(peer) 탐색.
# 2) Take the connection alive from the point of view of network
#    equipment in the middle.
#
# 리눅스에서, 지정된 값(초 단위)은 ACK를 보내기위해 사용되어지는 시간이다. 
# 주의해야할 것은 접속을 차단하기위해서는 두배의 시간이 필요하다.
# 다른 커널들에서는 이 시간은 커널 설정에 의존한다.
#
# 이 옵션에 대한 적당한 값은 60초 이다.
tcp-keepalive 0

# 서버 상세 레벨을 지정한다.
# 이것은 다음중에 하나 일수 있다.
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice

# 로그 파일 이름을 지정하라. 또한 빈 문자열은 Redis 에게 표준출력으로 로그하도록 강제하는데
# 사용되어질 수 있다. 주목해야할 것은 만약 당신이 데몬으로 동작중인데 로깅을 위해서
# 표준출력을 사용한다면 로그들은 /dev/null 로 보내질 것이다.
logfile /usr/local/redis/logs/redis.log

# 시스템 로거에 로깅을 활성화하기 위해, 그냥 'syslog-enabled' 를 'yes' 로 지정하고
# 옵션으로 필요한 것에 맞게 다른 syslog 파라메터들을 업데이트해라.
# syslog-enabled no

# syslog 식별자 지정
# syslog-ident redis

# syslog 설비 지정. LOCAL0-LOCAL7 사이나 USER 를 반드시 사용해라.
# syslog-facility local0

# 데이터베이스 수 지정. 기본 데이터베이스는 DB 0, 당신은 기본적으로 dbid 가 0 에서 database-1 사이 숫자로
# SELECT <dbid> 를 사용해 각 연결마다 다른 하나를 선택할 수 있다.
databases 16

################################ SNAPSHOTTING  ################################
#
# DB 를 디스크에 저장하기:
#
#   save <seconds> <changes>
#
#   만일 초단위의 시간과 DB에서 일어나는 쓰기 연산의 숫자, 두가지가 주어진다면 DB를 저장하게 된다.
#
#   예를들어, 아래의 행동들은 저장되게 될 것이다:
#   900초 (15 분) 동안 최소 1 개 키가 바뀐 경우 저장
#   300초 (5 분) 동안 최소 10 개 키가 바뀐 경우 저장
#   60초 동안 최소 10000개 키가 바뀐 경우 저장
#
#   주의: 당신은 save 라인 모두를 코멘트 처리함으로써 저장하는 것을 완벽하게 비활성할 수 있다. 
#
#   이것은 또 아래의 예제처럼 하나의 빈 문자열을 인자로 save 지시자를 추가함으로써
#   이전에 설정된 save 포인트들 모두를 제거할 수 있다:
#
#   save ""

save 900 1
save 300 10
save 60 10000

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

# .rdb 데이터베스로 덤프할때에 LZF 를 사용해 스트링 객체를 압축해라?
# 거의 항상 위너처럼 기본적으로 'yes' 로 지정해라.
# 만약 자식 프로세스가 저장하는데 CPU 자원을 절약하기 원한다면 'no' 로 지정할 수 있지만
# 압축 가능한 값이나 키가 있을 경우에 데이터셋(dataset)은 좀 더 커질 수 있다. 
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# 덤프할때 쓰일 파일 이름.
dbfilename dump.rdb

# 작업 디렉토리
#
# DB 는 위에 'dbfilename' 설정 지시어를 사용해 지정한 filename 으로 이 디렉토리 안에 쓰여질 것이다.
#
# Append Only File 또한 이 디렉토리 안에서 생성되어진다. 
#
# 주의할 것은 파일 이름이 아니라 디렉토리만 지정해야 합니다.
dir /usr/local/redis/data

################################# REPLICATION #################################

# Master-Slave 리플리케이션. 다른 Redis 서버의 복제 Redis 인스턴스를 만들기 위해서 slaveof 를
# 사용하라. 몇가지 Redis 리플리케이션에 대해서 ASAP 를 이해해야 한다.
#
# 1) Redis 리플리케이션은 비동기지만 만약 적어도 주어진 슬래이브에 연결되지 않는게 나타난다면,
#    당신은 쓰기 수신을 중단하도록 마스터를 설정할 수 있다.
# 2) Redis 슬레이브들은 상대적으로 아주 적은 시간동안 리플리케이션 링크를 잃었다면
#    마스터의 부분 재동기화를 수행할 수 있다. 당신의 필요에 의해 적절한 값을 가진 리플리케이션 백로그 크기를
#    설정할 수 있다. (이 파일의 다음 섹션을 보라)
# 3) 리클리케이션은 자동적이고 사용자 개입이 필요하지 않다. 네트워크 단절 이후에 슬레이브들은 자동적으로
#    마스터에 재접속하고 재싱크를 시도한다.
#
# slaveof <masterip> <masterport>

# 만약 마스터가 패스워드로 보호되고 있다면 (아래 "requirepass" 설정 지시어를 사용하기)
# 리플리케이션 동기화 과정을 시작하기전에 인증을 위해 슬레이브에게 말해줄 수 있으며 그렇지 않으면
# 마스터는 슬레이브 요청을 거절할 것이다.
#
# masterauth <master-password>

# 슬레이브가 마스터 접속을 잃었을때나 리플리케이션이 아직 진행중일때 슬레이브는 두가지의 다른 방법을
# 취할 수 있다:
#
# 1) 만약 slave-serve-stale-data 가 'yes'로 지정되어 있따면 슬레이브는 여전히 클라이언트
#    요청에 응답하거나, 아마도 out of data 를 가진 데이터, 만약 이것이 첫 동기화라면
#    그 데이터는 단순하게 빈(empty)채로 채워질 것이다.
#
# 2) 만약 slave-serve-stale-data가 'no' 로 지정되어 있다면 슬레이브는
#    INFO와 SLAVEOF 를 제외한 모든 명령어에 대해 "SYNC with master in progress" 에러를 응답할 것이다. 
#
slave-serve-stale-data yes

# 당신은 슬레이브 인스턴스가 쓰기를 받아들일지 말지를 설정할 수 있다. 쓰는것에 대해 슬레이브 인스턴스는
# 어떤 임시 데이터를 저장하는데 유용할 수 있지만 (왜냐하면 슬레이브에 데이터쓰기는 마스터에 재싱크후에 쉽게
# 삭제되어질 수 있기 때문이다.) 클라이언트가 슬레이브에 쓰기를 한다면 잘못된 설정으로 인한것으로
# 문제를 유발할 수 있다. 
#
# Redis 2.6 이후에 슬레이브들에게 read-only 는 기본값이 됐다.
#
# 주의: read only 슬레이브는 인터넷에 신뢰할수 없는 클라이언트에 노출되도록 디자인되지 않았다.
# 이것은 단순히 인스턴스의 오용에 대한 보호 레이어다. 여전히 read only 슬레이브는
# 기본적으로 CONFIG, DEBUG 를 비롯한 모든 관리 명령어들을 전달한다. 제한된 범위에서
# 당신은 모든 관리적이고 위험한 명령어의 쉐도우(shadow)를 위해 'rename-command' 사용해
# read only 슬레이브 보안을 개선할 수 있다.
slave-read-only yes

# 리플리케이션 SYNC 전략: disk or socket.
#
# -------------------------------------------------------
# 경고: DISKLESS 리플리케이션은 현재 실험상태이다.
# -------------------------------------------------------
#
# 새로운 슬레이브들이나 재접속중인 슬레이브들은 단순하게 차이만 받아서 리플리케이션 프로세스를 계속할 수 없으며
# "full synchronization" 이라 불리는 작업이 필요하다. RDB 파일은 마스터에서 슬레이브로 전송되어진다.
# 전송(transmission) 에는 두가지 다른 방법이 발생할 수 있다:
#
# 1) Disk-backed: Redis 마스터는 RDB 파일을 디스크에 쓰기위한 새로운 프로세스를 생성한다.
#                 나중에 이 파일은 부모 프로세스에 의해서 슬레이브에게 점진적으로(incrementally)
#                 전송되어 진다.
# 2) Diskless: Redis 마스터는 전체 디스크 접촉없이 슬레이브 소켓에 RDB 파일에 직접 쓰는
#              새로운 프로세스를 생성한다.
#
# disk-backed 리플리케이션은 RDB 파일이 생성되는 동안, 더 많은 슬레이브들이 대기할 수 있고,
# RDB 파일을 생성하는 현재 자식 프로세스가 작업을 완료하면 RDB 파일은 즉각 제공된다.
# diskless 리플리케이션은 전송을 시작하는 대신에 새로운 슬레이브들은 대기상태에 도달하고 and a new transfer
# will start when the current one terminates
#
# diskless 리플리케이션을 사용할때, 마스터는 여러 슬레이브와 연결이되거나 다중으로 전송할 수 있도록
# 전송을 시작하기전에 설정한 시간만큼 기달린다.
#
# 느린 디스크가 있고 대신 아주 빠른 네트워크를 가지고 있으면, diskless 리플리케이션은 잘 동작한다.
repl-diskless-sync no

# diskless 리플리케이션이 활성되면, RDB 파일을 슬레이브로 전송하기위해 서버가 자식 프로세스가 생성하는데
# 기다리는 딜레이 시간을 설정할 수 있다.
#
# 한번 전송이 시작된 이후, 이것은 매우 중요한데, 새로운 슬레이브를 받알 수 없고 다음 RDB를 전송하기 위해
# 대기할 수 있도 있고 서버는 더많은 슬레이브들을 받알수 있도록 딜레이 시간만큼 기다린다.
#
# 딜레이 시간은 초단위로 지정되고, 기본값은 5초이다. 전체적으로 비활성화하기 위해서는
# 단순하게 0으로 세팅하면 되고 전송은 ASAP를 시작한다.
repl-diskless-sync-delay 5

# 슬레이브들은 미리 정의된 간격(interval)으로 서버에 PING을 보낸다. 이 간격은 repl_ping_slave_period 옵션
# 으로 변경할 수 있다. 기본값은 10초이다.
#
# repl-ping-slave-period 10

# 아래의 옵션은 다음의 리플리케이션 타임아웃에 대해 지정한다:
#
# 1) Bulk transfer I/O during SYNC, from the point of view of slave.
# 2) Master timeout from the point of view of slaves (data, pings).
# 3) Slave timeout from the point of view of masters (REPLCONF ACK pings).
#
# 이것은 repl-ping-slave-period 지정된 값보다 확실히 커야한다게 매우 중요하며
# 그렇지 않으면 otherwise a timeout will be detected
# every time there is low traffic between the master and the slave.
#
# repl-timeout 60

# SYNC 후에 슬레이브 소켓에 TCP_NODELAY를 비활성화?
#
# 만약 당신이 "yes" 를 선택한다면 Redis 는 아주 작은 TCP 패킷과 슬레이브에
# 데이터를 보내기위해서 적은 대역폭을 사용할 것이다. 하지만 이것은 슬레이브측에서 데이터가 나타나는데
# 지연(delay)이 추가될 수 있으며, 기본 설정을 사용하는 리눅스 커널은 40ms 이상이다.
#
# 만약 'no'를 선택한다면 슬레이브측에 데이터가 나타나기위한 지연(delay)은 줄어드지만
# 리플리케이션을 위해서 좀 더 많은 대역폭이 사용되어질 것이다.
#
# 기본적으로 우리는 low latency 에 최대한 좋게 만들었지만 매우 높은 트래픽 환경이나
# 마스터와 슬레이브들이 아주 많은 홉(hop, 네트워크 용어다)을 거치거나 환경이면 튜닝을 위해
# "yes"로 하는것은 좋은 아이디어일 수도 있다.
repl-disable-tcp-nodelay no

# 리플리케이션 backlog 크기 지정. backlog 는 슬레이브들이 때때로 접속이 안될때 슬레이브 데이터를
# 축적하기위한 버퍼이고 그래서 슬레이브가 다시 접속되길 원할때, 종종 full resync 가 필요하지 않다,
# 부분 resync 만으로 충분하고, 단순히 접속이 차단되었을때에 빠진부분의 데이터 부분을 슬레이브에 전달한다.
#
# 아주 큰 리플리케이션 backlog는 오랫동안 슬레이브가 접속이 안되었을 수 있고 나중에 이것을 이용해
# 부분 재싱크를 실행할 수 있다. 
#
# backlog 는 적어도 슬레이브가 연결되어질때 한번만 할당된다.
#
# repl-backlog-size 1mb

# 마스터는 몇 분동안 슬레이브에 연결이되지 않는다면 backlog 는 해제되어 진다. 아래의 옵션은
# 마지막 슬레이브가 차단되었을때부터 경과하기 시작하는, backlog 버퍼를 해제하는데 필요한 시간을 설정이다.
#
# 0은 backlog 를 결코 풀지 않는다는 의미다.
#
# repl-backlog-ttl 3600

# 슬레이브 우선순위는 INFO로 출력에서 Redis 에 의해서 발행되는 정수값이다. 
# 이것은 Redis Sentinel 에서 사용되어지는데, 마스터가 제대로 동작하지 않을 경우 마스터로 승격시킬
# 슬레이브를 선택하는 우선수위로 사용되어진다. 
#
# 낮은 우선순위 수를 가지는 슬레이브는 승격에 유리한데, 각각 10, 100, 25 Sential
# 의 우선순위를 가진 세개 슬레이브가 있다면 그중에 10 우선순위를 가진 슬레이브가 선택될 것이다.
#
# 대신, 아주 특별한 우선순위인 0은 슬레이브가 마스터로 역활을 하지 못하도록 표시하는 것으로
# 0 우선순위를 가진 슬레이브는 승격을 위해 결코 Redis Sential 에 선택되어지지 않는다.
#
# By default the priority is 100.
slave-priority 100

# 이것은 M 초 같거나 뒤떨어지는 시간을 가지는 N개의 접속된 슬레이브보다 적을 마스터에
# 쓰기를 받아들이는것을 중단하도록 한다.
#
# N 슬레이브들은 "online" 상태여야 한다.
#
# 초 단위 시간에서 뒤처짐은 반드시 <= 로 값을 정의해야 하는데 일반적으로 매초 보내지는
# 슬레이브로부터 받은 마지막 ping 을 계산한다.
#
# 이 옵션은 N 리플리카가 쓰기를 받아들이도록 보증하지 않지만 지정한 시간동안에 슬레이브들을 충분히
# 활용할수 없는 경우에 잃어버린 쓰기에 대한 window of exposure 를 제한 한다.
#
# 예를들어 적어도 lag <= 10 초를 가지는 3개의 슬레이브들을 필요하다면 다음과 같이 쓴다:
#
# min-slaves-to-write 3
# min-slaves-max-lag 10
#
# 하나 혹은 기능을 비활성화하기위해 0으로 세팅하기
#
# 기본값으로 min-slaves-to-write 은 0(기능 비활성화)이고 min-slaves-max-lag는 10이다.

################################## SECURITY ###################################

# 명령어를 진행하기 전에 AUTH <PASSWORD> 이슈로 클라이언트에게 요구하라. 이것은 redis-server
# 호스트에 접속을 신뢰할 수 없는 환경에서 유용하다.
#
# 이것은 이전 버전과의 호환성을 위해 주석을 유지하고 대부분의 사람이 auth 를 필요로하지 않는다.
# 경고: Redis 는 매우 빠르기 때문에 외부 사용자는 좋은 머신에대해 초당 150k 패스워드를 대입해
# 볼수 있다. 이것은 아주 강력한 패스워드를 사용하지 않으면 매우 쉽게 뚫릴것이라는 의미다.
#
# requirepass foobared

# Command renaming.
#
# 이것은 Redis 를 같이 쓰는 환경에서 위험한 명령어의 이름을 바꿀 수 있다. 예를들어
# CONFIG 명령은 내부용 툴을 사용할 수 있도록 추측하기 어려운 무언가로 변경될 수 있지만
# 일반적인 클라이언트를 위해서는 사용할 수 없다.
#
# Example:
#
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
# 또, 빈문자열로 이름을 변경함으로써 완벽하게 명령어를 죽일 수 있다:
#
# rename-command CONFIG ""
#
#
# 주의할 것은 이름을 변경하면 AOF 파일에 기록되는 것을 유의해야하며 슬레이브들에 전송할때
# 문제를 일으킬 수 있다.

################################### LIMITS ####################################

# 동시 접속 클라이언트의 최대 수를 지정. 기본값으로 이 제한은 10000 클라이언트로 지정되 있으나
# 만약 Redis 서버가 특정한 제한을 허용하기 위해서 프로세스 파일 제한을 설정할 수 없다면
# 허용된 클라이언트의 최대 수 = 현재 파일 제한 - 32 로 지정된다.(Redis 가 내부 사용을 위해
# 몇가지 파일 디스크립터를 예약하는것처럼)
#
# 제한에 도달되면, Redis 는 'max number of clients reached' 를 내보내기 위해서 모든 새로운
# 접속을 닫는다. 
#
# maxclients 10000

# 지정한 bytes 양만큰 더 많은 메모리를 사용하지 마라.
# 메모리 제한에 도달하게되면 Redis 는 eviction 정책에 따라 키 삭제를 시도한다.(see maxmemory-policy)
#
# 만약 Redis 가 정책에따라 키를 삭제하지 못하거나 정책이 'noeviction' 으로 지정되어 있다면
# Redis 는 좀 더 많은 메모리 사용하는 것에 명령어(SET, LPUSH와같은 명령어)에 에러로 응답하기 시작할 것이고
# GET 과 같은 read-only 명령어에만 응답할 것이다.
#
# 이 옵션은 보통 Redis 가 LRU 캐쉬처럼 사용하거나 인스턴스에('noeviction' 정책을 사용하는)
# 하드 메모리 제한을 지정할때에 유용하다.
#
# 경고: 만약 인스턴스가 maxmemory 에 도달한 슬레이브를 가지고 있는 경우,
# 슬레이브를 공급하는데 필요한 출력 버퍼의 크기는 사용하는 메모리 카운터에서 빼게 되며,
# 그래서 네트워크 문제나 resync 는 키가 어디에서 쫓겨났는지하는 탐색을 트리커하지 않을 것이고,
# 슬레이브의 출력 버퍼는 아주 많은 키의 삭제 추적을 위해 쫓겨나게되는 DELs of key 들로 가득차고
# 이는 데이터베이스가 완전히 비어질때까지 계속된다. 
#
# 짧게 말해서 만일 당신에게 슬레이브가 있다면 슬레이브 아웃 버퍼를 위해서 시스템에 얼마간의 free RAM
# 이 있어야하고 maxmemory 를 위해서 낮은 제한을 지정하길 제한한다.(하지만 정책이 'noeviction' 이라면
# 이거슨 불필요한 것이다.)
#
# 추가: maxmemory 는 Redis가 시작할때 운영체제로부터 메모리를 할당받는 개념이 아니다.
#      Redis 가 사용할 메모리의 제한을 두는 것 뿐이다. 따라서 maxmemory 값은 런타임(runtime)에서
#      바꿀 수 있다. 단, 제한을 둘때는 현재 사용중인 메모리 양보다 커야 한다. 
# maxmemory <bytes>

# MAXMEMORY POLICY: Redis 가 maxmemory 에 도달했을때, 무엇을 지울지를 어떻게 선택할까?
# 당신은 다섯개중에 선택할 수 있다:
#
# volatile-lru -> LRU 알고리즘을 이용해 만료시간이 설정되있고 만료된 키를 삭제.
# allkeys-lru -> LRU 알고리즘에 따라서 모든 키를 삭제.
# volatile-random -> 만료시간이 설정되있고 만료된 키를 랜덤으로 선택해 삭제. 
# allkeys-random -> 모든 키, 랜덤으로 모든 키를 선택해 삭제.
# volatile-ttl -> 만료시간에 근접한(minor TTL) 키를 삭제.
# noeviction -> 전혀 만료되지 않고, 단지 쓰기 연산에서 오류를 리턴한다.
#
# 주의: 위의 어떠한 정책을 가지던지간에, 퇴출을 위한 적절한 키가 아닐 경우에 Redis 는 쓰기 연산에서
#      오류를 리턴할 것이다
#
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort
#
# The default is:
#
# maxmemory-policy volatile-lru

# LRU 와 minimal TTL 알고리즘은 정확한 알고리즘이 아니지만 적절한 알고리즘이며(메모리를 절약하기 위해),
# 당신은 체크를 위해서 샘플 크기를 아주 쉽게 선택할 수 있다. 예를들어, 기본적으로 Redis 는 세개 키를 체크하고
# 최근에 덜 사용된 것중에 하나를 선택하는데, 당신은 다음의 설정 지시어를 이용해서 샘플 크기를 변경 할 수 있다.
#
# 추가: 만료된 key 를 골라낼때에 하나하나 다 조사하고 조건에 맞는지 판별한 후에 골라내는게 아니다.
# 단 몇개의 샘플(sample) 키를 골라서 그중에 오래된 key 를 선택하는 방법을 사용한다. 이때에 그
# 단 몇개의 샘플이 개수를 몇개로 할것인지를 결정하는 설정 지시어다.
#
# maxmemory-samples 3

############################## APPEND ONLY MODE ###############################

# 기본적으로 Redis 는 비동기적으로 데이터셋을 디스크에 덤프한다. 이 모드는 많은 애플리케이션에서
# 충분히 좋은 것이지만, Redis 일처리를 할때나 파워가 나갈때에 몇분간의 쓰기 데이터를
# 잊을 수 있다.(설정된 저장 포인트에 의존적이다.)
#
# Append Only File 은 아주 좋은 내구성을 제공하는 대안적인(alternative) 퍼시스턴스 모드이다.
# 예를들어 기본 데이터 fsync 정책을(설정파일 뒤에 나온다) 사용할 경우에 Redis 는 서버의 파워가
# 나가는것과 같은 드라마틱 이벤트시에(in a dramatic event) 쓰기의 순간을 잃어버릴 수 있거나,
# 운영체제가 여전이 잘 동작한다고 하더라도, Redis 처리에 어떤 문제를 가진 단일 쓰기가 일어날 수 있다. 
#
# AOF 와 RDB 퍼시스턴스는 문제없이 동시에 활성화 될수 있다. 만일 (Redis가) 시작할때에 활성화 되어 있으면
# Redis 는 아주 좋은 내구성을 보장하는 AOF 를 로딩할 것이다.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# fsync() 콜은 아웃버퍼에 좀더 많은 데이터를 기다리는 대신에 실질적으로 디스크에 데이터를 쓰도록
# 운영체제에게 말한다. 어떤 OS는 실제로 디스크에 데이터를 플러쉬(flush)할 것이고 또 다른 OS에서는
# 단순하게 ASAP 로 동작하도록 노력할 것이다.
#
# Redis 는 세가지의 다른 모드를 지원한다:
#
# no: fsync 하지마라, 이것은 OS가 원하는 때에 데이터를 플러쉬 하도록 한다. 매우 빠르다.
#     (OS 에 위임하는 것이다.)
# always: append only log 에 모든 쓰기가 된 후에 fsync. 느리다. 겁나 안전하다.
# everysec: 매초 fsync 를 한번만. 타협(Compromise).
#
# 기본값은 "everysec" 인데, 일반적으로 속도와 데이터 안전 사이를 적절히 타협한다. 
# It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# 확실하지 않다면, "everysec" 를 사용해라.

# appendfsync always
appendfsync everysec
# appendfsync no

# AOF fsync 정책이 always 나 everysec 로 지정되었을때에 백그라운드 저장하기 프로세스는
# (백그라운드 저장 이나 AOF 로그 백그라운드 재작성하기) 디스크에 대해 아주많은 I/O를 발생시키는 중일때
# 몇몇 리눅스 설정에서 Redis 는 fsync() 콜에 아주 긴 시간동안 블럭될 수 있다. 주의할 것은
# 현재 이것을 고칠 수 없으며 서로다른 쓰레드에서 fsync 를 수행중일때 조차도 우리의 동기 write(2) 콜은
# 블럭된다.

#
# 이 문제를 완화하기 위해서, BGSAVE 이나 BGREWRITEAOF가 진행되는 동안 메인 프로세스에서 호출되는
# fsync() 방지할 다음의 옵션 사용이 가능하다.
#
# 이것은 다른 자식 프로세스가 저장하는 동안, Redis 의 내구성은 "appendfsync none"와 같아진다는
# 걸 의미하다. 실용적인 측면에서 이는 최악의 시나리오에서 로그의 최대 30초까지 잃을 수 있음을 의미한다.
# (기본적으로 리눅스 세팅상황에서)
#
# 만약 당신이 latency 에 문제가 있다면 이것을 "yes" 로 켜라. 그렇지 않으면 내구성의 관점에서
# 가지고 올수 있는 최대의 안전성을 위해서는 "no"로 남겨둬라.

no-appendfsync-on-rewrite no

# 자동적으로 the append only file 에 재기록 한다.
# Redis 는 AOF 로그 크기가 지정된 퍼센트만큼 자라면, 묵시적으로 BGREWRTEAOF 호출해서 자동적으로
# 로그파일 재기록 된다. 
#
# 그것이 작동하는 방법이다: Redis 는 최종적으로 다시쓴 후에 AOF 파일의 크기를 기억한다.
# (만약 재시작한 후에 다시쓰기가 일어나지 않았다면, 시작시점에 AOF 파일의 크기가 사용된다)
#
# 이 기본 크기는 현재 크기와 비교한다. 만약 현재 크기가 지정된 퍼센트보다 크다면 재기록이 일어난다.
# 또, 당신은 재기록될 AOF 파일의 최소 크기를 지정할 필요가 있는데, 이것은 증가율에 도달하더라도
# AOF 파일을 재기록되는 것을 방지하는 데 유용하지만, 여전히 꽤 작다
#
# 자동적인 AOF 재기록 기능을 비활성화하기 위해서라면 0 퍼센트로 지정하라.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# AOF 파일은 Redis 가 시작되는 동안에, AOF 데이터가 메모리로 로드되는, 끝부분이
# 잘려져 있다는걸 발견하게 될수도 있다. 
# 이것은 Redis 가 동작중인 시스템이 크래쉬가 발생될 수 있는데, 특히
# ext4 파일시스템이 data=ordered 옵션없이 마운트되었을때에 발생될 수 있다.
# (그러나 운영체제가 정상적으로 동작하는 중일때, Redis 스스로 크래쉬 되거나 중단되었을때에는
# 일어나지 않는다.)
#
# Redis 는 또 이런 일이 발생하면 에러와 함께 종료되거나 시작시에 끝이 잘려진 AOF 파일이 발견되어지면
# 가능한 아주 많은 데이터를 로드하려 한다. 아래의 옵션은 이러한 행동을 제어한다.
#
# 만약 aof-load-truncated 가 yes 로 지정하면, 잘려진 AOF 파일은 로드되어지고 Redis 서버는
# 사용자의 이벤트를 알리기위해서 로그에 기록하기 시작한다. 그렇지 않고 옵션을 no 로 지정하면,
# 서버는 시작을 거부하고 에러와 함께 중단된다. 옵션이 no 로 지정되었을때, 사용자는 서버를
# 재시작하기 전에 "redis-check-aof" 유틸리티를 사용해 AOF 파일을 고쳐야 한다.
#
# 주의할 것은 만약 AOF 파일이 중간에 오류가 있는 것이 발견되어진다면, 서버는 에러와함께 종료될 것이다.
# 이 옵션은 오직 Redis 가 충분한 bytes 가 발견되이지 않더라도 AOF 파일로부터 더 많은 데이터를
# 읽도록 노력하게 만들뿐이다.
aof-load-truncated yes

################################ LUA SCRIPTING  ###############################

# Lua 스크립트의 최대 실행 시간. (milliseconds)
#
# If the maximum execution time is reached Redis will log that a script is
# still in execution after the maximum allowed time and will start to
# reply to queries with an error.
#
# When a long running script exceeds the maximum execution time only the
# SCRIPT KILL and SHUTDOWN NOSAVE commands are available. The first can be
# used to stop a script that did not yet called write commands. The second
# is the only way to shut down the server in the case a write command was
# already issued by the script but the user doesn't want to wait for the natural
# termination of the script.
#
# Set it to 0 or a negative value for unlimited execution without warnings.
lua-time-limit 5000

################################## SLOW LOG ###################################

# Redis Slow Log 는 지정된 실행시간을 초과한 쿼리를 기록하는 시스템이다. 실행시간은 클라이언트와
# 통신하는, 응답을 보내고하는 것과 같은, I/O 연산을 포함하지 않고 단지 명령어가 실행하는데 필요한
# 실제 시간일 뿐이다.(이것은 쓰레드가 블럭되어지고 다른 요청을 제공할수 없는 곳에서 명령어 실행단계일 뿐이다.)
#
# 당신은 두개의 파라메터로 슬로우 쿼리를 설정할 수 있다: 하나는 Redis 요청이 초과된 기록이 필요한 명령어가 무엇인지,
# 실행시간이 무엇인지, microseconds 단위, 다른 파라메터는 Slow log 길이이다. 새로운 명령어가
# 기록되어질때, 아주 오래된 명령어는 기록된 명령어 큐에서 제거되어진다. 
#
# 아래의 시간은 microsecond 단위로 표현되는데, 그래서 1000000는 1초와 같다. 주의해야할 것은
# 음수는(negative number) slow log 를 비활성화 하지만 0은 모든 명령어를 기록하도록 강제한다.
slowlog-log-slower-than 10000

# 이것의 길이에는 제한이 없다. 다만 메모리 소비만 주의하면 된다.
# "SLOWLOG RESET" slow log 에의해서 사용되어진 메모리를 갱신할 수 있다.
slowlog-max-len 128

################################ LATENCY MONITOR ##############################

# Redis latency 모니터링 서브시스템은 Redis 인스턴스 latency 의 원인과 연관된 데이터를 수집할
# 목적으로 runtime 시 서로다른 연산을 (견본을) 뽑는다.
#
# LATENCY 명령어를 통해 이러한 정보는 리포트를 얻고 그래프를 그릴수 있도록 사용자들에게 활용된다.
#
# 시스템은 latency-monitor-threshold 설정 지시어에 명시된 milliseconds 단위보다 크거나
# 같을때에 로그 연산들을 실행한다. 이 값이 0으로 지정하면 latency 모니터는 off 된다.
#
# 기본적으로 latency 모니털은 대부분 불필요하기에 비활성화되어 있다. 만일 latency 이슈가 없고
# 아주 큰 성능 충력을 가지는 데이터 수집은 큰 부하하에서도 측정되어질 수 있다. Latency 모니터링은
# 필요하다면 runtime 시에 "CONFIG SET latency-monitor-threshold <milliseconds>"
# 명령어를 사용해서 아주 쉽게 활성화될 수 있다.
latency-monitor-threshold 0

############################# Event notification ##############################

# Redis can notify Pub/Sub clients about events happening in the key space.
# This feature is documented at http://redis.io/topics/notifications
#
# For instance if keyspace events notification is enabled, and a client
# performs a DEL operation on key "foo" stored in the Database 0, two
# messages will be published via Pub/Sub:
#
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
#
# It is possible to select the events that Redis will notify among a set
# of classes. Every class is identified by a single character:
#
#  K     Keyspace events, published with __keyspace@<db>__ prefix.
#  E     Keyevent events, published with __keyevent@<db>__ prefix.
#  g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
#  $     String commands
#  l     List commands
#  s     Set commands
#  h     Hash commands
#  z     Sorted set commands
#  x     Expired events (events generated every time a key expires)
#  e     Evicted events (events generated when a key is evicted for maxmemory)
#  A     Alias for g$lshzxe, so that the "AKE" string means all the events.
#
#  The "notify-keyspace-events" takes as argument a string that is composed
#  of zero or multiple characters. The empty string means that notifications
#  are disabled.
#
#  Example: to enable list and generic events, from the point of view of the
#           event name, use:
#
#  notify-keyspace-events Elg
#
#  Example 2: to get the stream of the expired keys subscribing to channel
#             name __keyevent@0__:expired use:
#
#  notify-keyspace-events Ex
#
#  By default all notifications are disabled because most users don't need
#  this feature and the feature has some overhead. Note that if you don't
#  specify at least one of K or E, no events will be delivered.
notify-keyspace-events ""

############################### ADVANCED CONFIG ###############################

# 해쉬는 아주 작은 엔트리 개수를 가지고 있거나 아주 큰 엔트리가 주어진 threshold 초과할때, 효율적인
# 데이터 구조로 메모리를 사용하기 위해서 인코딩 된다. 이러한 threshold 아래의 지시어를 사용해서
# 설정되어질 수 있다. 
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# 해쉬와 비슷하게, 아주작은 리스트(list) 또한 공간을 절략하기 위해서 특별한 방법으로 인코딩 된다.
# The special representation 는 아래의 제한 아래 있을때에만 사용되어진다. 
list-max-ziplist-entries 512
list-max-ziplist-value 64

# Set은 단 하나의 경우에서만 특별한 인코딩을 가진다: when a set is composed
# of just strings that happen to be integers in radix 10 in the range
# of 64 bit signed integers.
# 아래의 설정 세팅은 이것을 특별한 메모리에 인코딩을 저장하는데 사용하기 위해서
# 셋의 크기의 제한을 지정한다.
set-max-intset-entries 512

# 해쉬와 리스트와 비슷하게, 정렬된(sorted) set 또한 공간을 절약하기 위해서 특별히 인코딩되어 진다.
# 이 인코딩은 오직 길이와 정렬된 set 의 element 가 아래의 제한 아래에 있을때만 사용되어진다:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# HyperLogLog sparse representation bytes limit. The limit includes the
# 16 bytes header. When an HyperLogLog using the sparse representation crosses
# this limit, it is converted into the dense representation.
#
# A value greater than 16000 is totally useless, since at that point the
# dense representation is more memory efficient.
#
# The suggested value is ~ 3000 in order to have the benefits of
# the space efficient encoding without slowing down too much PFADD,
# which is O(N) with the sparse encoding. The value can be raised to
# ~ 10000 when CPU is not a concern, but space is, and the data set is
# composed of many HyperLogLogs with cardinality in the 0 - 15000 range.
hll-sparse-max-bytes 3000

# Active rehashing 은 메인 Redis 해쉬 테이블를(the one mapping top-level
# keys to values) 재해슁(rehashing)을 돕기위해서 매번 CPU 타임의 100ms의 1ms 를 사용한다.
# Redis 에서 사용하는 해쉬 테이블 구현하기위해 lazy 재해슁을 실행시킨다: the more operation
# you run into a hash table
# that is rehashing, the more rehashing "steps" are performed, so if the
# server is idle the rehashing is never complete and some more memory is used
# by the hash table.
#
# The default is to use this millisecond 10 times every second in order to
# actively rehash the main dictionaries, freeing memory when possible.
#
# If unsure:
# use "activerehashing no" if you have hard latency requirements and it is
# not a good thing in your environment that Redis can reply from time to time
# to queries with 2 milliseconds delay.
#
# use "activerehashing yes" if you don't have such hard requirements but
# want to free memory asap when possible.
activerehashing yes

# 클라이언트 아웃 버퍼 제한(output buffer limit)은 어떤 이유에서 충분히 매우 빠른 서버로부터
# 데이터를 읽을 수 없는 클라이언트의 비접속을 강제하도록 사용되어질 수 있다.(a
# common reason is that a Pub/Sub client can't consume messages as fast as the
# publisher can produce them).
#
# 제한은 세개의 다른 클라이언트 등급에대해 다르게 지정될 수 있다:
#
# normal -> MONITOR 클라이언트를 포함한 일반 클라이언트들.
# slave -> 슬레이브 클라이언트들.
# pubsub -> 적어도 하나의 pubsub 채널 이나 패턴에 가입된 클라이언트들.
#
# 모든 client-output-buffer-limit 지시어 문법은 다음과 같다:
#
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
#
# 클라이언트는 hard limit 에 도달하거나 soft limit 에 도달하거나 지정된 시간이 다을때
# 즉각적으로 접속이 해제된다.
# 예를들어 hard limit 가 32MB 이고 soft limit 가 16MB / 10 second 이면
# 클라이언트는 아웃 버퍼 크기가 32MB에 도달하면 즉각적으로 접속이 해제되지만,
# 클라이언트가 16MB에 도달하거나 계속적으로 10초간 제한을 넘어선다면 또한 즉각적으로 접속이 해제된다.
#
# 기본적으로 normal clients 제한이 없다. 왜냐하면 asking (in a push way) 없이 데이터를
# 받을 수 없기 때문인데, 그래서 오직 비동기 클라이언트는 데이터를 읽는 것보다 훨씬 빠르게 요청되얼질 수
# 있는 시나리오를 생성해야 한다.(번역자: 뭔 소리냐? ㅡㅡ)
# 
# Instead there is a default limit for pubsub and slave clients, since
# subscribers and slaves receive data in a push fashion.
#
# hard 나 soft limit 양쪽 모두 0ㅇ으로 세팅하면 비활성화 될수 있다. 
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# Redis 는 많은 백그라운드 태스크를 실행하기 위해서 내부 함수를 호출한다.(타임아웃(timeout)
# 시에 클라이언트의 접속을 차단하는 것처럼, 결코 요청되지 않는 만료된 키를 퍼지(purge)하기,
# 기타 등등.)
#
# 모든 태스크가 같은 빈도(frequency)로 실행되지 않는데, 대신 Redis 는 모든 태스크에 대해
# "hz" 지정된 값에 따라 실행하기를 체크한다.
#
# 기본적으로 "hz" 는 10으로 지정된다. 값이 높아짐에따라 Redis 가 idle 이라도 좀 더 많은
# CPU 를 사용할 것이지만 같은 시점에서 좀 더 많은 키가 만료되었을때에 좀더 많은 응답을 만들어낼 서이고
# 타임아웃(timeout)은 좀 더 정확하게 다루어질 거다.
#
# 범위는 1과 500 사이지만 100 이상을 값은 일반적으로 좋은 아이디어는 아니다. 대부분의 사용자들은
# 기본값인 10을 사용하고 매우 낮은 latency 가 필요한 환경일 경우에 이것을 100이상 값으로
# 높여주어야 한다.
hz 10

# 자식이 AOF 파일을 재기록할때, 만약 아래의 옵션이 활성화되어 있다면 파일은 매번 생성된 데이터의 32MB가
# fsync 된다. 이것은 디스크에 좀더 점진적으로 파일에 커밋을 하거나 큰 latency 치솟는것을 피할때에 유용하다.
aof-rewrite-incremental-fsync yes