Redis入门

目录或文件	作用
redis-benchmark	性能测试工具
redis-check-aof	AOF文件修复工具
redis-check-dump	RDB文件检查工具（快照持久化文件）
redis-cli	命令行客户端
redis-server	redis服务器启动命令
redis.windows.conf	redis核心配置文件

2.4Redis的常见数据类型

字符串（String）
哈希（hash）
字符串列表（list）
字符串集合（set）
有序字符串集合（sorted set）

2.4.1字符串类型String

字符串 string 是 Redis 最简单的数据结构。在Redis中字符串类型的Value最多可以容纳的数据长度是512M。

常用命令：

set key value

设定key持有指定的字符串value，如果该key存在则进行覆盖操作。总是返回”OK”

get key

获取key的value。如果与该key关联的value不是String类型，redis将返回错误信息，因为get命令只能用于获取String value；如果该key不存在，返回(nil)。

del key

删除指定key

incr key

指定字段数字递增1

incrby key 数值

指定字段数字递增指定的数值

decr key

指定字段数字递减1

decrby key 数值

指定字段数字递减指定的数值

2.4.2哈希类型Hash

Redis中的Hash类型可以看成具有String Key和String Value的map容器。所以该类型非常适合于存储值对象的信息。如果Hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。

常用命令：

hset key field value

为指定的key设定field/value对（键值对）。

hget key field
返回指定的key中的field的值

hdel key field [field … ]
可以删除一个或多个字段，返回值是被删除的字段个数

hmset key field value field value field value

一次设置多个值

hmget key field field field

一次获取多个值

hkeys key

获取一个hash中所有的键

hvals key

获取一个hash中所有的值

hgetall key

获取一个hash中所有的键值对

del key

删除掉整个hash

2.4.3列表类型list

在Redis中，List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4294967295个。

常用命令：

lpush key values[value1 value2…]
在指定的key所关联的list的头部插入所有的values，如果该key不存在，该命令在插入的之前创建一个与该key关联的空链表，之后再向该链表的头部插入数据。插入成功，返回元素的个数。

rpush key values[value1 value2…]
在指定的key所关联的list的尾部插入所有的values，如果该key不存在，该命令在插入的之前创建一个与该key关联的空链表，之后再向该链表的尾部插入数据。插入成功，返回元素的个数。

lpop key
返回并弹出指定的key关联的链表中的第一个元素，即头部元素。如果该key不存在，返回nil；若key存在，则返回链表的头部元素

rpop key
从尾部弹出元素。

lrange key start end

查看key中多有元素。

start、end为正数或0表示从左数第几个元素。为负数表示从又数第几个元素。

del key

删除整个key

2.4.4集合类型set

在Redis中，我们可以将Set类型看作为没有排序的字符集合，和List类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为O(1)，即常量时间内完成次操作。Set可包含的最大元素数量是4294967295，和List类型不同的是，Set集合中不允许出现重复的元素。

常用命令：

sadd key values[value1、value2…]
向set中添加数据，如果该key的值已有则不会重复添加

smembers key
获取set中所有的成员

srem key members[member1、member2…]
删除set中指定的成员

sdiff key1 key2

取两个集合的差集

sunion key1 key2

取两个集合的并集

sinter key1 key2

取两个集合的交集

2.4.5有序集合类型sorted set

Redis 有序集合和集合一样也是string类型元素的集合，且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的序。有序集合的成员是唯一的，但分数(score)却可以重复。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

常用命令：

zadd key score member [score member ...]
向有序集合中加入一个元素和该元素的分数，如果该元素已经存在则会用新的分数替换原有的分数。返回值是新加入到集合中的元素个数，不包含之前已经存在的元素。

zscore key member
获取元素的分数

zrem key member [member ...]
移除有序集key中的一个或多个成员，不存在的成员将被忽略。当key存在但不是有序集类型时，返回一个错误。

zrange key start stop [WITHSCORES]
按照元素分数从小到大的顺序返回索引从start到stop之间的所有元素（包含两端的元素）

zrevrange key start stop [WITHSCORES]
按照元素分数从大到小的顺序返回索引从start到stop之间的所有元素（包含两端的元素）

2.4.6通用指令

keys *
返回满足给定pattern 的所有key

del key1 key2

删除key

exists key
确认一个key 是否存在

type key
查看key的数据类型

expire key seconds

设置key的生存时间（单位：秒）key在多少秒后会自动删除

ttl key

查看key生于的生存时间

-1：永不超时

-2：已超时

正数：剩余生存的秒数

persist key

清除生存时间

pexpire key milliseconds

生存时间设置单位为：毫秒

Redis当中默认存在16个数据库

select index

切换库

dbsize

返回当前库中有多少个key

flushdb

清空当前数据库数据

flushall

清空当前实例下所有的数据库数据

2.5Redis的持久化机制

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。

RDB持久化（默认支持，无需配置）：该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

AOF持久化：该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。

无持久化：我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。

redis可以同时使用RDB和AOF。

2.5.1RDB持久化机制优点

一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上性能最大化。

对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork（分叉）出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

2.5.2RDB持久化机制缺点

如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

2.5.3RDB持久化机制的配置

在redis.windows.conf配置文件中有如下配置：

################################ SNAPSHOTTING #################################
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving at all commenting all the "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:

#
# save ""
save 900 1
save 300 10
save 60 10000

其中，上面配置的是RDB方式数据持久化时机：

关键字	时间(秒)	key修改数量	解释
save	900	1	每900秒(15分钟)至少有1个key发生变化，则dump内存快照
save	300	10	每300秒(5分钟)至少有10个key发生变化，则dump内存快照
save	60	10000	每60秒(1分钟)至少有10000个key发生变化，则dump内存快照

2.5.4AOF持久化机制优点

该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

2.5.5AOF持久化机制缺点

对于相同数量的数据集而言，AOF文件通常要大于RDB文件。

根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

2.5.6AOF持久化机制配置

开启AOF持久化机制

在redis.windows.conf配置文件中有如下配置：

############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on

# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
appendonly no

将appendonly修改为yes，开启aof持久化机制，默认会在目录下产生一个appendonly.aof文件。

AOF持久化时机

# appendfsync always
appendfsync everysec
# appendfsync no

上述配置为aof持久化的时机，解释如下：

关键字	持久化时机	解释
appendfsync	always	每执行一次更新命令，持久化一次
appendfsync	everysec	每秒钟持久化一次
appendfsync	no	不会主动执行持久话，依赖于操作系统的空闲调用

以上是关于Redis的基础介绍，如有不严谨的地方，麻烦各位大佬评论或私信支教，还请不吝赐教，谢谢！