자세한 Redis 최적화 구성

1. Redis 구성 전략

1.1 Redis 구성 파일

• 구성 매개 변수 (/etc/redis/6379.conf)

bind：监听的主机地址
port：端口（默认6379）
daemonize yes：启用守护进程
pidfile：指定PID文件
loglevel notice：日志级别
logfile：指定日志文件

1.2 Redis 데이터베이스에서 일반적으로 사용되는 명령

• redis-cli 명령 줄 도구

连接本地数据库
/usr/local/redis/bin/redis-cli
127.0.0.1:6379>

连接远程数据库
redis-cli -h 192.168.140.10 -p 6379
 192.168.140.10>

1.3 Redis 명령 도구

1.3.1 명령 도구 소개

• redis-server : Redis 시작 도구
• redis-benchmark :이 컴퓨터에서 Redis의 운영 효율성을 감지하는 데 사용됩니다.
• redis-check-aof : AOF 영구 파일 복구
• redis-check-rdb : RDB 영구 파일 복구
• redis-cli : Redis 명령 줄 도구
• redis-sentinel : 센티넬 모드를 시작하는 도구입니다.

1.3.2 redis-benchmark (테스트 도구) 명령 줄 옵션

• 기본 테스트 구문은 다음과 같습니다.

redis-benchmark [option] [option value]

-h: 指定服务器主机名
-p：指定服务器端口
-s：指定服务器socket
-c：指定并发连接数
-n：指定请求数
-d：以字节的形式指定SET/GET值的数据大小
-k：1=keep alive  0=reconnect
-r：SET/GET/INCR使用随机key，SADD使用随机值
-P：通过管道传输<numreq>请求
-q：强制退出redis，仅显示query/sec值
---csv：以CSV格式输出
-l：生成循环，永久执行测试
-t：仅运行以逗号分隔的测试命令列表
-I：Idle模式，仅打开N个idle 连接并等待

• 적용 사례

[root@server ~]# redis-benchmark -h 192.168.140.20 -p 6379 -c 100 -n 10000
//向IP地址为192.168.140.20，端口为6379的Redis服务器发送100个并发连接与10000个请求测试性能

2. Redis 다중 데이터베이스 작업

2.1 데이터베이스 분석

• Redis는 여러 데이터베이스를 지원하며 기본적으로 16 개의 데이터베이스가 지원되며 이름은 0-15입니다.

• 여러 데이터베이스는 서로 독립적이며 서로 간섭하지 않습니다.

• 
  여러 데이터베이스에 일반적으로 사용되는 명령 : 여러 데이터베이스 간 전환
  여러 데이터베이스 간에 데이터 이동 데이터베이스의 데이터
  지우기

2.2 명령 분석

2.2.1 여러 데이터베이스 간 전환

• Select 명령을 사용하여 여러 Redis 데이터베이스간에 전환
• 명령 형식

select index
//其中index 表示数据库的序号，而使用redis-cli 连接Redis数据库后，默认使用的是序号为0的数据库

• 적용 사례

127.0.0.1:6379> select 2      //此时表示从数据库0切换到数据库2
OK
127.0.0.1:6379[2]> select 10  //切换到数据库10
OK
127.0.0.1:6379[10]> 

2.2.2 여러 데이터베이스간에 데이터 이동

• Redis 데이터베이스는 여러 데이터베이스에서 데이터를 이동할 수있는 이동 명령을 제공합니다.
• 명령의 기본 구문 형식

move key dbindex
//其中“key“表示当前数据库的目标键，"dbindex"表示目标数据库的序号

• 적용 사례

127.0.0.1:6379> move q 10     //移动q到数据库10
(integer) 1
127.0.0.1:6379> get q   
(nil)
127.0.0.1:6379> select 10     //切换到数据库10
OK
127.0.0.1:6379[10]> keys *    列出key中的所有关键词
1) "q"

2.2.3 데이터베이스의 데이터 지우기

• Redis 데이터베이스의 전체 데이터베이스 데이터 삭제는 주로 두 부분으로 나뉩니다
  . 현재 데이터베이스 데이터
  지우기 , FLUSHDB 명령을 사용하여 모든 데이터베이스 데이터 지우기, FLUSHALL 명령을 사용하여 달성 (일반적으로 안 함)

• 적용 사례

127.0.0.1:6379> select 10    //切换到数据库10
OK
127.0.0.1:6379[10]> keys *   //列出key中的所有关键词
1) "q"
127.0.0.1:6379[10]> get q    //输出q键值
"10"
127.0.0.1:6379[10]> flushdb  //清除当前数据库中的数据
OK
127.0.0.1:6379[10]> keys *   //列出key中的所有关键词
(empty list or set)

2.3 Redis 데이터베이스에서 일반적으로 사용되는 명령

2.3.1 주요 관련 명령

