Redis 是完全开源免费的,基于C语言开发,遵守BSD协议,是一个高性能的key-value非关系型数据库(NoSql)。
参考:Redis教程
Redis 与其他 key - value 缓存产品有以下三个特点:
Redis支持Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作
set k1 1234567 #设置键值对,k1为键,1234567为值
get k1 #根据键k1查询对应的值
getrange k1 0 2 #查询k1对应的值,并获取值的从索引0开始到2位置的内容
mget k1 k2 k3 #批量查询键k1、k2、k3的值
incr k1 #将k1的内容自增1
incrby k1 2 #将k1的内容增加2
decr k1 #k1的内容自减1
decrby k1 2 #k1的内容减少2
Hash类型是一个string类型的field和value的映射表,hash特别适合用于存储对象。类似于一个对象对应的属性和属性值。
hmset zhangsan age 16 gender male address chengdu #设置键为zhangsan,内容有age、gender、address和对应的值
hmget zhangsan age gender #获取键为zhangsan的内容中age和gender对应的值
hgetall zhangsan #查询张三键中所有的内容
List是简单的字符串列表,按照插入顺序排序。你可以添加一个元素到列表的头部(左边)或者尾部(右边),可将list看作一个管道,即从管道的那一口添加和查询数据。
lpush list 1 2 3 4 5 #从列表左边依次添加1,2,3,4,5
lrange list 0 5 #从左边查询列表list的内容,由于是从左边读取,因此读取结果为5,4,3,2,1
lpop list #从左边弹出第一个元素,弹出5
rpush list 0 #从右边添加内容
rpop list #弹出列表右边第一个元素
Set 是 String 类型的无序集合。集合成员是唯一的,这就意味着集合中不能出现重复的数据。
sadd set zhangsan lisi wangwu zhangsan #将zhangsan、lisi、wangwu添加到set中,set存储内容无序,且不重复,因此只保留一个zhangsan
smembers set #查询set的内容,并且内容随机
spop set #随机弹出一个内容
SortedSet和Set一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zadd english 99 zhangsan 81 lisi 66 wangwu #在有序集合中添加english键,对应内容zhangsan、lisi、wangwu的成绩(score)分别为99,81,66
zcard english #返回有序集合成员数
zcount english 80 90 #查询成绩在80到90之间的数据(90>=score>=80)
zrank english zhangsan #返回zhangsan在english集合中的位置索引
zscore english zhangsan #返回english成员zhangsan对应的分数
zrange english 0 20 withscores #返回english中前20位的成员
zrevrange english 0 20 withscores #查看english中后20位的成员
在指定时间间隔内将内存中的数据(SnapShot)写入磁盘,恢复将快照读取到内存中。
Redis会单独创建(fork)一个子进程进行持久化,现将数据写入一个临时文件,待持久化过程结束,再用临时文件替换上次持久化好的文件。整个过程主进程不进行任何的IO操作,确保性能。RDB保存为dump.rdb文件。
Fork:Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。
快照时间配置:
save 900 1 #15分钟修改一次库
save 300 10 #5分钟修改十次库
save 60 10000 #1分钟修改10000次库
注:flushall会生成dump.rdb但是该文件存的是flushall之后的数据备份,无意义,需要恢复。
RDB是紧凑的文件,RDB在保存时父进程唯一需要做的就是fork一个子进程,接下来全部工作由子进程来做,父进程不需要任何IO操作,因此RDB持久化方式可以最大化redis性能。
RDB数据丢失风险大,RDB需要经常fork子进程来保存数据到硬盘,当数据集比较大的时候,fork进程耗时,导致redis在毫秒级不能响应客户端。
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件不能改写文件。Redis启动之初会读取该文件重新构建数据,即Redis重启的话会根据日志文件将写指令从前到后执行一次完成数据恢复。AOF文件保存形式:appendonly.aof
AOF配置
1.appendonly:默认no
2.appendfilename:aof文件名
3.Appendfsync:
Always:同步持久化,每次数据发生变更立即被记录到磁盘,性能较差但数据完整性好
Eversec:默认配置,异步执行每秒记录,若一秒down则数据丢失
No
4.No-appendfsync-on-rewrite:重写时是否可以运用Appendfsync,默认no
5.Auto-aof-rewrite-min-size:设置重写基准值
6.Auto-aof-rewrite-percentage:设置重写基准值
AOF采取文件追加方式,文件会越来越大,为了避免此情况新增重写机制,当AOF文件大小超过设定阈值,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof
Rewrite原理:AOF文件持续过大时,会fork出一条新进程来将文件重写,即先写临时文件最后再rename,遍历新进程中的内存数据,每条记录有一条set语句。重写AOF文件的操作,并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令方式从写一个新的aof文件。
触发机制:Redis记录上次重写时AOF的大小,默认配置是当AOF文件大小是上次rewirte后大小的一倍且文件大于64MB时出发
AOF是一个追加的日志文件,Redis在AOF体积变大时自动对AOF进行重写,AOF文件有序的保存路对数据库的写操作,这些写操作以redis协议形式保存,通俗易懂。
对于相同数据集,AOF文件体积大于RDB,并且AOF速度可能比RDB慢
AOF和RDB的选择:建议同时开启两种持久化方式,通常情况下redis会优先载入AOF恢复数据,
因为AOF通常比RDB更完整。建议只在slave上持久化RDB并且15分钟备份一次即可
redis事务:可以一次执行多个命令,本质是一组命令的集合,一个事物中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入加塞
事务作用:一个队列中,一次性、顺序性、排他性的执行一系列命令
补充:
事务特性(ACID)
原子性:事务要么全部成功,要么失败
一致性:事务执行前后数据库状态一致
隔离性:事务不影响另一个事务执行
持久性:事务对数据库的影响时永久的
在multi开启事务之后,如果在执行语句加入队列是报错(Error),执行exec后执行语句全体失败;
若在加入队列成功(ok),执行exec后发生错误,则队列中除报错语句外其他语句执行,即redis对事务部分支持。
WATCH指令类似乐观锁,事务提交时,如果key值已被别的客户端改变,比如某个list已被别的客户端push/pop,整个事务队列都不会被执行。
通过WATCH命令在事务执行之前监控了多个keys,倘若在WATCH之后有任何key的值发生变化,exec命令执行的事务都将被放弃,同时返回nill应答以通知调用者事务执行失败。
监视一个或多个key,如果事务执行前这些key被其他命令改动,那么事务被打断。取消对所有key的监视,一旦执行exec后加的所有监控锁都会被取消
进程间的一种消息通信模式,发布者(pub)发送消息,订阅者(sub)接收消息
命令:
主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slave机制,Master以写为主,Slave以读为主。
目的:读写分离和容灾恢复
只配从库不配主库,从库配置:slaveof 从库IP 从库端口
一个主节点两个从节点
上一个slave可以是下一个slave的master,slave同样可以接受其他slave的连接和同步请求,那么该slave作为链条中的下一个master,可以减轻master的写压力
缺点:中途变更转向会清楚之前的数据,重新建立拷贝
使当前数据库停止与其他数据库同步,变成master
主从复制原理:
1.Slave启动成功后连接到master会发送一个sync命令
2.master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令
3.在后台进程执行完毕之后,master将传送整个数据文件到slave,已完成一次完全同步
全量复制:slave服务在接收到数据库文件数据后,将其存盘并加载到内存中
增量复制:master继续将新的所有收集到的修改命令依次传给slave完成同步
注:主要重新连接master,一次完全同步(全量复制)就会被执行
能够从后台监控主机是否故障,如果故障能自动将slave变成master,即不用手动在控制台输入slaveof指定master。故障mater重新启动后将变成slave,原来的mater不变。
复制延时:由于所有的写操作都是先在master上操作,然后同步更新到slave上,所以master同步到slave机器上有一定的延迟,当系统很繁忙的时候延迟更加严重,slave机器数量增加也会加重该问题。