标签：超过 list 故障 序号 正是 inode 完成 永久 数据持久化
redis是一种高级的key:value存储系统，其中value支持五种数据类型：
1.字符串（strings）
2.字符串列表（lists）
3.字符串集合（sets）
4.有序字符串集合（sorted
sets）
5.哈希（hashes）
而关于key，有几个点要提醒大家：
1.key不要太长，尽量不要超过1024字节，这不仅消耗内存，而且会降低查找的效率；
2.key也不要太短，太短的话，key的可读性会降低；
3.在一个项目中，key最好使用统一的命名模式，例如user:10000:passwd。
Keys *
127.0.0.1:6379> keys *
1) "str2"
2) "num"
3) "str1"
4) "mystr"
5) "mynum"
select 0
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> select 2
OK
127.0.0.1:6379[2]>
exists key
如果存在，返回整数类型 1 ，否则返回 0
127.0.0.1:6379> exists str
(integer) 0
127.0.0.1:6379> exists mynum
(integer) 1
del key [key.....]
可以删除一个或多个键，返回值是删除的键的个数
注意：不支持通配符删除
127.0.0.1:6379> get str
"666"
127.0.0.1:6379> del str
(integer) 1
127.0.0.1:6379> get str
(nil)
type key
返回值可能是 string(字符串类型) hash(散列类型) list(列表类型) set(集合类型) zset(有序集合类型)
127.0.0.1:6379> type str
string
set key value 赋值
get key 取值
127.0.0.1:6379> set str "666"
OK
127.0.0.1:6379> get str
"666"
incr key
incrby key increment
incrby 命令与 incr 命令基本一样，只不过前者可以通过 increment 参数指定一次增加的数值如：
incrby num 2
incrby num 3
127.0.0.1:6379> get mynum
"7"
127.0.0.1:6379> incr mynum
(integer) 8
127.0.0.1:6379> get mynum
"8"
127.0.0.1:6379> incrby mynum 5
(integer) 13
127.0.0.1:6379> get mynum
"13"
decr key
decrby key increment
desc 命令与incr 命令用法相同，只不过是让键值递减
decrby 命令与 incrby命令用法相同
127.0.0.1:6379> get mynum
"13"
127.0.0.1:6379> decr mynum
(integer) 12
127.0.0.1:6379> get mynum
"12"
127.0.0.1:6379> decrby mynum 5
(integer) 7
127.0.0.1:6379> get mynum
"7"
append key value
作用是向键值的末尾追加 value ，如果键不存在则将改键的值设置为 value，即相当于 set key value。返回值是追加后字符串的长度。
127.0.0.1:6379> set str "hello world"
OK
127.0.0.1:6379> get str
"hello world"
127.0.0.1:6379> append str "!!!"
(integer) 14
127.0.0.1:6379> get str
"hello world!!!"
strlen key
返回键值的长度，如果键不存在则返回0
127.0.0.1:6379> get mystr
"hello world!!!"
127.0.0.1:6379> strlen mystr
(integer) 14
mget key [key.....]
mset key value [key value .......]
127.0.0.1:6379> mset str1 "0000" str2 "1111"
OK
127.0.0.1:6379> mget str1 str2
1) "0000"
2) "1111"
move key db
127.0.0.1:6379> keys *
1) "str2"
2) "num"
3) "str1"
4) "mystr"
5) "mynum"
127.0.0.1:6379> move mynum 1
(integer) 1
127.0.0.1:6379> keys *
1) "str2"
2) "num"
3) "str1"
4) "mystr"
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
1) "mynum"
127.0.0.1:6379[1]>
flushdb
127.0.0.1:6379[1]> keys *
1) "mynum"
127.0.0.1:6379[1]> flushdb
OK
127.0.0.1:6379[1]> keys *
(empty list or set)
127.0.0.1:6379[1]>
flushal
127.0.0.1:6379> keys *
1) "str2"
2) "num"
3) "str1"
4) "mystr"
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
1) "str"
127.0.0.1:6379[1]> flushall
OK
127.0.0.1:6379[1]> keys *
(empty list or set)
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> keys *
(empty list or set)
randomkey
127.0.0.1:6379> mset str "000" mynum "1" str1 "222"
OK
127.0.0.1:6379> keys *
1) "str1"
2) "mynum"
3) "str"
127.0.0.1:6379> randomkey
"mynum"
127.0.0.1:6379> randomkey
"mynum"
127.0.0.1:6379> randomkey
"str1"
127.0.0.1:6379> randomkey
"str1"
127.0.0.1:6379> randomkey
"str1"
127.0.0.1:6379> randomkey
"str"
127.0.0.1:6379>
expire
expire key seconds 设置过期时间，单位是秒
ttl key 查看剩余时间
persist key 取消生存时间
pexpire key milliseconds 设置过期时间，单位是毫秒
pttl key 查看剩余时间
expire 命令的使用方法为 expire key seconds ，其中 seconds 参数表示键的生存时间，单位是秒，该参数必须是整数
命令返回 1表示设置成功，返回 0 则表示键不存在或设置失败
如果想知道一个键还有多久会被删除，可以使用 ttl 命令。返回值是键的剩余时间（单位是秒），
如果想取消键的生存时间设置(即将键恢复成为永久的)，可以使用 persist 命令。如果生存时间被成功清除则返回 1 。否则返回 0
除了 persist 命令之外，使用 set 、getset 命令为键赋值也同时会清楚键的生存时间
注： incr 、lpush、hset、zrem 命令均不会影像键的生存时间
精确控制键的生存时间应该使用 pexpire 命令。该命令的单位是毫秒
可以使用 pttl 命令以毫秒为单位返回键的剩余时间
1.举例：设置过期时间
127.0.0.1:6379> keys *
1) "str1"
2) "mynum"
3) "str"
127.0.0.1:6379> expire str 20
(integer) 1
127.0.0.1:6379> ttl str
(integer) 14
127.0.0.1:6379> ttl str
(integer) 8
127.0.0.1:6379> ttl str
(integer) 0
127.0.0.1:6379> ttl str
(integer) -2
127.0.0.1:6379> keys *
1) "str1"
2) "mynum"
2.举例:取消生存时间
127.0.0.1:6379> keys *
1) "str1"
2) "mynum"
3) "str"
127.0.0.1:6379> expire str 20
(integer) 1
127.0.0.1:6379> ttl str
(integer) 16
127.0.0.1:6379> persist str
(integer) 1
127.0.0.1:6379> ttl str
(integer) -1
127.0.0.1:6379> keys *
1) "str1"
2) "mynum"
3) "str"
有人说，如果只使用redis中的字符串类型，且不使用redis的持久化功能，那么，redis就和memcache非常非常的像了。这说明strings类型是一个很基础的数据类型，也是任何存储系统都必备的数据类型。
我们来看一个最简单的例子：
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的这个特性来实现业务上的统计计数需求。
lpush key value [value ...] 新建一个list, 在左侧插入一个新元素
rpush key value [value ...] 在右侧插入一个新元素
lrange key start stop 从lists中指定一个范围来提取元素
redis的另一个重要的数据结构叫做lists，翻译成中文叫做“列表”。
首先要明确一点，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"
sadd key member [member ...] 新建集合并添加元素
smembers key 列出集合中的所有元素
sismember key member 判断元素是否在集合中，返回1表示存在，返回0表示不存在
sunion key [key ...] 对两个集合求并集
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的集合来实现，把每一个用户的标签都存储在一个集合之中。
//新增一个有序集合并添加元素
zadd key [NX|XX] [CH] [INCR] score member [score member ...]
//列出有序集合的所有元素
zrange key start stop [WITHSCORES]
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 withscores
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"
hmset key field value [field value ...] 建立哈希，并赋值
hgetall key 列出哈希的内容
hset key field value 更改哈希中的某一个值
最后要给大家介绍的是hashes，即哈希。哈希是从redis-2.0.0版本之后才有的数据结构。
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（Redis DataBase）和AOF（Append Only File）。
RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。
如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。
RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是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文件
AOF重写的内部运行原理，我们有必要了解一下。
在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。
对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。
标签：超过 list 故障 序号 正是 inode 完成 永久 数据持久化
原文地址：https://www.cnblogs.com/jcjssl/p/10393158.html