• 키 : 규칙을 충족하는 키 값 목록을 가져옵니다.
• 존재 : 키 값이 존재하는지 확인
• del : 현재 데이터베이스의 지정된 키를 삭제합니다.
• 유형 : 키에 해당하는 값 유형을 가져옵니다.
• rename (덮어 쓰기) / renamenx (덮어 쓰지 않음) : 기존 키의 이름을 바꿉니다.
• dbsize : 현재 데이터베이스의 키 수보기

2.3.2 일반적으로 사용되는 명령의 적용 예

• 사용 예

[root@server1 ~]# redis-cli     //连接数据库

• s로 시작하는보기

192.168.140.20:6379> keys s*                 
1) "set1"
2) "set2"

• 키워드 세트가 존재하는지 확인하십시오 (1은 존재 함, 0은 존재하지 않음을 의미).

192.168.140.20:6379> exists set3
(integer) 0
192.168.140.20:6379> exists set1
(integer) 1

• 키워드 삭제, 작업 성공 출력 1

192.168.140.20:6379> del set1
(integer) 1

• 키에 해당하는 값 유형 가져 오기

192.168.140.20:6379> set string1 77
OK
192.168.140.20:6379> type string1
string
192.168.140.20:6379> type hash1   //获取hash1对应的vlane值类型
hash

• rename 명령은 기존 키의 이름을 바꿉니다.

rename命令进行重命名时，无论目标key是否存在都进行重命名，且源key的值会覆盖目标key 的值。
在实际使用过程中，建议先用exists命令查看目标 key是否存在，然后再决定是否执行rename命令，以避免覆盖重要数据
命令格式为 rename 源key 目标key

192.168.140.20:6379> set bw 1           //添加键值
OK
192.168.140.20:6379> set cw 2
OK
192.168.140.20:6379> rename cw bw   //重命名cw覆盖bw键值
OK
192.168.140.20:6379> get bw
"2"

• renamenx 명령은 기존 키의 이름을 바꾸고 새 이름이 있는지 확인합니다.

其命令格式与 rename 的命令格式除命令关键字不同外基本相同，renamenx源key目标key。
使用renamenx命令进行重命名时，如果目标key存在则不进行重命名
命令格式：renamenx 源key 目标key

192.168.140.20:6379> set bw 1
OK
192.168.140.20:6379> set cw 2
OK
192.168.140.20:6379> renamenx cw bw		//重命名cw覆盖bw键值，重命名失败
(integer) 0

3. Redis 구성 파일 분석

3.1 지속성 개요

개요 :

• Redis가 메모리에서 실행 중이며 전원이 꺼지면 메모리의 데이터가 손실됩니다.
• Redis 데이터를 재사용하거나 시스템 장애를 방지하려면 다음을 수행해야합니다.
• Redis의 데이터는 디스크 공간, 즉 지속성에 기록됩니다.

지속성 분류 :

• RDB 방법 : 특정 시간에 Redis의 모든 데이터 사본을 얻기위한 스냅 샷 생성
• AOF 방법 : 실행 된 쓰기 명령을 파일 끝에 쓰고 데이터 변경 사항을 로그에 기록

3.2 RDB 지구력 화

3.2.1 개요

• Redis의 기본 지속성 방법이며 기본 파일 이름은 dump.rdb입니다.

3.2.2 트리거 조건

• 지정된 시간 간격에서 지정된 수의 쓰기 작업을 실행합니다 (구성 파일 제어).
• 저장 또는 bgsave (비동기) 명령 실행
• flushall 명령을 실행하여 데이터베이스의 모든 데이터를 지 웁니다.
• 종료 명령을 실행하여 데이터 손실없이 서버가 정상적으로 종료되도록합니다.

3.2.3 장점과 단점

• 대규모 데이터 복구에 적합
• 비즈니스에 높은 데이터 무결성과 일관성이 필요하지 않은 경우 RDB가 좋은 선택입니다.
• 데이터 무결성 및 일관성이 높지 않습니다.
• 백업 중 메모리 점유

3.2.4 RDB 파일을 통해 데이터 복구

• dump.rdb 파일을 redis 설치 디렉토리의 bin 디렉토리에 복사하고 redis 서비스를 다시 시작합니다.

[root@localhost ~]# vim /etc/redis/6379.conf

#RDB核心规则配置 save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘
中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的
数据快照写入磁盘。
若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释
#save ""
save 900 1					"这三项默认设置"
save 300 10
save 60 10000
dbfilename dump.rdb				//RDB文件名称
dir /var/lib/redis/6379			//RDB文件路径
rdbcompression yes				//是否进行压缩
 
#当RDB持久化出现错误后，是否依然进行继续进行工作，yes：不能进行工作，no：可以继续进行工作，可以通过info中的rdb_last_bgsave_status了解RDB持久化是否有错误
stop-writes-on-bgsave-error yes
 
#配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
rdbcompression yes
 
#是否校验rdb文件;从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC64的校验和。这跟有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗，所以如果你追求高性能，可以关闭该配置
rdbchecksum yes
 
