Redis基础教程

 

strings

strings是redis的基础类型,例子如下:

set mystr "hello world!" //设置字符串类型
get mystr //读取字符串类型

字符串类型的用法就是这么简单,因为是二进制安全的,所以你完全可以把一个图片文件的内容作为字符串来存储。

另外,我们还可以通过字符串类型进行数值操作:

127.0.0.1:6379> set mynum "2"
OK
127.0.0.1:6379> get mynum
"2"
127.0.0.1:6379> incr mynum
(integer) 3
127.0.0.1:6379> get mynum
"3"

在遇到数值操作时,redis会将字符串类型转换成数值

由于INCR等指令本身就具有原子操作的特性,所以我们完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令来实现原子计数的效果,假如,在某种场景下有3个客户端同时读取了mynum的值(值为2),然后对其同时进行了加1的操作,那么,最后mynum的值一定是5。不少网站都利用redis的这个特性来实现业务上的统计计数需求。

一 redis数据类型
redis支持5种类型的数据类型,它描述如下的:

  • 字符串(strings)
  • 字符串列表(lists)
  • 字符串集合(sets)
  • 有序字符串集合(sorted sets)
  • 哈希(hashes)
    key则是字符串类型,其中key一般以如下方式命名,用于保存尽可能多的信息。例如user:10000:passwd

  例子:

主从同步原理

从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中Redis基础教程。。在数据持久化期间,主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上,然后再将其读取到内存中。这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器

另外,要说的一点是,即使有多个从服务器同时发来SYNC指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前,如果从服务器与主服务器因某些原因断开连接的话,都会进行一次主从之间的全量的数据同步;而在2.8版本之后,redis支持了效率更高的增量同步策略,这大大降低了连接断开的恢复成本

主服务器会在内存中维护一个缓冲区,缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后,从服务器会尝试再次与主服务器连接,一旦连接成功,从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置(replication
offset)”发送出去。主服务器接收到这样的同步请求后,首先会验证主服务器ID是否和自己的ID匹配,其次会检查“请求的偏移位置”是否存在于自己的缓冲区中,如果两者都满足的话,主服务器就会向从服务器发送增量内容。

增量同步功能,需要服务器端支持全新的PSYNC指令。这个指令,只有在redis-2.8之后才具有。

redis> MULTI //标记事务开始 OKredis> INCR user_id //多条命令按顺序入队QUEUEDredis> INCR user_idQUEUEDredis> INCR user_idQUEUEDredis> PINGQUEUEDredis> EXEC //执行1) (integer) 12) (integer) 23) (integer) 34) PONG
AOF 后台重写

上一节展示的 AOF 重写程序可以很好地完成创建一个新 AOF 文件的任务,
但是, 在执行这个程序的时候, 调用者线程会被阻塞。
很明显, 作为一种辅佐性的维护手段, Redis 不希望 AOF
重写造成服务器无法处理请求, 所以 Redis 决定将 AOF
重写程序放到(后台)子进程里执行
。不过,
使用子进程也有一个问题需要解决: 因为子进程在进行 AOF 重写期间,
主进程还需要继续处理命令, 而新的命令可能对现有的数据进行修改,
这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致

www.9778.com,为了解决这个问题, Redis 增加了一个AOF 重写缓存, 这个缓存在 fork
出子进程之后开始启用, Redis 主进程在接到新的写命令之后,
除了会将这个写命令的协议内容追加到现有的 AOF 文件之外,
还会追加到这个缓存中
.
换言之, 当子进程在执行 AOF 重写时, 主进程需要执行以下三个工作:
1:处理命令请求。
2:将写命令追加到现有的 AOF 文件中。
3:将写命令追加到 AOF 重写缓存中。
这样一来可以保证:
现有的 AOF 功能会继续执行,即使在 AOF
重写期间发生停机,也不会有任何数据丢失。
所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。

当子进程完成 AOF 重写之后, 它会向父进程发送一个完成信号,
父进程在接到完成信号之后, 会调用一个信号处理函数, 并完成以下工作:

  • 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
  • 对新的 AOF 文件进行改名,覆盖原有的 AOF 文件。

