1.Redis数据结构及简单操作指令

String、list、set、hash、zset（有序set）

总体来说redis都是通过Key-Value的形式来存储数据的。只是不用数据类型Value的形式不同。

String：最简单数据结构，比如我们将一个对象转成json串来存储

set key value 存放数据

get key 获取数据

exists key 查看数据是否存在，存在返回1否则0

del key 删除数据 返回操作成功的条数

mset key1 value1 key2 value2 key3 value3...存放多组数据

mget key1 ke2y key3... 获取多个key的数据，返回一个集合，类似Map的values方法

expire key second 设置key 过去时间，单位秒

setex key second value设置key 过去时间，单位秒(等价于先set，再expire)

setnx key value 如果key不存在就set 返回1.如果存在返回0（可以基于此实现分布式锁）

List：并不是java里面的list，redis的list更像一个链表或者说队列/栈的结构。这就意味着它的删除插入快，但是通过索引定位就比较慢了。当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收。

Redis 的列表结构常用来做异步队列使用。将需要延后处理的任务塞进 Redis 的列表，另一个线程从这个列表中轮询数据进行处理。

rpush key value1 value2 value3...  插入list数据

llen key     查看长度

lpop key    按加入顺序获取（先进先出，类似队列）

rpop key   后进先出，有点类似栈

列表取数据，取完后整个列表都被回收了，就是说只能取一次数据。

Hash：类似java的hashMap，和字符串相比，我们存储数据的时候可以只存储对象的部分属性，而字符串则需要完整将整个对象转换。当然hash存储结构的消耗肯定是高于字符串的

hset redisKey hashKey1 value1

 　  hset redisKey hashKey2 value2  插入数据

hgetall redisKey  获取数据，key value间隔出现

hlen redisKey  查看hash长度

hget redisKey hashKey 获取hashKey 对应的value

hmset redisKey hashKey1 value1 hashKey2 value2 hashKey2 value3 批量插入值

Set : 类似HashSet,但是list类似，最后一个数据取完之后，该结构会被清理，无法再次获取数据

sadd key value         

sadd key value1 value2   批量添加

smembers key    查看所有

sismember key value  查询某个值是否存在，存在返回1

scard  key   查看大小

spop key    获取一个元素

原子计数操作

如果value是整数的话还可以实现自增操作（也可以用于实现分布式锁，该增长有限，最大到long max，超过该值会直接报错）

incr key 自增 如果key不存在默认从0自增1

incrby key step 设置增加步长step

2.redis持久化

虽然说redis都是内存级别的操作，其实也是有持久化的。

一种是基于RDB快照，

Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

可以对 Redis 进行设置， 让它在N 秒内数据集至少有 M 个改动这一条件被满足时， 自动保存一次数据集。

另一种是AOF（append-only file）

快照并不可靠，上次快照之后，还未到达下一次快照条件时，这时候服务出现了问题，那么这期间的数据是无法保存到快照版本中的。这个时候就需要AOF了，它将每一条指令都记录进文件，当redis重启的时候，重新执行这个文件里面指令，就可以恢复所有的数据到内存中了。

可以通过配置appendonly yes 来开启AOF，默认是关闭的

AOF也有三种同步数据的策略，

每次有操作都去刷新文件，很慢，但安全

每秒同步刷新一次：可能会丢失一秒内的数据

从不同步同步刷新：让操作系统在需要的时候刷新数据，不安全

默认的是每秒刷一次 

混合持久化：

RDB快照数据恢复速度快，但是可能会有大量数据丢失，所以通常恢复数据还是用的AOF日志重放，但是AOF相对来说速度会很慢，尤其是在数据量大的时候。因此在4.0的时候带来了混合持久化，也就是AOF在刷新的时候，先记录上次的快照版本，然后记录上次快照版本到现在的增量操作，然后合并成一个文件，覆盖原来的appendonly.aof文件。Redis重启的时候，先加载RDB快照的内容，在重放AOF日志中增量操作的内容就可以了。

开启混合持久化：aof-use-rdb-preamble yes

混合持久化中appendonly.aof内容格式，一部分是RDB文件内容格式，另外的才是AOF文件的内容格式。

3.缓存淘汰策略：

当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 。会让 Redis 的性能急剧下降，对于访问量比较频繁的 Redis 来说，这样存取效率基本上等于不可用。

在生产环境中我们是不允许 Redis 出现交换行为的，为了限制最大使用内存，Redis 提供了配置参数 maxmemory 来限制内存超出期望大小。

当实际内存超出 maxmemory 时，Redis 提供了几种可选策略 (maxmemory-policy) 来让用户自己决定该如何腾出新的空间以继续提供读写服务。

noeviction 不会继续处理写请求 (del,read请求可以继续进行)。这样可以保证不会丢失数据，但是会让线上的写相关的业务不能持续进行。这是默认的淘汰策略。

volatile-lru 尝试淘汰设置了过期时间的 key，最少使用的 key 优先被淘汰。没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。

volatile-ttl 跟上面一样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。

volatile-random 跟上面一样，不过淘汰的 key 是过期 key 集合中随机的 key。

allkeys-lru 区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不只是过期的 key 集合。这意味着没有设置过期时间的 key 也会被淘汰。

allkeys-random 跟上面一样，不过淘汰的策略是随机的 key。

volatile-xxx 策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的 key 进行淘汰。如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。