#指定本地数据库文件名，一般采用默认的dump.rdb
dbfilename dump.rdb
 
#数据目录，数据库会写入这个目录。rdb、aof文件也会写在这个目录
dir /var/lib/redis/6379

3.3 AOF 지속성

• Redis는 기본적으로 켜져 있지 않습니다.

• RDB의 단점 (데이터 불일치)을 보완합니다.

• 로그를 사용하여 각 쓰기 작업을 기록하고 파일에 추가합니다.

• Redis restart는 로그 파일의 내용에 따라 앞에서 뒤로 쓰기 명령을 실행하여 데이터 복구 작업을 완료합니다.

• AOF는 기본적으로 설정되어 있지 않으며 수동으로 설정해야합니다. RDB는 기본적으로 설정되어 있습니다.

[root@localhost ~]# vim /etc/redis/6379.conf
 
'//Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。
appendonly no
 
appendfilename "appendonly.aof"		//指定本地数据库文件名，默认值为 appendonly.aof
  
#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快
	always表示每次写入都执行fsync，以保证数据同步到磁盘
	everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
# appendfsync always		'//always:数据要求高'
appendfsync everysec 	'//everysec:一般情况使用 '
# appendfsync no			

no-appendfsync-on-rewrite no
 
auto-aof-rewrite-percentage 100
 
'//设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写'
auto-aof-rewrite-min-size 64mb
 
aof-load-truncated yes
 
'//加载redis时，可以识别AOF文件以“redis”开头'
'//字符串并加载带前缀的RDB文件，然后继续加载AOF尾巴'
aof-use-rdb-preamble yes

자세한 구성 명령

• Redis가 다시 시작되면 로그 파일의 내용에 따라 쓰기 명령을 앞뒤로 실행하여 데이터 복구 작업을 완료합니다. 기본적으로 redis는 많은 애플리케이션에서 충분한 RDB 지속성 방법을 사용합니다. 그러나 중간에 redis가 충돌하면 몇 분 동안 데이터가 손실 될 수 있으며, 지속성을위한 저장 전략에 따르면 Append Only File은 더 나은 지속성 특성을 제공 할 수있는 또 다른 지속성 방법입니다. Redis는 수신 후 매번 기록 된 데이터를 appendonly.aof 파일에 쓰고, Redis는 처음 시작할 때마다이 파일의 데이터를 메모리에 먼저 읽고 RDB 파일을 먼저 무시합니다. rdb가 켜져 있으면 no를 yes로 변경합니다.

appendonly no

• AOF가 RDB 파일을 다시 쓰거나 쓸 때 많은 IO가 수행됩니다.이 때 Everysec 및 Always의 AOF 모드의 경우 fsync를 실행하면 너무 오래 차단되고 no-appendfsync-on-rewrite 필드가 발생합니다. 기본 설정으로 설정되어 있습니다. 애플리케이션에 높은 대기 시간이 필요한 경우이 필드를 yes로 설정할 수 있습니다. 그렇지 않으면 여전히 no로 설정하여 지속성 기능에 대해 더 안전한 선택입니다. yes로 설정하면 새 쓰기 작업이 다시 쓰기 중에 fsync되지 않고 일시적으로 메모리에 저장되고 다시 쓰기가 완료된 후에 기록됩니다. 기본값은 no, yes를 권장합니다. Linux의 기본 fsync 정책은 30 초입니다. 30 초의 데이터가 손실 될 수 있습니다.

no-appendfsync-on-rewrite no

• Aof는 자동으로 구성을 다시 작성합니다. 현재 AOF 파일 크기가 마지막으로 다시 쓴 AOF 파일 크기를 초과하면 다시 쓰기가 수행됩니다. 즉, AOF 파일이 일정 크기로 커지면 Redis는 bgrewriteaof를 호출하여 로그 파일을 다시 쓸 수 있습니다. 현재 AOF 파일 크기가 마지막 로그 다시 쓰기 (100으로 설정)에서 얻은 AOF 파일 크기의 두 배인 경우 새 로그 다시 쓰기 프로세스가 자동으로 시작됩니다.

auto-aof-rewrite-percentage 100

• aof 파일은 마지막에 불완전 할 수 있으며 redis가 시작되면 aof 파일의 데이터가 메모리에로드됩니다. 특히 ext4 파일 시스템에 data = order 옵션이 추가되지 않은 경우 redis가 다운 된 호스트 운영 체제 이후에 재시작이 발생할 수 있습니다 (redis 다운 또는 비정상 종료로 인해 불완전한 테일이 발생하지 않음).이 현상이 발생하면 선택할 수 있습니다. Redis가 종료되도록하거나 가능한 한 많은 데이터를 가져옵니다. 예를 선택하면 잘린 aof 파일을 가져올 때 로그가 자동으로 클라이언트에 게시 된 다음로드됩니다. 아니요 인 경우 사용자는 AOF 파일을 복구하기 위해 수동으로 redis-check-aof를 수행해야합니다.

aof-load-truncated yes