1. Redis基础
非关系型数据库。
key - value，对。
flushall，清空所有数据。
1.1 Redis数据类型
redis提供五种数据类型：string，hash，list，set及zset(sorted set)。
1.1.1 string
string是最简单的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value，其上支持的操作与Memcached的操作类似。但它的功能更丰富.
set username lyx #创建新键。set 键 键值。会覆盖。
get username #查看键值。get 键。
setnx username lyx #创建新键。如果存在，返回 0，如果不存在，返回1
ttl username #查看键值生命周期。 ttl 键
setex username2 30 cs #创建新键，并设置生命时间。setex 键 秒数 值。
mset a1 10 a2 20 #批量创建键。mset 键 值 键 值。会覆盖。
mget a1 a2 a3 #批量查看键值。mget 键 键 键。
msetnx a1 40 a2 50 a3 60 #批量创建新键。不会覆盖。返回0 创建失败，返回1，创建成功。
getset a1 70 #设置新值，并返回原值。
setrange a1 9 zhengchangle #查找替换某一段原值。setrange 键 第几个字符开始 新值。 -1代表结尾
getrange a1 9 12 #查看值的某一段。getrange 键 从第几个开始 到第几个结束。
incr a1 #在原值的基础上加1
decr a1 #在原值的基础下减1
incrby a1 5 #在原值的基础上加5
decrby a1 5 #在原值的基础上减5
del a1 #删除键。
1.1.2.hash
dict中table为dictEntry指针的数组，数组中每个成员为hash值相同元素的单向链表。set是在dict的基础上实现的，指定了key的比较函数为dictEncObjKeyCompare，若key相等则不再插入。
Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
应用场景
假设有多个用户及对应的用户信息，可以用来存储以用户ID为key，将用户信息序列化为比如json格式做为value进行保存。
hset b1 name lyx #使用哈希存值。hset 键 字段 值。会覆盖原值。
hget b1 name #使用哈希取值。hget 键 字段。
hsetnx b1 name fangchao #使用哈希存值，如果存在返回0，如果不存在 ，返回1.
hmset b1 name1 f1 name2 f2 name3 f3 #批量存值。
hmget b1 name1 name2 name3 #批量取值。
hlen b1 #查看键中有多少个字段。
hgetall b1 #查看键中所有字段 值。
hkeys b1 #查看所有键
hvals b1 #查看所有值
hdel b1 name #删除键中的某一个字段。
hincrby b1 num 10 #递增10 没有递减。
1.1.3.list(双向列表)
list是一个链表结构，主要功能是push、pop、获取一个范围的所有值等等。操作中key理解为链表的名字。
简单的说就是一个链表或者说是一个队列。可以从头部或尾部向Redis列表添加元素。列表的最大长度为2^32 - 1，也即每个列表支持超过40亿个元素。
Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
应用场景
Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表、粉丝列表等都可以用Redis的list结构来实现，再比如有的应用使用Redis的list类型实现一个简单的轻量级消息队列，生产者push，消费者pop/bpop。
lpush list1 1 #创建列表，并插入一条数据，。lpush 列表 数值 ，从右往左插入。
rpush list2 1 #创建列表，从左到右。
lrange list1 0 -1 #查看列表中所有值。
列表中的下标，索引。从左到右。0 1 2 3 4。从右到左。-1 -2 -3 -4 -5。
lindex list1 -1 #查看指定索引的数值。
linsert list1 before 2(值) 5(值)。#在某个值的前面插入。只在第一个前面添加
linsert list1 after 2(值) 5(值)。#在某个值的后面插入。 只在第一个前面添加
lset list1 2 7 #修改列表中的某个值。2是下标，7是修改后的值。
lrem list1 -5 5 #删除列表中的指定的值。lrem list1 删除的位置 指定的值。
ltrim list2 2 3 #保留2－3（下标）的值，其余删除掉。指定从左到右的列表。
lpop/rpop list2 #从头或者尾部删除一个值。
llen list1 #查看列表中数值的个数。
1.1.4.set
set是集合，和我们数学中的集合概念相似，对集合的操作有添加删除元素，有对多个集合求交并差等操作。操作中key理解为集合的名字。
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
应用场景
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。又或者在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。
sadd s1 1 2 3 #创建集合并添加数值。
smembers s1 #查看集合中所有的元素。
srandmember s1 #随机取出一个值。
spop s1 #随机删除一个值。
srem s1 值 #删除指定的一个值。
scard s1 #查看集合中元素个数。
sinter s1 s2 #查看交集
sinterstore s3 s1 s2 #查看交集并保存到s3
sdiffstore s4 s1 s2 #查看差集并保存到s4
sunion s1 s2 #查看并集
sunionstore s5 s1 s2 #查看并集并保存到s5
smove s1 s2 5 #移动s1里的5到s2中。
1.1.5.zset
zset是set的一个升级版本，他在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，zset会自动重新按新的值调整顺序。可以理解了有两列的mysql表，一列存value，一列存顺序。操作中key理解为zset的名字。
Redis有序集合类似Redis集合，不同的是增加了一个功能，即集合是有序的。一个有序集合的每个成员带有分数，用于进行排序。
Redis有序集合添加、删除和测试的时间复杂度均为O(1)(固定时间，无论里面包含的元素集合的数量)。列表的最大长度为2^32- 1元素(4294967295，超过40亿每个元素的集合)。
Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
使用场景
Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
又比如用户的积分排行榜需求就可以通过有序集合实现。还有上面介绍的使用List实现轻量级的消息队列，其实也可以通过Sorted Set实现有优先级或按权重的队列。
zadd z1 1 a 2 b 10 c 3 d 4 e #创建有序集合并添加元素。zadd z1 分数 值 分数 值。如果值重复，则覆盖，如果不重复，则添加
zrange z1 0 -1 #查看所有元素并从小到大排列 。
zrevrange z1 0 -1 #查看所有元素并从大到小排列 。
zrangebyscore z1 3 5 #查看某个分数范围内的元素。
zrem z1 aa #删除集合中某个值的元素。
zincrby z1 10 xxx #添加元素，如果不存在，添加成功，如果存在，添加不成功。
zrank z1 lyxx #查看指定值的下标。从0 开始。
zrevrank z1 lyx #查看指定元素的下标。倒着从0开始。
zcard z1 #统计集合中元素的个数。
zcount z1 3 5 #统计集合中指定分数范围内的元素个数。
zremrangebyrank z1 1 2 #根据下标来删除指定范围内的元素。
zremrangebyscore z1 3 5 #根据分数来删除指定范围内的元素。
zinterstore z7 3 z1 z2 z3 #查看交集并保存到新的集合。zinterstore 新集合 集合数目 集合1 集合2 集合3
1.2 redis 存储
redis使用了两种文件格式：全量数据和增量请求。
全量数据格式是把内存中的数据写入磁盘，便于下次读取文件进行加载；
增量请求文件则是把内存中的数据序列化为操作请求，用于读取文件进行replay得到数据，序列化的操作包括SET、RPUSH、SADD、ZADD。
redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。save seconds updates，save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。
appendonly yes/no ，appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。
appendfsync no/always/everysec ，appendfsync配置，no表示等操作系统进行数据缓存同步到磁盘，always表示每次更新操作后手动调用fsync()将数据写到磁盘，everysec表示每秒同步一次。
1.3 Redis淘汰机制
在 redis 中，允许用户设置最大使用内存大小 server.maxmemory，在内存限定的情况下是很有用的。譬如，在一台 8G 机子上部署了 4 个 redis 服务点，每一个服务点分配 1.5G 的内存大小，减少内存紧张的情况，由此获取更为稳健的服务。
redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：
- volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
- volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
- volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
- allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
- allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
redis 确定驱逐某个键值对后，会删除这个数据并，并将这个数据变更消息发布到本地（AOF 持久化）和从机（主从连接）。
1.3.1 LRU淘汰机制
在服务器配置中保存了 lru 计数器 server.lrulock，会定时（redis 定时程序 serverCorn()）更新，server.lrulock 的值是根据 server.unixtime 计算出来的。从 struct redisObject 中可以发现，每一个 redis 对象都会设置相应的 lru。可以想象的是，每一次访问数据的时候，会更新 redisObject.lru。
LRU 数据淘汰机制是这样的：在数据集中随机挑选几个键值对，取出其中 lru 最大的键值对淘汰。所以，你会发现，redis 并不是保证取得所有数据集中最近最少使用（LRU）的键值对，而只是随机挑选的几个键值对中的。
1.3.2 TTL淘汰机制
redis 数据集数据结构中保存了键值对过期时间的表，即 redisDb.expires。和 LRU 数据淘汰机制类似，TTL 数据淘汰机制是这样的：从过期时间的表中随机挑选几个键值对，取出其中 ttl 最大的键值对淘汰。同样你会发现，redis 并不是保证取得所有过期时间的表中最快过期的键值对，而只是随机挑选的几个键值对中的。
2 Redis安全问题
2.1 无数据key 查询，缓存击穿问题
对于不存在的key 一般会去数据库进行查询，但这也产生了一系列问题，对于数据也不存在的数据，特别是不可能存在的key，如'&&'，‘$$$$$’，如果同一时间用这些参数去请求redis这将会在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
2.2 缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。
缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
2.3 缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。
缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
2.3.1 使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。
SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。
2.3.2
"提前"使用互斥锁(mutex key)：
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。
3.Redis的持久化
redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
3.1 RDB的特点
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数 据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
RDB又存在哪些劣势呢？
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
3.2 AOF的特点
1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其 效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变 化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操 作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据 一致性的问题。
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创 建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
AOF的劣势有哪些呢？
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。
3.3 Redis持久化配置
3.3.1 RDB持久化配置
Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
3.3.2 AOF持久化配置
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。