Redis is able to start without a configuration file using a built-in default configuration, however this setup is only recommanded for testing and development purposes.
The proper way to configure Redis is by providing a Redis configuration file, usually called redis.conf
.
The redis.conf
file contains a number of directives that have a very simple format:
Redis는 built-in 기본 구성을 사용하는 것으로 configuration 파일 없이 시작할 수 있다. 그러나 이 설정은 테스트 용도와 개발 목적으로 사용하길 권한다.
Redis를 구성하는 올바른 방법은 Redis configuration 파일을 사용하는 것이고, 보통 redis.conf라 부른다.
이 redis.conf 파일은 매우 간단한 형식의 지침들을 포함한다.
keyword argument1 argument2 ... argumentN
This is an example of configuration directive:
이것은 configuration 지침의 예제이다.
slaveof 127.0.0.1 6380
It is possible to provide strings containing spaces as arguments using quotes, as in the following example:
이것은 큰따옴표를 사용하는 인수로써 공백을 포함하는 문자열을 제공할 수 있고, 그 예제는 다음과 같다.
requirepass "hello world"
The list of configuration directives, and their meaning and intended usage is available in the self documented example redis.conf shipped into the Redis distribution.
이 지침들을 구성하는 리스트와 그것들이 의미하는 것과 용도는 자체 문서화 된 예제인 redis.conf에서 볼 수 있다.
- The self documented redis.conf for Redis 2.6.
- The self documented redis.conf for Redis 2.4.
Passing arguments via command line
Since Redis 2.6 it is possible to also pass Redis configuration parameters using the command line directly. This is very useful for testing purposes. The following is an example that stats a new Redis instance using port 6380 as a slave of the instance running at 127.0.0.1 port 6379.
./redis-server --port 6380 --slaveof 127.0.0.1 6379
The format of the arguments passed via the command line is exactly the same as the one used in the redis.conf file, with the exception that the keyword is prefixed with --
.
Note that internally this generates an in-memory temporary config file (possibly concatenating the config file passed by the user if any) where arguments are translated into the format of redis.conf.
커맨드라인을 통해 전달되는 인수의 형식은 Redis 파일에 사용된 것과 정확하게 같고 이미 정해진 키워드는 예외이다.
Note : redis.conf 형식으로 인자값이 전송됬을 때, 내부적으로 임시 config 파일을 in-memory에 생성한다(어떤 유저에 의해 전송된 config 파일을 합치는 것이 가능함),
Changing Redis configuration while the server is running
It is possible to reconfigure Redis on the fly without stopping and restarting the service, or querying the current configuration programmatically using the special commands CONFIG SET and CONFIG GET
Not all the configuration directives are supported in this way, but most are supported as expected. Please refer to the CONFIG SET andCONFIG GET pages for more information.
Note that modifying the configuration on the fly has no effects on the redis.conf file so at the next restart of Redis the old configuration will be used instead.
서비스 재부팅이나 프로그램을 중지시킬 필요 없이 Redis가 살아 있는 동안 재구성하는 것이 가능하다. 또는 CONFIG SET과 CONFIG GET을 사용하는 것으로 현재 configuration을 계획에 따라 조회하는 것이 가능하다.
이 방법은 직접 configuration하는 것을 지원하지 않는다. 그러나 대부분이 지원된다. 더 많은 정보 페이지들을 CONFIG SET 그리고 CONFIG GET 해서 알아볼 수 있다.
실행 중에 configuration을 덮어쓰는 것은 redis.conf 파일에 아무런 영향을 미치지 않는다. 그래서 재부팅해도 그거 대신에 예전 redis.conf 파일이 사용될 것이다.
Configuring Redis as a cache
If you plan to use Redis just as a cache where every key will have an expire set, you may consider using the following configuration instead (assuming a max memory limit of 2 megabytes as an example):
만약 모든 키가 expire로 설정될 위치에서 Redis를 캐시처럼 사용할 계획이라면, 이것 대신에 다음 configuration을 사용해 보는 것을 고려해야 한다.
maxmemory 2mb
maxmemory-policy allkeys-lru
In this configuration there is no need for the application to set a time to live for keys using the EXPIRE command (or equivalent) since all the keys will be evicted using an approximated LRU algorithm as long as we hit the 2 megabyte memory limit.
이 configuration은 EXPIRE 명령(또는 이와 동등한 것)을 사용하는 것으로 일일이 key들에 어플리케이션 시간(EXPIRE 시간)을 설정할 필요가 없다. 그래서 2메가 메모리 제한을 넘은 모든 Key만큼 LRU 알고리즘과 관련된 걸 사용해서 없앨 것이다.
This is more memory effective as setting expires on keys uses additional memory. Also an LRU behavior is usually to prefer compared to a fixed expire for every key, so that the working set of your data (the keys that are used more frequently) will likely last more.
Basically in this configuration Redis acts in a similar way to memcached.
이것은 추가적으로 메모리를 사용해서 모든 키들에 expire 설정을 하는 것 보다 메모리 효율적이다. 또한 LRU 동작은 보통 모든 키에 대해 고정된 expire를 비교하는 걸 선호한다. 그래서 마지막 남은 key(자주 사용하는 key)들은 좀 더 동작하고 있을 수 있다.
기본적으로 이 configuration에서 Redis는 memcached와 비슷하게 작동한다.
When Redis is used as a cache in this way, if the application also requires the use Redis as a store, it is strongly suggested to create two Redis instances, one as a cache, configured in this way, and one as a store, configured accordingly to your persistence needs and only holding keys that are not about cached data.
Note: The user is adviced to read the example redis.conf to check how the other maxmemory policies available work.
Redis가 이 방법으로 cache처럼 사용될 때, 만약 어플리케이션이 Redis를 저장소로 사용하길 요구한다면, 이것은 반드시 두 개의 Redis instance를 생성하길 권장한다. 하나는 이 방법으로 cache로 구성하고, 다른 하나는 당신이 필요하다고 생각되는 store로 만든다. 그리고 cache된 데이터가 아닌 key들을 holding한다.
Note : 유저는 어떤 식으로 maxmemory 정책을 사용하는지를 확인하기 위해 redis.conf 예제를 읽는 것으로 조언을 얻을 수 있다.
'Linux' 카테고리의 다른 글
[Llinux] Cron에 대해 알아보자 (0) | 2016.09.29 |
---|---|
[스크랩][Linux] dd 명령어 옵션 설명 (0) | 2014.08.16 |
[Redis][Doc] Redis Clients Handling (0) | 2013.10.07 |
[Linux][Redis][doc] Redis Administration (0) | 2013.09.30 |