步骤 1 执行完毕之后, 现有 AOF 文件、新 AOF
文件和数据库三者的状态就完全一致了。
当步骤 2 执行完毕之后, 程序就完成了新旧两个 AOF 文件的交替。
这个信号处理函数执行完毕之后,
主进程就可以继续像往常一样接受命令请求了。 在整个 AOF 后台重写过程中,
只有最后的写入缓存和改名操作会造成主进程阻塞, 在其他时候, AOF
后台重写都不会对主进程造成阻塞, 这将 AOF
重写对性能造成的影响降到了最低。
以上就是 AOF 后台重写。
对于我们应该选择RDB还是AOF,官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。

  •  AOF,英文是Append Only File,即只允许追加不允许改写的文件。
  •  通过配置redis.conf中的appendonly
    yes就可以打开AOF功能。如果有写操作(如SET等),redis就会被追加到AOF文件的末尾。
  •  默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中).因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据。
  • 如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复。
  • AOF文件会变得越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。
  • 在进行AOF重写时,仍然是采用先写临时文件,全部完成后再替换的流程,所以断电、磁盘满等问题都不会影响AOF文件的可用性.
  • AOF的一个好处场景再现,如果有人不小心清了数据库。在AOF文件还没没被重写的情况下,
    可以通过停掉Redis修改AOF文件,去掉误操作的语句。重启Redis恢复数据。
  • 如果出现AOF文件被写坏的情况。可按如下步骤修复:

哈希

最后要给大家介绍的是hashes,即哈希。hashes存的是字符串和字符串值之间的映射,比如一个用户要存储其全名、姓氏、年龄等等,就很适合使用哈希。
我们来看一个例子:

//建立哈希,并赋值
127.0.0.1:6379> HMSET user:001 username antirez password P1pp0 age 34 OK
//列出哈希的内容
127.0.0.1:6379> HGETALL user:001
1) "username"
2) "antirez"
3) "password"
4) "P1pp0"
5) "age"
6) "34"
//更改哈希中的某一个值
127.0.0.1:6379> HSET user:001 password 12345
 (integer) 0
//再次列出哈希的内容
127.0.0.1:6379> HGETALL user:001
1) "username"
2) "antirez"
3) "password"
4) "12345"
5) "age"
6) "34"

九 redis 事务

RDB

RDB方式,是将redis某一时刻的数据持久化到磁盘中,是一种快照式的持久化方法
redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件。正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的。
对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能。

如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。

虽然RDB有不少优点,但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感,那么RDB方式就不太适合你,因为即使你每5分钟都持久化一次,当redis故障时,仍然会有近5分钟的数据丢失。所以,redis还提供了另一种持久化方式,那就是AOF。

    1. key不要太长,尽量不要超过1024字节,这不仅消耗内存,而且会降低查找的效率;
    2. key也不要太短,太短的话,key的可读性会降低;
    3. 在一个项目中,key最好使用统一的命名模式,例如user:10000:passwd。
    4. 字符串类型的用法就是这么简单,因为是二进制安全的,所以你完全可以把一个图片文件的内容作为字符串来存储。

Redis事务

众所周知,事务是指“一个完整的动作,要么全部执行,要么什么也没有做”。

在聊redis事务处理之前,要先和大家介绍四个redis指令,即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础

  • MULTI用来组装一个事务;
  • EXEC用来执行一个事务;
  • DISCARD用来取消一个事务;
  • WATCH用来监视一些key,一旦这些key在事务执行之前被改变,则取消事务的执行。

我们来看一个MULTI和EXEC的例子:

redis> MULTI //标记事务开始
OK
redis> INCR user_id //多条命令按顺序入队
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //执行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

在上面的例子中,我们看到了QUEUED的字样,这表示我们在用MULTI组装事务时,每一个命令都会进入到内存队列中缓存起来,如果出现QUEUED则表示我们这个命令成功插入了缓存队列,在将来执行EXEC时,这些被QUEUED的命令都会被组装成一个事务来执行

