A, 레디 스 소개
레디 스 완전히 무료 오픈 소스, BSD이 본 계약을 준수, 높은 성능입니다 키 - 값 데이터베이스.
레디 스 및 기타 키 - 값 캐싱 제품은 다음과 같은 세 가지 특성이있다 :
당신 재사용 할 수있을 때 1.Redis 지원 데이터 지속성, 메모리의 데이터가 디스크, 부하에 재부팅에 저장할 수 있습니다.
또한 저장리스트 세트 ZSET 해시 및 다른 데이터 구조를 제공하는 동시에 2.Redis은 간단한 키 값 데이터 유형을 지원한다.
백업 데이터, 즉, 데이터 백업 마스터 - 슬레이브 모드 지원 3.Redis.
두, 레디 스 사용 배경
우리의 일상 자바 웹 개발에서, 모든 인해 일반 시스템 작업에 데이터를 저장하는 데이터베이스를 사용하는 일반적이 아무 문제 없을 것 같다, 그래서 높은 동시성의 경우에 존재하지만, 많은 양의 데이터에 관해서하지 않습니다 같은 때문에 디스크에 직면 문제의 저장소 시스템 데이터에 더 큰, 일회용 데이터베이스, 디스크 / 속도가 상대적으로 느린 쓰기 및 성능에 심각한 단점을 읽을 때, 또는 가정 방문 순간 장면을 사는 등 일부 상품에 대한 수요, 인스턴트 요청 수천에서 온다, 매우 짧은 시간에 읽기 / 쓰기 작업의 완료 수천에 필요한 시스템, 더 자주 데이터베이스를 견딜 수 없습니다보다 이번에는 데이터베이스 시스템은 결국 서비스 댕을 선도 원인 마비에 매우 쉽게 심각한 생산 문제 기계.
이러한 문제점을 극복하기 위해, 자바 웹 프로젝트는 종종 소개 되는 NoSQL 메모리 기반 데이터베이스입니다 기술을, 일부 지속성 기능을 제공합니다.
레디 스 및 MongoDB를은 현재 가장 널리 사용되는 NoSQL이며, 기술 레디 스, 성능이 우수 지원할 수 당 수십만 초 읽기 / 쓰기 작업의 성능은 지금까지 데이터베이스를 초과하고, 또한 분산 된 클러스터를 지원합니다 스타일, 마스터 - 슬레이브 동기화 구성은 더욱 안심이도 있다는 것입니다, 더 많은 데이터가 메모리에 저장되도록 원칙적으로 무제한 확장 할 수 있습니다 특정 거래의 기능을 지원 높은 동시성 및 데이터에 따라 현장의 안전을 보장 일관성.
세, 레디 스의 장점
1. 매우 높은 성능 - 레디 스 최대한 빨리 110,000 배 / S를 읽을 수는, 쓰기 속도는 S / 81000 번이다.
2. 리치 데이터 유형 레디 스 이진 경우 문자열,리스트, 해시, 세트 및 순서 집합 연산의 데이터 유형을 지원합니다 -.
3. 원자 - 레디 스에게 모든 작업은 원자이고, 원자 레디 스도 전체의 여러 작업 후 구현을 지원합니다.
4. 다양한 기능 - 특성에 대한 레디 스도 지원하는 공개 / 등록, 신고, 키 만료 등.
네, 레디 스 NoSQL에 저장 및 기타 다른
1.Redis가 갖는 더 복잡한 데이터 구조 와 그 동작에 원자 제공 다른 데이터베이스 진화 경로와 다르다. 한편 레디 스 데이터 형식은 추가 추상화 없이도 프로그래머 투명 기본적인 데이터 구조에 기초한다.
2.Redis 메모리에서 실행하지만, 디스크 유지 될 수 절충 고속 메모리시의 판독 및 데이터의 하드웨어 메모리의 양보다 더 클 수 있기 때문에 서로 다른 데이터 세트를 작성하므로. 당신이 내부 레디 스 매우 복잡한 문제를 많이 할 수 있도록 메모리 데이터베이스의 또 다른 장점은, 같은 복잡한 데이터 구조에 비해, 디스크에 매우 간단한 메모리에서 작동합니다. 그들은 랜덤 액세스를 필요로하지 않기 때문에 한편, 컴팩트 디스크 형식의 측면에서, 또 다른 방법을 생성합니다.
JavaWeb에서 레디 스의 V. 신청
자바 웹에서 레디 스 두 가지 시나리오가 있습니다 :
1. 캐싱 - 저장 자주 사용되는 데이터,
2. 고속 읽기 / 쓰기 -이 빠른 읽기 / 쓰기 사용;
1. 캐시
데이터베이스에 매일 접속에 쓰기 작업에 대한 읽기 작업의 수까지 약 1의 비율 이상 : 9-3 : 가능성이 가능성이 있으므로 7 훨씬의 쓰기보다 읽을 수 있습니다. 우리가 읽고 데이터베이스에 쓸 수있는 SQL 문을 사용하는 경우, 데이터베이스는 상대적으로 느린 과정이다 인덱스에 대응하는 데이터를 다시 얻을 수있는 디스크로 이동합니다.
우리가 메모리에 직접 배치되어 레디 스의 데이터를 넣어 경우, 메모리 읽고 신속하게보다 디스크의 쓰기 속도 있기 때문에 읽을 수 및 쓰기 속도가 매우 빠르고 속도 때문에 직접 서버가 메모리에 데이터를 읽을 수 있습니다 많은 압력은 크게 데이터베이스를 줄일 수 있지만, 제한된 비용으로, 일반적으로 우리가 바로 그러한 사용자 로그인 정보와 같은 몇 가지 일반적인 주요 레디 스 데이터 저장소를 사용하기 때문에 데이터 저장을위한 메모리의 사용은 오버 헤드가 상대적으로 크다.
: 레디 스 스토리지를 사용하는 경우 일반적으로, 우리는 다음과 같은 측면 고려할 필요가있다
1. 비즈니스 데이터가 사용을? 어떻게 안타? 적중률이 매우 낮은 경우, 쓰기 캐싱 할 필요가 없다
다중 작업 비즈니스 데이터를 읽을 2. 또는 쓰기 작업을 더? 쓰기 작업과 더 자주 필요가 데이터베이스에 기록 할 경우, 사용 캐싱 할 필요가 없습니다
3. 비즈니스 데이터의 크기를 수행하는 방법? 당신이 파일의 메가 바이트의 저장 수백하려면 캐시는, 많은 압력을 가져올 것이다 그래서 필요가 없습니다,
당신은 캐시를 사용할 필요성을 느끼는 경우에 이러한 문제를 고려한 후에, 그것을 사용!
아래와 같이 논리 레지스터를 읽을 레디 스 사용 :
우리는 다음 두 가지 사항을 알 수있는 그래프에서 :
첫 번째 데이터 읽기, 레디 스 실패 읽기 데이터를, 다음 프로그램이 데이터베이스가 트리거 읽을 때, 데이터를 읽어와 레디 스로 작성,
두 번째 이후 필요가 읽을 때 데이터는 직접적, 레디 스를 읽 속도가 크게 향상되어 있으므로, 처리의 종료 후에 데이터를 판독.
위의 분석이 알 수에서 읽기 동작의 가능성보다 훨씬 더는 쓰기 작업은 데이터베이스에 대한 의존도를 줄이고, 자주 속도 증가를 읽으려면 레디 스의 필요성을 사용하여 루틴을 처리하는 데이터가 해당 데이터베이스, 그래서, 명백 할 것이다 압력은 크게 감소된다.
논리적 분석,의는 프로세스 쓰기 살펴 보자 읽
으로 프로세스, 갱신 또는 쓰기 동작에서 볼 수, 작업이 여러 레디 스 필요한 실제 응용 시나리오 경우, 비즈니스 데이터 읽기 쓰기의 수보다 훨씬 큰 횟수는 레디 스를 사용할 필요가 없다.
2. 고속 읽기 / 쓰기 응용 프로그램을
오늘날의 인터넷 상황은 Lynx와 배 (11) 높은 동시성, 전력 시스템 사업 현장 스파이크 제품에 대한 가장 일반적인 방법은, 점점 더 많은 존재는 이러한 경우는, 등 리 콘서트 티켓을 잡아입니다 처리를 위해 데이터베이스의 단순한 사용, 서비스 댕, 붕괴 데이터베이스에 마비하면서, 사용자의 가난한 사용자 경험 손실의 원인에 이르기까지 매우 느려질 수없는 경우 경우 수천 즉시 요청에있다가 서버에 도착 기계,하지만 그런 경우는 허용되지 않습니다!
: 우리는 기회의 이러한 높은 동시성 요구 사항을 처리 할 레디 스를 사용할 필요가 그래서, 우리는 순서도 요청에 대해 살펴
우리는 더이 과정을 설명 :
요청이 레디 스 리더에 수행 서버 만 서비스 데이터 (재고 제품 스파이크)에 도착하면, 아무런 조작을하지 않으면 데이터베이스가 너무 크게 고속 응답의 요구를 충족하기 위해, 읽기, 쓰기의 속도를 향상시킬 수 있습니다;
하지만 캐시 된 데이터는 여전히 읽기 작업이 완료 레디 스 요청 / 쓰기 나중에 그래서, 그것은 고속 / 쓰기 작업이 종료 판사 것입니다 일반적으로 스파이크를 읽을 수 있는지 여부를 확인하기 위해 갈 것입니다, 데이터베이스에 저장된 지속성을, 필요 주식은 제로, 설정되지 않은 경우 0시 설립, 그것은 데이터베이스를 작동하지 않습니다 빨간 봉투의 양입니다 true의 경우, 트리거 이벤트는 따라서 지속적인 작업을 완료 한 시간의 배치의 형태로 데이터베이스에 레디 스 데이터를 캐시됩니다 .
여섯, 레디 스 설치
설치에서 1.Window
다운로드 : https://github.com/MSOpenTech/redis/releases
레디 스는 32 비트 및 64 비트를 지원한다. 시스템 플랫폼 선택의 실제 상황, C 드라이브에 여기에 우리 Redis-x64-xxx.zip 다운로드 아카이브에 따라이 폴더에 압축을 풉니 다 레디 스의 이름을 변경 .
다음과 같이 폴더를 엽니
열고 cmd를 창을 C로 디렉토리를 변경하려면 cd 명령을 사용하여 : \ 실행 레디 스 :
redis-server.exe redis.windows.conf
如果想方便的话，可以把 redis 的路径加到系统的环境变量里，这样就省得再输路径了，后面的那个 redis.windows.conf 可以省略，如果省略，会启用默认的。输入之后，会显示如下界面：
上图的提示信息告诉了我们：① Redis 当前的版本为 3.0.100/位数为64 位；② Redis 运行在 6379 端口；③ Redis 进程的 PID 为 15292；
至此，Redis服务端就启动完成了。接下来进行Redis客户端的启动。
Redis目录下有一个redis-cli.exe 文件，这是 Redis 自带的一个客户端工具，它可以用来连接到我们当前的 Redis 服务器。
启动客户端需要另启一个 cmd 窗口，原来的服务端窗口不要关闭，不然就无法访问服务端了。
切换到 redis 目录下运行:
redis-cli.exe -h 127.0.0.1 -p 6379
设置键值对:
set myKey abc
取出键值对:
get myKey
至此，我们便在 Windows 的环境下安装好了 Redis。
2.Linux环境下安装
下载地址： http://redis.io/download，下载最新稳定版本。
本教程使用的最新文档版本为 2.8.17，下载并安装：
$ wget http://download.redis.io/releases/redis-2.8.17.tar.gz
$ tar xzf redis-2.8.17.tar.gz
$ cd redis-2.8.17
$ make
make完后 redis-2.8.17目录下会出现编译后的redis服务程序redis-server,还有用于测试的客户端程序redis-cli，两个程序位于安装目录 src 目录下：
下面启动redis服务.
$ cd src
$ ./redis-server
注意这种方式启动redis 使用的是默认配置。 也可以通过启动参数告诉redis使用指定配置文件使用下面命令启动。
$ cd src
$ ./redis-server ../redis.conf
redis.conf 是一个默认的配置文件。我们可以根据需要使用自己的配置文件。
启动redis服务进程后，就可以使用测试客户端程序redis-cli和redis服务交互了。 比如：
$ cd src
$ ./redis-cli
redis> set foo bar
OK
redis> get foo
"bar"
七、Redis 配置
Redis 的配置文件位于 Redis 安装目录下，文件名为 redis.conf(Windows 名为 redis.windows.conf)。
你可以通过 CONFIG 命令查看或设置配置项。
语法
Redis CONFIG 命令格式如下：
redis 127.0.0.1:6379> CONFIG GET CONFIG_SETTING_NAME
实例
redis 127.0.0.1:6379> CONFIG GET loglevel
1) "loglevel"
2) "notice"
使用 * 号获取所有配置项：
实例
redis 127.0.0.1:6379> CONFIG GET *
"dbfilename"
"dump.rdb"
"requirepass"
""
"masterauth"
""
"unixsocket"
""
"logfile"
""
"pidfile"
"/var/run/redis.pid"
"maxmemory"
"0"
"maxmemory-samples"
"3"
"timeout"
"0"
"tcp-keepalive"
"0"
"auto-aof-rewrite-percentage"
"100"
"auto-aof-rewrite-min-size"
"67108864"
"hash-max-ziplist-entries"
"512"
"hash-max-ziplist-value"
"64"
"list-max-ziplist-entries"
"512"
"list-max-ziplist-value"
"64"
"set-max-intset-entries"
"512"
"zset-max-ziplist-entries"
"128"
"zset-max-ziplist-value"
"64"
"hll-sparse-max-bytes"
"3000"
"lua-time-limit"
"5000"
"slowlog-log-slower-than"
"10000"
"latency-monitor-threshold"
"0"
"slowlog-max-len"
"128"
"port"
"6379"
"tcp-backlog"
"511"
"databases"
"16"
"repl-ping-slave-period"
"10"
"repl-timeout"
"60"
"repl-backlog-size"
"1048576"
"repl-backlog-ttl"
"3600"
"maxclients"
"4064"
"watchdog-period"
"0"
"slave-priority"
"100"
"min-slaves-to-write"
"0"
"min-slaves-max-lag"
"10"
"hz"
"10"
"no-appendfsync-on-rewrite"
"no"
"slave-serve-stale-data"
"yes"
"slave-read-only"
"yes"
"stop-writes-on-bgsave-error"
"yes"
"daemonize"
"no"
"rdbcompression"
"yes"
"rdbchecksum"
"yes"
"activerehashing"
"yes"
"repl-disable-tcp-nodelay"
"no"
"aof-rewrite-incremental-fsync"
"yes"
"appendonly"
"no"
"dir"
"/home/deepak/Downloads/redis-2.8.13/src"
"maxmemory-policy"
"volatile-lru"
"appendfsync"
"everysec"
"save"
"3600 1 300 100 60 10000"
"loglevel"
"notice"
"client-output-buffer-limit"
"normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
"unixsocketperm"
"0"
"slaveof"
""
"notify-keyspace-events"
""
"bind"
""
编辑配置
你可以通过修改 redis.conf 文件或使用 CONFIG set 命令来修改配置。
语法
CONFIG SET 命令基本语法：
redis 127.0.0.1:6379> CONFIG SET CONFIG_SETTING_NAME NEW_CONFIG_VALUE
实例
redis 127.0.0.1:6379> CONFIG SET loglevel "notice"
OK
redis 127.0.0.1:6379> CONFIG GET loglevel
"loglevel"
"notice"
Redis配置具体参数说明：https://www.cnblogs.com/jianmingyuan/p/11089406.html
Redis持久化配置
redis有两种持久化方式：RDB和AOF。
具体差别跟优缺点可参考redis数据的两种持久化方式对比
RDB配置方式
默认情况下，是快照RDB的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb
redis.conf默认配置：
save 900 1
save 300 10
save 60 10000
配置含义：
900秒内，如果超过1个key被修改，则发起快照保存
300秒内，如果超过10个key被修改，则发起快照保存
60秒内，如果1万个key被修改，则发起快照保存
默认配置不方便看效果，可将快照频率设大一点，在redis.conf中增加一行：
save 10 1
保存后，启动redis服务端和客户端。在客户端输入命令：
输入完，发现dump.rdb文件的修改日期变了，并且redis服务端增加了保存日志：
接下来，重启redis服务端和客户端，看数据是否真的持久化了：
取到对应key的value值与之前设置的相同，说明使用RDB快照持久化成功了。
AOF 配置方式
redis.conf默认配置：
appendonly no
配置文件中的appendonly修改为yes，开启AOF持久化。 开启后，启动redis服务端，发现多了一个appendonly.aof文件
使用AOF做持久化，每一个命令以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写，使得 AOF文件的体积不会超出保存数据集状态所需的实际大小。实际上，AOF持久化并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失。
appendfsync always
appendfsync everysec
appendfsync no
配置含义：
always: 每次操作都会立即写入aof文件中
everysec: 每秒持久化一次(默认配置)
no: 不主动进行同步操作，默认30s一次
当然always一定是效率最低的，个人认为everysec就够用了，数据安全性能又高。Redis也允许我们同时使用两种方式，再重启redis后会从AOF中恢复数据，因为AOF比RDB数据损失小。
일단 구성되면, 명령을 입력 레디 스 클라이언트를 시작 :
최종 flushall가 모든 키를 취소하는 것입니다. Appendonly.aof 파일을 열고, 당신은 볼 수 있습니다
(명령은 레디 스 계약에 따라 증가 될 수있다) 최후 flushall을 제거, 데이터 지속성 정말 있는지 확인하기 위해 클라이언트와 서버를 다시 시작합니다
값 이전에 설정 한 값에 도착 마찬가지로, 지속성 AOF 지침은 성공이다.
요약 : 영구 모드의 두 종류하는 RDB 모델 지속성이 만족 될 때, 데이터는 디스크에 저장된 주파수를 지정 AOF 및 디스크 캐시에 저장된 각각의 동작 모드를 명령 한 다음 구성 부품 appendfsync 디스크 캐시 동기화의 모음은 디스크 스토리지에 명령 빈도를 지정합니다. 상대적으로 말하기, 볼륨이 손실 된 데이터 복구 적은 RDB AOF 파일보다 커야 만합니다.
당신이 FLUSHALL 명령의주의 구현하지 않는 경우,하지만 한 AOF 파일이 덮어되지 않았기 때문에, 너무 오래 서버가 중지되고 모든 쓰기 작업이 데이터베이스에서 수행 질서있는 방식으로 파일을 저장 AOF 때문에, 쓰기 작업은 형식 레디 스 프로토콜을 저장합니다 파일의 FLUSHALL 명령 AOF 끝을 제거하고, 레디 스를 다시 시작, 당신은 FLUSHALL 실행 전 상태로 데이터 세트를 복원 할 수 있습니다.
참고 링크 :
