REDIS 的一些总结
1. Redis 的简介
1. 什么是Reids?
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、key-value数据库 。可用于缓存,事件发布或订阅,高速队列等场景。
redis 称为remote dictionary server(远程字典服务器)用C语言编写的,是当下热门的NoSql数据库(NoSQL = not only SQL,即非关系型数据库)。
redis默认有16个数据库,从0开始。可用 select 数据库号 来选择数据库,默认使用的0号数据库。
redis默认没有密码。
Redis通常被称为数据结构服务器,因为值(value)可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。
2.Redis 有什么特点?
high performance ,高并发高读写,动态页面展示与交互,比如微博点赞评论等操作,实时统计在线人数排行榜等
huge storage,海量数据的高效存储和访问,大型网站的用户登录系统
high scalability && high availability,高可扩展性和高可用性
3. 为什么使用Redis?
- Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。
- Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。
- Redis支持数据的备份,即master-slave模式的数据备份。
4.Redis 应用的场景
- 缓存
- 网站访问统计
- 任务队列
- 数据过期处理
- 应用排行榜
- 分布式集群架构中的session分离
5.守护进程
Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程
1 | daemonize no |
什么是守护进程?
守护进程(Daemon Process),也就是通常说的 Daemon 进程(精灵进程),是 Linux 中的后台服务进程。它是一个生存期较长的进程,通常独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件。
守护进程是个特殊的孤儿进程,这种进程脱离终端,为什么要脱离终端呢?之所以脱离于终端是为了避免进程被任何终端所产生的信息所打断,其在执行过程中的信息也不在任何终端上显示。由于在 linux 中,每一个系统与用户进行交流的界面称为终端,每一个从此终端开始运行的进程都会依附于这个终端,这个终端就称为这些进程的控制终端,当控制终端被关闭时,相应的进程都会自动关闭。
2. Redis 的安装
下载安装包tar,4.0是比较稳定的版本,有需要的可以下载最新的。。。
java1
wget http://download.redis.io/releases/redis-4.0.11.tar.gz
方便管理我都是把软件安装到/usr/local/ 目录下,当然看自己喜欢
java1
2
3
4
5
6
7[root@localhost app]# tar xzf redis-4.0.11.tar.gz
[root@localhost redis-4.0.6]# make
# 如果编译失败请先下载编译依赖,编译成功不需要执行以下命令
yum install wget make gcc tcl 下载安装gcc
rpm -qa|grep gcc 验证gcc是否安装成功
运行redis
java1
2
3
4
5
6
7
8
9
10
11
12进入到redis的 bin 目录
[root@localhost bin]# ./redis-server 运行redis
使用内置的客户端命令redis-cli进行使用:
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> get foo
"bar"
127.0.0.1:6379>修改redis的一些参数配置
java1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16vi /etc/redis.conf
#查找daemonize no改为 yes以守护进程方式运行 即以后台运行方式去启动
daemonize yes
#修改dir ./为绝对路径, 默认的话redis-server启动时会在当前目录生成或读取dump.rdb 所以如果在根目录# #下执行redis-server /etc/redis.conf的话
#, 读取的是根目录下的dump.rdb,为了使redis-server可在任意目录下执行 所以此处将dir改为绝对路径
dir /usr/local/redis-4.0.11/bin
#修改appendonly为yes
#指定是否在每次更新操作后进行日志记录, Redis在默认情况下是异步的把数据写入磁盘,
#如果不开启,可能会在断电时导致一段时间内的数据丢失。 因为 redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly yes
#redis 日志生成位置
logfile "/app/log/redis.log"1
2
3
4再次启动
[root@localhost bin]# ./redis-server redis.conf
[root@localhost bin]# ./redis-cli
3. JAVA 访问 Jedis
java连接jedis 需要的jar包
- jedis-2.1.0.jar
- commons-pool-1.6.jar
maven依赖下载
1 | <dependency> |
创建项目并测试
1 | public static void main(String[] args) { |
注:若出现连接失败异常请关闭linux防火墙
CentOS 7.0 版本以上的关于防火墙的命令
1 | 1、查看firewall服务状态 |
4. Redis 的一些基本命令
1 | set key value 赋值 |
1 | get key 取值 |
1 | select index 切换库(下标从0开始) |
1 | dbsize 查看当前库key的数据 |
1 | flushdb 清空当前库 |
1 | flushall 清空所有库 |
1 | keys * 查看所有key (keys后面参数可以用表达式代替) |
1 | exists key 判断一个键值是否存在(如果存在,返回整数类型 1 ,否则返回 0) |
1 | del key [key.....] 可以删除一个或多个键,返回值是删除的键的个数 |
1 | type key 返回值可能是 string(字符串类型) hash(散列类型) list(列表类型) set(集合类型) zset(有序集合类型) |
1 | move key db 当前库就没有了,被移除了 |
1 | expire key time(秒) 为给定的key设置过期时间 |
1 | ttl key 查看还有多少秒过期,-1表示永不过期,-2表示已过期 |
5. Redis 的持久化
持久化概念:将数据从断电易失的内存存放到能够永久存储的设备上。
RDB
RDB(Redis Database) 是 Redis 默认的持久化方案。它可以在指定的时间间隔内将内存中的数据集快照写入磁盘
,
也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里,在RDB方式下,你有两种选择:
1. 手动执行持久化数据命令
1. save 命令
1 | save 命令执行时只管保存,其他不管,全部阻塞,save操作在Redis主线程中工作,因此会阻塞其他请求操作,应该避免使用 |
2. bgsave 命令
1 | bgsave后台备份,在备份的同时可以处理输入的数据,bgSave则是调用Fork,产生子进程,父进程继续处理请求。子进程将数据写入临时文件,并在写完后,替换原有的.rdb文件。Fork发生时,父子进程内存共享,所以为了不影响子进程做数据快照,在这期间修改的数据,将会被复制一份,而不进共享内存。所以说,RDB所持久化的数据,是Fork发生时的数据。在这样的条件下进行持久化数据,如果因为某些情况宕机,则会丢失一段时间的数据。如果你的实际情况对数据丢失没那么敏感,丢失的也可以从传统数据库中获取或者说丢失部分也无所谓,那么你可以选择RDB持久化方式。 |
3. 区别
1 | save是同步命令, bgsave是异步命令,bgsave会从redis主进程fork出一个子进程专门用来生成rdb二进制文件 |
2. 根据配置文件的策略,达到策略的某些条件时自动持久化数据
触发RDB快照的条件
- 在指定的时间间隔内,执行指定次数的写操作。
- 执行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (异步)命令。
- 执行flushall 命令,清空数据库所有数据,意义不大。
- 执行shutdown 命令,保证服务器正常关闭且不丢失任何数据,意义也不大。
数据恢复
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。
优势
- 适合大规模的数据恢复
- 对数据完整性要求不高
劣势
- 在一定时间做一次备份,如果redis意外宕机的话就会丢失最后一次快照后的所有数据
- Fork的时候,内存中的数据被克隆了一份,在fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不响应客户端的请求
AOF
AOF(Append Only File) ,Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写操作,并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
1. 开启AOF
1 | # AOF和RDB的持久化是可以同时开启的 |
想要执行数据恢复,将备份文件 (appendonly.aof) 移动到 redis 安装目录并启动服务即可
2. 触发AOF快照
根据配置文件触发,可以是每次执行触发,可以是每秒触发,可以不同步。
- appendfsync always 每次有数据修改发生时都会写入AOF文件。
- appendfsync everysec 每秒钟同步一次,该策略为AOF的缺省策略。
- appendfsync no 从不同步。高效但是数据不会被持久化。
1 | # 每修改同步:同步持久化 每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好 |
3. AOF rewrite(重写机制)
由于该机制对日志文件的
写入操作采用的是append模式
,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操 作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据 一致性的问题AOF采用文件追加方式,新增了重写机制,如果日志过大,Redis可以
自动启用rewrite机制
。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创 建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
恢复数据的最小指令集
1 | bgrewriteaof |
AOP文件修复
1 | redis-check-aof --fix appendonly.aof |
4. RDB & AOF比较
优势
RDB:适合大规模的数据恢复。如果业务对数据完整性和一致性要求不高,RDB是很好的选择。
AOF:数据的完整性和一致性更高。
劣势
RDB:数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
AOF:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。
总结
Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。
Redis 针对 AOF文件大的问题,提供重写的瘦身机制。
若只打算用Redis 做缓存,可以关闭持久化。
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份,留一后手。AOF出问题了,还有RDB
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。
6. 主从复制
Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制
。在Redis中,用户可以通过执行SLAVEOF命令或者设置slaveof选项,让一个服务器去复制(replicate)另一个服务器,我们称呼被复制的服务器为主服务器(master),而对主服务器进行复制的服务器则被称为从服务器(slave)。通常用作读写分离,以及数据恢复
。
配置主从
在从库里使用slaveof命令,从库认主后,从库只能做读操作;
当主机挂求后,从机原地待命;
当从机挂求重启后,从机变主机;
当使用redis.conf认主,不使用命令配置认主。
1 | slaveof host port 认主 |
1 | info [section] 查看redis信息(带replication参数可直接看主从信息) |
1 | SLAVEOF no one 将从库转成主库,并保已有数据 |
哨兵模式
Redis的主从架构,如果master发现故障了,还得手动将slave切换成master继续服务,手动的方式容易造成失误,导致数据丢失,那Redis有没有一种机制可以在master和slave进行监控,并在master发送故障的时候,能自动将slave切换成master呢?有的,那就是哨兵。
1. 哨兵的作用
监控redis进行状态,包括master和slave
当master down机,能自动将slave切换成master
2. 配置哨兵
新建配置文件,命名为sentinel.conf,输入下面内容
1 | sentinel monitor mymaster 192.168.137.101 6379 1 |
mymaster :master服务的名称,随便定义
3. 启动哨兵
1 | redis-sentinel sentinel.conf |
有想法的小伙伴可以进入我的Github查看源码
** 在哪里跌倒,就在哪里趴下,休息一会儿你会发现新大陆的哦~ **