对于事务的执行来说,如果redis开启了AOF持久化的话,那么一旦事务被成功执行,事务中的命令就会通过write命令一次性写到磁盘中去,如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题,那么就可能出现只有部分命令进行了AOF持久化,这时AOF文件就会出现不完整的情况,这时,我们可以使用redis-check-aof工具来修复这一问题,这个工具会将AOF文件中不完整的信息移除,确保AOF文件完整可用。
有关事务,大家经常会遇到的是两类错误:

  • 调用EXEC之前的错误
  • 调用EXEC之后的错误

调用EXEC之前的错误,有可能是由于语法有误导致的,也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况,redis都会进行记录,在客户端调用EXEC时,redis会拒绝执行这一事务。我们来看一个这样的例子:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> haha //一个明显错误的指令
(error) ERR unknown command 'haha'
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> exec//redis无情的拒绝了事务的执行,原因是“之前出现了错误”
(error) EXECABORT Transaction discarded because of previous errors.

而对于“调用EXEC之后的错误”,redis则采取了完全不同的策略,即redis不会理睬这些错误,而是继续向下执行事务中的其他命令。这是因为,对于应用层面的错误,并不是redis自身需要考虑和处理的问题,所以一个事务中如果某一条命令执行失败,并不会影响接下来的其他命令的执行。我们也来看一个例子:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 23
QUEUED
//age不是集合,所以如下是一条明显错误的指令
127.0.0.1:6379> sadd age 15 
QUEUED
127.0.0.1:6379> set age 29
QUEUED
127.0.0.1:6379> exec //执行事务时,redis不会理睬第2条指令执行错误
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get age
"29" //可以看出第3条指令被成功执行了

好了,我们来说说最后一个指令“WATCH”,这是一个很好用的指令,它可以帮我们实现类似于“乐观锁”的效果,即CAS(check
and set)。

WATCH本身的作用是“监视key是否被改动过”,而且支持同时监视多个key,只要还没真正触发事务,WATCH都会尽职尽责的监视,一旦发现某个key被修改了,在执行EXEC时就会返回nil,表示事务无法触发。

127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> watch age //开始监视age
OK
127.0.0.1:6379> set age 24 //在EXEC之前,age的值被修改了
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 25
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec //触发EXEC
(nil) //事务无法被执行
  • 调用EXEC之前的错误。
  • 有可能是由于语法有误导致的,也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况,redis都会进行记录,在客户端调用EXEC时,redis会拒绝执行这一事务。
  • 调用EXEC之后的错误。
  • Redis则采取了完全不同的策略,即redis不会理睬这些错误,而是继续向下执行事务中的其他命令。这是因为,对于应用层面的错误,并不是redis自身需要考虑和处理的问题,所以一个事务中如果某一条命令执行失败,并不会影响接下来的其他命令的执行。
  • WATCH本身的作用是“监视key是否被改动过”,而且支持同时监视多个key,只要还没真正触发事务,WATCH都会尽职尽责的监视,一旦发现某个key被修改了,在执行EXEC时就会返回nil,表示事务无法触发。

有序集合

redis不但提供了无需集合(sets),还很体贴的提供了有序集合(sorted
sets)。有序集合中的每个元素都关联一个序号(score),这便是排序的依据

很多时候,我们都将redis中的有序集合叫做zsets,这是因为在redis中,有序集合相关的操作指令都是以z开头的,比如zrange、zadd、zrevrange、zrangebyscore等等

老规矩,我们来看几个生动的例子:

//新增一个有序集合myzset,并加入一个元素baidu.com,给它赋予的序号是1
127.0.0.1:6379> zadd myzset 1 baidu.com 
(integer) 1
//向myzset中新增一个元素360.com,赋予它的序号是3
127.0.0.1:6379> zadd myzset 3 360.com 
(integer) 1
//向myzset中新增一个元素google.com,赋予它的序号是2
127.0.0.1:6379> zadd myzset 2 google.com 
(integer) 1
//列出myzset的所有元素,同时列出其序号,可以看出myzset已经是有序的了。
127.0.0.1:6379> zrange myzset 0 -1 with scores 
1) "baidu.com"
2) "1"
3) "google.com"
4) "2"
5) "360.com"
6) "3"
//只列出myzset的元素
127.0.0.1:6379> zrange myzset 0 -1 
1) "baidu.com"
2) "google.com"
3) "360.com"

    两类错误:

lists

Lists(列表)是Redis另外一个重要的数据结构。redis中的lists在底层实现上并不是数组,而是链表,也就是说对于一个具有上百万个元素的lists来说,在头部和尾部插入一个新元素,其时间复杂度是常数级别的,比如用LPUSH在10个元素的lists头部插入新元素,和在上千万元素的lists头部插入新元素的速度应该是相同的。

虽然lists有这样的优势,但同样有其弊端,那就是,链表型lists的元素定位会比较慢,而数组型lists的元素定位就会快得多

lists的常用操作包括LPUSH、RPUSH、LRANGE等。我们可以用LPUSH在lists的左侧插入一个新元素,用RPUSH在lists的右侧插入一个新元素,用LRANGE命令从lists中指定一个范围来提取元素。我们来看几个例子:

//新建一个list叫做mylist,并在列表头部插入元素"1"
127.0.0.1:6379> lpush mylist "1" 
//返回当前mylist中的元素个数
(integer) 1 
//在mylist右侧插入元素"2"
127.0.0.1:6379> rpush mylist "2" 
(integer) 2
//在mylist左侧插入元素"0"
127.0.0.1:6379> lpush mylist "0" 
(integer) 3
//列出mylist中从编号0到编号1的元素
127.0.0.1:6379> lrange mylist 0 1 
1) "0"
2) "1"
//列出mylist中从编号0到倒数第一个元素
127.0.0.1:6379> lrange mylist 0 -1 
1) "0"
2) "1"
3) "2"

lists的应用相当广泛,随便举几个例子:

  • 我们可以利用lists来实现一个消息队列,而且可以确保先后顺序。
  • 利用LRANGE还可以很方便的实现分页的功能。
  • 从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中。
  • 在数据持久化期间,主服务器将执行的写指令都缓存在内存中。
  • 在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上,然后再将其读取到内存中。
  • 这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

redis是一种kv存储系统,value支持五种数据类型:

 

Redis持久化

redis提供了两种持久化的方式,分别是RDB和AOF。

  • RDB,简而言之,就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上;
  • AOF,则是换了一个角度来实现持久化,那就是将redis执行过的所有写指令记录下来,在下次redis重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用,在这种情况下,如果redis重启的话,则会优先采用AOF方式来进行数据恢复,这是因为AOF方式的数据恢复完整度更高
如果你没有数据持久化的需求,也完全可以关闭RDB和AOF方式,这样的话,redis将变成一个纯内存数据库,就像memcache一样

 

set

redis的集合,是一种无序的集合,集合中的元素没有先后顺序。
集合相关的操作也很丰富,如添加新元素、删除已有元素、取交集、取并集、取差集等。我们来看例子:

//向集合myset中加入一个新元素"one"
127.0.0.1:6379> sadd myset "one" 
(integer) 1
127.0.0.1:6379> sadd myset "two"
(integer) 1
//列出集合myset中的所有元素
127.0.0.1:6379> smembers myset 
1) "one"
2) "two"
//判断元素1是否在集合myset中,返回1表示存在
127.0.0.1:6379> sismember myset "one" 
(integer) 1
//判断元素3是否在集合myset中,返回0表示不存在
127.0.0.1:6379> sismember myset "three" 
(integer) 0
//新建一个新的集合yourset
127.0.0.1:6379> sadd yourset "1" 
(integer) 1
127.0.0.1:6379> sadd yourset "2"
(integer) 1
127.0.0.1:6379> smembers yourset
1) "1"
2) "2"
//对两个集合求并集
127.0.0.1:6379> sunion myset yourset 
1) "1"
2) "one"
3) "2"
4) "two"

对于集合的使用,也有一些常见的方式,比如,QQ有一个社交功能叫做“好友标签”,大家可以给你的好友贴标签,比如“大美女”、“土豪”、“欧巴”等等,这时就可以使用redis的集合来实现,把每一个用户的标签都存储在一个集合之中。

 

