Redis 缓存数据库

第1章 Redis简介:

redis是使用C语言编写的开源的,支持网络,基于内存,可持久性的键值对存储数据库,2013年5月之前,Redis是最流行的键值对存储数据库

Redis采用内存数据集,支持多种数据类型

官方网站：https://redis.io

官方各版本下载地址：http://download.redis.io/releases/

Redis 中文命令参考：http://redisdoc.com

中文网站1：http://redis.cn

中文网站2：http://www.redis.net.cn

1.1 Redis特性:

1.      高速读写,数据类型丰富

2.      支持持久化,多种内存分配及回收策略

3.      支持弱事务,消息队列,发布订阅

4.      支持高可用,支持分布式分片集群

1.2 企业缓存数据库解决方案对比:

memcached:

1.      优点 : 高性能读写,单一数据类型,支持客户端式分布式集群,一致性hash多核结构,多线程读写性能高

2.      缺点 : 无持久化,节点故障可能出现缓存穿透,分布式需要客户端实现,跨房数据同步困难,架构扩容复杂

Redis:

1.      优点 : 高性能读写,多数据类型支持,数据持久化,高可用架构,支持定义虚拟内存,支持分布式分片集群,单线程读写性能极高

2.      缺点 : 多线程读写比memcached慢

Tair:

1.      优点 : 高性能读写,支持三种存储引擎(ddb;rdb;ldb)支持高可用,支持分布式分片集群,支撑了几乎所有淘宝业务的缓存

2.      缺点 : 单机情况下,读写性能较其他两种产品较慢

1.1 Redis应用场景:

数据高速缓存,web会话缓存

排行榜应用

消息队列,发布订阅

第1章 Redis安装部署:

1.1 环境说明:

[root@gitlab ~]# cat /etc/redhat-release

CentOS Linux release 7.2.1511 (Core)

[root@gitlab ~]# uname -r

3.10.0-327.el7.x86_64

[root@gitlab ~]# getenforce

Disabled

[root@gitlab ~]# systemctl status firewalld.service

● firewalld.service - firewalld - dynamic firewall daemon

Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)

Active: inactive (dead)

1.2 下载地址:

wget http://download.redis.io/releases/redis-3.2.10.tar.gz

1.3 安装redis:

[root@gitlab application]# tar xzf  redis-3.2.10.tar.gz

[root@gitlab application]# ll

total 1520

drwxrwxr-x 6 root root    4096 Jul 28  2017 redis-3.2.10

-rw-r--r-- 1 root root 1550261 Jul 29  2017 redis-3.2.10.tar.gz

[root@gitlab application]# mv redis-3.2.10 redis

[root@gitlab application]# mv redis-3.2.10.tar.gz /server/tools/

[root@gitlab application]# ll

total 4

drwxrwxr-x 6 root root 4096 Jul 28  2017 redis

[root@gitlab application]# cd redis/

[root@gitlab redis]# make

至此安装完成

1.4 启动第一个Redis实例

[root@gitlab redis]# cd src/

[root@gitlab src]# ./redis-server &

第2章 Redis操作

2.1 Redis配置文件:

[root@gitlab src]# mkdir -p /data/6379

[root@gitlab src]# vim /etc/redis.conf

daemonize yes

port 6379

logfile /data/6379/redis.log

dbfilename dump.rdb

dir /data/6379

protected-mode no       保护模式,是否开启本地访问

bind 10.0.0.63          指定redis监听地址,可以通过这个地址进行网络连接到数据库

2.1.1 在查询配置:

10.0.0.63:6379> CONFIG GET *

1) "dbfilename"

2) "dump.rdb"

2.1.2 在线修改配置:

10.0.0.63:6379> CONFIG SET requirepass 123

OK

10.0.0.63:6379> CONFIG GET requirepass

(error) NOAUTH Authentication required.

10.0.0.63:6379> auth

(error) ERR wrong number of arguments for 'auth' command

10.0.0.63:6379> auth 123

OK

10.0.0.63:6379> CONFIG GET requirepass

1) "requirepass"

2) "123"

10.0.0.63:6379>

第3章 Redis数据持久化

3.1 什么是持久化?

缓存数据库在宕机或者重启后,还可以重新构造内存中的数据,持久保持数据

3.2 持久化的种类:

RDB持久化:

基于快照的持久化功能,保存一个时刻的数据状态,企业中常用的持久化功能,一般还可以以用作备份

AOF持久化:

只追加日志模式,会将redis一段时间内的所有修改命令记录下来,属于比较安全的一种持久化方式

3.3 RDB持久化的优缺点:

3.3.1 优点:

1.      RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集,这种文件非常适用于进行备份,比如说你可以在最近的24小时内,每小时备份一次RDB文件,并且在每个月的每一天,也备份一个RDB文件,这样,即使遇到问题,也可以随时将数据集还原到不同的版本

2.      RDB非常适用于灾难恢复:它只有一个文件,并且内容都非常紧凑,可以将它传送到别的数据中心

3.      RDB可以最大化Redis的性能,父进程在保存RDB文件时唯一要做的就是fork出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘IO操作

4.      RDB在恢复大数据集时的速度比AOF快

3.3.2 缺点:

1.      如果你需要尽量避免在服务器故障时丢失数据,那么RDB不适用,因为RDB文件需要保存整个数据集的状态,所以这并不是一个轻松的操作,因此你可能至少5分钟才保存一次文件,在这种情况下,一旦发生故障,你就可能会丢失几分钟的数据

2.      每次保存RDB的时候,Redis都要fork出一个子进程,并由子进程来进行实际的持久化工作,在数据集比较庞大时,fork可能会非常耗时,造成服务器在某某毫秒内停止处理客户端,如果数据集非常庞大,并且CPU时间非常紧张的话,那么这种停止时间可能会长达整整一秒,虽然AOF重写也需要进行fork,但无论AOF重写的执行间隔有多长,数据的耐久性都不会有任何损失

3.4 AOF持久化的优缺点:

优点:

1.      使用AOF会让你的Redis更加耐久,你可以使用不同的fsync策略,无fsync,每秒fsync,每次写的时候fsync,使用默认的每秒fsync策略,Redis的性能依然很好,fsync是由后台线程进行处理的,主线程会尽力处理客户端请求,一旦出现故障,你最多丢失1秒的数据

2.      Redis可以在AOF文件体积变的过大时,自动的在后台对AOF进行重写,重写后的AOF文件包含了恢复当前数据集所需的最小命令集合,整个重写操作是绝对安全的,因为Redis在创建AOF文件的过程中,会继续将命令追加到现有的AOF文件里面,即使重写过程中发生宕机,现有的AOF文件也不会丢失

3.      一旦新AOF文件创建完毕,Redis就会从旧AOF文件切换到新的AOF文件,并开始对AOF文件进行追加操作

4.      AOF文件有序的保存了对数据库执行的所有写操作,这些写入操作以Redis协议的格式保存,因此AOF文件的内容非常同意被人读懂,对文件进行分析,也很轻松,导出AOF文件也非常简单,举个例子,如果你不小心执行了flush all命令,但只要AOF文件未被重写,那么只要停止服务器,移除AOF文件末尾的flush all命令,并重启Redis,就可以将数据集恢复到flushall执行之前的状态

缺点:

1.      对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积,根据所使用的fsync策略,AOF的速度可能会慢于RDB

2.      在一般情况下,每秒fsync的性能依然非常高,而关闭fsync可以让AOF的速度和RDB一样快,即使在高负荷之下也是如此,不顾在处理巨大的写入载入时,RDB可以提供更有保证的最大延迟时间

3.      AOF在过去曾经发生过这样的bug,因为个别命令的原因,导致AOF文件在重新载入时,无法将数据集恢复成保存时的原样

3.5 如何选择使用哪种持久化方式?

Ø  一般来说,如果想要达到很高的数据安全性,应该同时使用两种持久化功能

Ø  如果你非常关心数据的安全,并且可以承受数分钟内的数据丢失,建议使用RDB

Ø  有很多用户只使用AOF,但是这种方式并不推荐,因为定时生成的RDB快照非常便于数据库进行备份,并且RDB恢复数据的速度要比AOF快很多,而且还有AOF的bug问题

3.6 RDB快照实现持久化:

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。

你也可以通过调用 SAVE或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。

比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集: save 60 1000

这种持久化方式被称为快照 snapshotting.

3.6.1 当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作: