4.1 Redis的5种数据类型
redis是一种高级的key-value的存储系统，其中value支持五种数据类型：
-
字符串（String）
-
哈希（hash）
-
字符串列表（list）
-
字符串集合（set）
-
有序字符串集合（sorted set）
关于key的定义，注意如下几点：
-
key不要太长，最好不要操作1024个字节，这不仅会消耗内存还会降低查找效率
-
key不要太短，如果太短会降低key的可读性
-
在项目中，key最好有一个统一的命名规范
4.2 字符串类型string
4.2.1 字符串类型string概述
字符串类型是Redis中最为基础的数据存储类型，它在Redis中是二进制安全的，这便意味着该类型存入和获取的数据相同。在Redis中字符串类型的Value最多可以容纳的数据长度是512M。
4.2.2 字符串类型string常用命令
-
set key value
设定key持有指定的字符串value，如果该key存在则进行覆盖操作。总是返回”OK”
127.0.0.1:6379> set company "itcast"
OK
127.0.0.1:6379>
-
get key
获取key的value。如果与该key关联的value不是String类型，redis将返回错误信息，因为get命令只能用于获取String value；如果该key不存在，返回(nil)。
127.0.0.1:6379> set name "itcast"
OK
127.0.0.1:6379> get name
"itcast" -
del key
删除指定key
127.0.0.1:6379> del name
(integer) 1
127.0.0.1:6379> get name
(nil)
incr命令 自增
decr命令 自减
incrby key step 自增步数
decrby key step 自减步数
4.3 哈希类型hash
4.3.1 哈希类型hash概述
Redis中的Hash类型可以看成具有String Key和String Value的map容器。所以该类型非常适合于存储值对象的信息。如Username、Password和Age等。如果Hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。
4.3.2 哈希类型hash常用命令
-
hset key field value
为指定的key设定field/value对（键值对）。
127.0.0.1:6379> hset myhash username haohao
(integer) 1
127.0.0.1:6379>
-
hget key field
返回指定的key中的field的值
127.0.0.1:6379> hset myhash username haohao
(integer) 1
127.0.0.1:6379> hget myhash username
"haohao"
-
hdel key field [field … ]
可以删除一个或多个字段，返回值是被删除的字段个数
127.0.0.1:6379> hdel myhash username
(integer) 1
127.0.0.1:6379> hget myhash username
(nil)
127.0.0.1:6379>
4.4 列表类型list
4.4.1 列表类型list概述
在Redis中，List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4294967295
4.4.2 列表类型list
-
lpush key values[value1 value2…]
在指定的key所关联的list的头部插入所有的values，如果该key不存在，该命令在插入的之前创建一个与该key关联的空链表，之后再向该链表的头部插入数据。插入成功，返回元素的个数。
127.0.0.1:6379> lpush mylist a b c
(integer) 3
127.0.0.1:6379>
-
lpop key
返回并弹出指定的key关联的链表中的第一个元素，即头部元素。如果该key不存在，返回nil；若key存在，则返回链表的头部元素。
127.0.0.1:6379> lpush mylist a b c
(integer) 3
127.0.0.1:6379> lpop mylist
"c"
127.0.0.1:6379> lpop mylist
"b" -
rpop key
从尾部弹出元素。
127.0.0.1:6379> lpush mylist a b c
(integer) 3
127.0.0.1:6379> rpop mylist
"a"
4.5 集合类型set
4.5.1 集合类型set
在Redis中，我们可以将Set类型看作为没有排序的字符集合，和List类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为O(1)，即常量时间内完成次操作。Set可包含的最大元素数量是4294967295，和List类型不同的是，Set集合中不允许出现重复的元素。
4.5.2 集合类型set的常用命令
-
sadd key values[value1、value2…]
向set中添加数据，如果该key的值已有则不会重复添加
127.0.0.1:6379> sadd myset a b c
(integer) 3 -
smembers key
获取set中所有的成员
127.0.0.1:6379> sadd myset a b c
(integer) 3
127.0.0.1:6379> smembers myset
1) "c"
2) "a"
3) "b" -
srem key members[member1、member2…]
删除set中指定的成员
127.0.0.1:6379> srem myset a b (integer) 2 127.0.0.1:6379> smembers myset 1) "c" 127.0.0.1:6379>
第5章 Redis的通用命令
-
keys pattern
获取所有与pattern匹配的key，返回所有与该key匹配的keys。*表示任意一个或多个字符，?表示任意一个字符
127.0.0.1:6379> keys *
1) "company"
2) "mylist"
3) "myhash"
4) "myset" -
del key1 key2…
删除指定的key
127.0.0.1:6379> del company
(integer) 1 -
expire key
判断该key是否存在，1代表存在，0代表不存在
127.0.0.1:6379> exists compnay
(integer) 0
127.0.0.1:6379> exists mylist
(integer) 1
127.0.0.1:6379> -
type key
获取指定key的类型。该命令将以字符串的格式返回。 返回的字符串为string、list、set、hash，如果key不存在返回none
127.0.0.1:6379> type company
string
127.0.0.1:6379> type mylist
list
127.0.0.1:6379> type myset
set
127.0.0.1:6379> type myhash
hash
127.0.0.1:6379>expire
过期时间:
expire key 秒值
第6章 Redis的持久化
6.1 Redis持久化概述
Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。
-
RDB持久化（默认支持，无需配置）
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
-
AOF持久化
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
-
无持久化
我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。
-
redis可以同时使用RDB和AOF
6.2 RDB持久化机制
6.2.1 RDB持久化机制优点
-
一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
-
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上
-
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork（分叉）出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高
6.2.2 RDB持久化机制缺点
-
如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
-
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟
6.2.3 RDB持久化机制的配置
在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内存快照 |
6.3 AOF持久化机制
6.3.1 AOF持久化机制优点
-
该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
-
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
-
如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
-
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建
6.3.2 AOF持久化机制缺点
-
对于相同数量的数据集而言，AOF文件通常要大于RDB文件
-
根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
6.3.3 AOF持久化机制配置
6.3.3.1 开启AOF持久化
############################## 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文件
6.3.3.2 AOF持久化时机
# appendfsync always
appendfsync everysec
# appendfsync no
上述配置为aof持久化的时机，解释如下：
| 关键字 | 持久化时机 | 解释 |
|---|---|---|
| appendfsync | always | 每执行一次更新命令，持久化一次 |
| appendfsync | everysec | 每秒钟持久化一次 |
| appendfsync | no | 不持久化 |