详细介绍AOF重写

AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取,
它针对的是数据库中键的当前值。
考虑这样一个情况, 如果服务器对键 list执行了以下四条命令:

RPUSH list 1 2 3 4 // [1, 2, 3, 4]
RPOP list // [1, 2, 3]
LPOP list // [2, 3]
LPUSH list 1 // [1, 2, 3]

那么当前列表键 list 在数据库中的值就为 [1, 2, 3] 。
如果我们要保存这个列表的当前状态, 并且尽量减少所使用的命令数,
那么最简单的方式不是去 AOF 文件上分析前面执行的四条命令, 而是直接读取
list 键在数据库的当前值, 然后用一条 RPUSH 1 2 3

命令来代替前面的四条命令。
再考虑这样一个例子, 如果服务器对集合键 animal 执行了以下命令:

SADD animal cat // {cat}
SADD animal dog panda tiger // {cat, dog, panda, tiger}
SREM animal cat // {dog, panda, tiger}
SADD animal cat lion // {cat, lion, dog, panda, tiger}

那么使用一条 SADD animal cat lion dog panda tiger命令, 就可以还原
animal
集合的状态, 这比之前的四条命令调用要大大减少。
除了列表和集合之外,
字符串、有序集、哈希表等键也可以用类似的方法来保存状态,
并且保存这些状态所使用的命令数量,
比起之前建立这些键的状态所使用命令的数量要大大减少。
根据键的类型, 使用适当的写入命令来重现键的当前值, 这就是 AOF
重写的实现原理。

  •  Redis提供了两种持久化的方式,分别是RDB(Redis
    DataBase)和AOF(Append Only File)。
  • RDB,简而言之,就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上;
  • AOF,则是换了一个角度来实现持久化,那就是将redis执行过的所有写指令记录下来.
  • 在下次redis重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。
  • 其实RDB和AOF两种方式也可以同时使用,在这种情况下,如果redis重启的话,则会优先采用AOF方式来进行数据恢复,这是因为AOF方式的数据恢复完整度更高。
  • 如果你没有数据持久化的需求,也完全可以关闭RDB和AOF方式,这样的话,redis将变成一个纯内存数据库,就像memcache一样。
  • 两种方式是可以同时使用的。

AOF

AOF,英文是Append Only File,即只允许追加不允许改写的文件
如前面介绍的,AOF方式是将执行过的写指令记录下来,在数据恢复时按照从前到后的顺序再将指令都执行一遍,就这么简单。

我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。
如果有写操作(如SET等),redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中),因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据。

如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复。

因为采用了追加方式,如果不做任何处理的话,AOF文件会变得越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。举个例子或许更形象,假如我们调用了100次INCR指令,在AOF文件中就要存储100条指令,但这明显是很低效的,完全可以把这100条指令合并成一条SET指令,这就是重写机制的原理

在进行AOF重写时,仍然是采用先写临时文件,全部完成后再替换的流程,所以断电、磁盘满等问题都不会影响AOF文件的可用性,这点大家可以放心。

AOF方式的另一个好处,我们通过一个“场景再现”来说明。某同学在操作redis时,不小心执行了FLUSHALL,导致redis内存中的数据全部被清空了,这是很悲剧的事情。不过这也不是世界末日,只要redis配置了AOF持久化方式,且AOF文件还没有被重写(rewrite),我们就可以用最快的速度暂停redis并编辑AOF文件,将最后一行的FLUSHALL命令删除,然后重启redis,就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇,这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了,那就无法通过这种方法来恢复数据了。

虽然优点多多,但AOF方式也同样存在缺陷,比如在同样数据规模的情况下,AOF文件要比RDB文件的体积大。而且,AOF方式的恢复速度也要慢于RDB方式。

如果你直接执行BGREWRITEAOF命令,那么redis会生成一个全新的AOF文件,其中便包括了可以恢复现有数据的最少的命令集。

如果运气比较差,AOF文件出现了被写坏的情况,也不必过分担忧,redis并不会贸然加载这个有问题的AOF文件,而是报错退出。这时可以通过以下步骤来修复出错的文件:

1:备份被写坏的AOF文件
2:运行redis-check-aof –fix进行修复
3:用diff -u来看下两个文件的差异,确认问题点
4:重启redis,加载修复后的AOF文件

$ find . -type f -executable./redis-benchmark // 用于进行redis性能测试的工具./redis-check-dump // 用于修复出问题的dump.rdb文件./redis-cli // redis的客户端./redis-server // redis的服务端./redis-check-aof // 用于修复出问题的AOF文件./redis-sentinel // 用于集群管理

Redis的主从机制

主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担。
redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。
主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提高主服务器的处理性能。
在主从架构中,从服务器通常被设置为只读模式,这样可以避免从服务器的数据被误修改。

四 redis 持久化

本文摘抄至大鹏的redis教程

  • redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。
  • 主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提高主服务器的处理性能。
  • 在主从架构中,从服务器通常被设置为只读模式,这样可以避免从服务器的数据被误修改。
  • 但是从服务器仍然可以接受CONFIG等指令,所以还是不应该将从服务器直接暴露到不安全的网络环境中。
  • 如果必须如此,那可以考虑给重要指令进行重命名,来避免命令被外人误执行。
  • 重命名指定可以参考另一篇blog

八 Redis 同步

七 Redis 主从同步

 

 

  • 事务是指“一个完整的动作,要么全部执行,要么什么也没有做”。
  • 四个redis指令,即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。
  • MULTI用来组装一个事务;
  • EXEC用来执行一个事务;
  • DISCARD用来取消一个事务;
  • WATCH用来监视一些key,一旦这些key在事务执行之前被改变,则取消事务的执行。
  1. 字符串
      Redis字符串是字节序列。Redis字符串是二进制安全的,这意味着他们有一个已知的长度没有任何特殊字符终止,所以你可以存储任何东西,512兆为上限。
  2. 哈希
      Redis的哈希是键值对的集合。
    Redis的哈希值是字符串字段和字符串值之间的映射,因此它们被用来表示对象.
  3. 列表
      Redis的列表是简单的字符串列表,排序插入顺序。您可以添加元素到Redis的列表的头部或尾部。
      列表的最大长度为 232 – 1
    元素(4294967295,每个列表中可容纳超过4十亿的元素)。
  4. 集合
      Redis的集合是字符串的无序集合。在Redis您可以添加,删除和测试文件是否存在,在成员O(1)的时间复杂度。
      集合中的元素最大数量为 232 – 1
    (4294967295,可容纳超过4十亿元素)。
  5. 有序集合
      Redis的有序集合类似于Redis的集合,字符串不重复的集合。不同的是,一个有序集合的每个成员用分数,以便采取有序set命令,从最小的到最大的成员分数有关。虽然成员具有唯一性,但分数可能会重复。

     a.备份被写坏的AOF文件
   b.运行redis-check-aof –fix进行修复
   c.用diff -u来看下两个文件的差异,确认问题点
   d.重启redis,加载修复后的AOF文件

六 Redis持久化 – AOF

  • QUEUED的字样,这表示我们在用MULTI组装事务时,每一个命令都会进入到内存队列中缓存起来,如果出现QUEUED则表示我们这个命令成功插入了缓存队列,在将来执行EXEC时,这些被QUEUED的命令都会被组装成一个事务来执行.
  • 对于事务的执行来说,如果redis开启了AOF持久化的话,那么一旦事务被成功执行,事务中的命令就会通过write命令一次性写到磁盘中去。
  • 如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题,那么就可能出现只有部分命令进行了AOF持久化,这时AOF文件就会出现不完整的情况。这时,我们可以使用redis-check-aof工具来修复这一问题,这个工具会将AOF文件中不完整的信息移除,确保AOF文件完整可用。
  •  Redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件。正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的。
  • 对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。

五 redis持久化 – RDB

三 Redis 管理

二 Redis 文件说明

  • 服务启动:./redis-server ../redis.conf 端口默认为6379
  • 使用客户端:./redis-cli
  • 通过客户端来关闭redis服务端 127.0.0.1:6379> shutdown
  •  一些注意: