Redis 缓存数据库

ph033378

　　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>　　[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 文件时， 服务器执行以下操作: