Redis学习
本文最后更新于:3 年前
redis安装
- wget URL
- tar xzf packageName
- 在有makefile文件下make(可以通过make install prefix=/usr/local/redis自定义安装的位置)
redis文件含义
安装完redis后,它会产生一系列文件,对应的文件解释如下:
1 |
|
redis服务端
redis-server即为redis服务端,可以直接通过./redis-server启动,但这是前台启动。
后台启动则通过将守护进程daemonize设为yes,然后利用配置文件启动服务端即可。(./redis-server ./redis.conf)
更多的关于redis.conf的配置可以看:redis.conf配置
redis服务端默认端口为6379
redis客户端
redis数据结构
redis是key:value存储系统,所谓的redis数据结构其实指的是value的数据结构
strings 字符串
- set key value
- get key
lists 字符串列表
redis的list底层实现是链表
- lpush key value
- rpush key value
- lrange key start stop
sets 字符串集合
redis的set是无序集合,可以做集合能做的事情,如交并差等
- sadd key value
- smembers key
- sismember key value
- sunion key1 key2 […keyn]
sorted sets 字符串有序集合
redis中的有序集合是通过加入score这一字段来实现有序性的,且因为其命令以z开头,因此redis的有序集合称为zsets
- zadd key score value
- zrange key start stop [rev]
hashes 哈希
类似于bean,可以用一个key存储一系列的键值对信息
- hset key filed value […field value]
- hgetall key
- hget key field
redis持久化
redis的持久化有两种方式,分别是RDB(redis database)和AOF(append only file)
二者可同时使用,若redis重启,则优先采用AOF来进行数据恢复
持久化之RDB
RDB是指在不同时间点将redis存储的数据通过生成快照的方式存储在磁盘上;
RDB如何持久化:单独fork一个子进程来完成持久化这项工作,主进程不进行任何IO操作;子进程会先将数据写入到一个临时文件中,待持久化结束,会将这个临时文件替换上次持久化好的文件。
若是对数据完整性并不敏感,则可以用RDB来恢复数据。(因为RDB持久化是隔一段时间进行一次的,所以会丢失部分的数据)
持久化之AOF
AOF(Append Only File 只许追加不许改写)是将redis执行过的所有写指令记录下来
利用AOF来恢复数据的话,它会从前往后的将指令执行一遍
如何配置:redis.conf里有个appendonly将其改为yes即打开了AOF功能,若有写操作,则会被追加到AOF文件的末尾
插入内容(方便下文理解):
Linux的同步IO(sync、fsync、fdatasync)
之所以会出现以上那些个同步IO是因为:传统的unix系统的磁盘IO是通过缓冲来进行的,是通过在内核中设有对应的缓冲区高速缓存或页高速缓存来实现的。
当我们将数据写入文件时,内核将数据复制到缓冲区中,只有当缓冲区写满或内核需要重用缓冲区时,才会将里面的数据冲去输出队列,至队首才进行真正的IO,此即为延迟写
延迟写会带来:数据更新慢以至更新的数据丢失等的情况,因此有上面的同步方法的出现,用于:保证磁盘上的文件与缓冲区高速缓存中内容的一致性
- sync
将缓冲区中的内容冲到输出队列即返回,并不等待实际的写磁盘结束。
- fsync
将指定的文件描述符中处于缓冲区的内容冲到输出队列,且等待实际的写磁盘结束后才返回。
既影响文件的数据部分,又影响文件的属性部分(metadata(size、access_time、modify_time…))
两次IO(数据部分与属性部分置于不同磁盘块)
- fdatasync
与fsync类似,但只影响文件的数据部分,不影响属性部分
一次IO
插入完毕
默认的AOF持久化策略为每秒fsync一次。此时可以让redis保持良好的性能,在丢失数据时,最多也是最近1秒的数据
如果遇到一些特殊情况:追加时遇到磁盘满、inode满、断电等情况,可以通过redis-check-aof工具来进行日志修复
因为AOF采用追加方式,所以在不额外做处理的情况下,文件会越来越大,因此,redis提供了AOF文件重写(rewrite)机制,所谓的AOF重写机制指的是:AOF文件的大小超过阈值,redis会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集(如INCR 100次,不如INCRBY KEY 100)
如何重写呢:
1. redis fork 重写子进程,读取现有 AOF文件,将其指令进行分析压缩后写入到一个临时文件中;
2. 主进程则将新接收的写指令放入缓冲区中,也写入到原AOF文件中(避免重写遇断电,无法恢复);
3. 重写子进程重写完毕后,会给父进程发信号,父进程收到后会将缓冲区的写指令追加到新AOF文件中;
4. 追加完毕后,redis用新AOF文件替代旧的AOF文件。
RDB和AOF对比
RDB | AOF | |
---|---|---|
数据敏感性 | 较差 | 较好 |
数据恢复速度 | 较快 | 较慢 |
文件体积 | 较小 | 较大 |
redis主从
redis支持主从同步,也有一主多从、多级从结构
redis的主从同步是异步进行的
-
如何进行主从同步的呢:
-
从服务器发出SYNC给主服务器,主服务器接收后,调用BGSAVE来创建子进程进行数据持久化工作(即将数据写入RDB文件中);
-
在持久化工作完成前,主服务器的写指令缓存在内存中;
-
BGSAVE完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器会将其存到磁盘上,然后读到内存中。之后主服务器会将期间缓存的写指令以redis协议的格式发给从服务器。
-
-
如果有多个从服务器发送SYNC指令呢?
那也只会执行一次BGSAVE,只需把持久化好的RDB文件发给多个下游就好
-
主从同步分为:
-
全量同步(即上面所介绍的“如何进行主从同步的呢”,初次连接都是全量同步)
-
增量同步(Redis 2.8 之后有)
增量同步指的是:主服务器每执行一个写指令时会向从服务器发送相同的写指令,从服务器接收并执行对应的写指令。
增量同步如何进行?
未写待续…
-
-
Redis主从同步策略
主从刚刚连接的时候,进行全量同步;全量同步结束后,进行增量同步。
当然,如果有需要,slave 在任何时候都可以发起全量同步。
redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
redis事务处理
在redis中,与事务处理相关的指令有以下四个:
-
multi
用于组装事务
-
exec
用于执行事务
-
discard
用于取消事务
-
watch
用于监视key(可多个),当被监视的key在multi之前有改变时,无论事务的内容是否关于该key,都会返回nil;若是被监视的key没有改变,则正常执行
在使用事务时可能遇到的错误:
-
执行前的错误
即语法错误或内存错误导致,在编写事务的某一条指令后会报错(exec前),之后调用exec指令时,会拒绝执行该事务(2.6.5版本之后)
-
执行后的错误
即应用层的错误,如sadd myset “a”;lpush myset “b”;可看出,myset于这两条指令中被使用了不同数据结构的指令。redis在执行此条事务时不会理睬这些错误,而是继续向下执行其他指令(不会影响其他指令的执行,也不会影响该条指令入列),事务最终可以被执行
redis配置
redis的配置文件为:redis.conf(Linux下),其支持在主配置文件中引入外部的配置文件,如:
include /home/ayy/...
redis配置文件被划分为如下几部分:
-
general
-
snapshotting
-
replication
-
security
-
limits
-
append only mode
-
lua scripting
-
slow log
-
event notification
-
gopher server
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!