一.预备知识
1.基本全局命令
set key value 将key的值设置成value
get key 得到key的值
keys [pattern] 查看匹配pattern的所有key
比如h?llo匹配hallo，hbllo，hcllo……只要用一个符号将？代替即可
比如h*llo匹配hllo，heeeello……用0个1个或多个字符将*代替即可
比如h[ae]llo匹配hallo，hello只有这两个
比如h[a-e]llo匹配hallo，hbllo，hcllo，hdllo，hello这五个
比如h[^e]llo表示除e之外的字母都匹
那keys * 则可以获取到任何key
keys命令的时间复杂度是O(N)所以在生产环境上一般禁止使用keys，尤其是大杀器 keys *。因为生产环境上的key一般非常非常多，而Redis又是一个单线程服务器，执行keys*的时间就会非常长，就会使redis服务器阻塞住，无法给其他命令/其他客户端使用。
就像一个妹纸同时交了三个男友，同时与三个男友周旋，如果在同一时间三个男友都要约会，就周旋不过来了。
而且Redis经常被当作缓存，替mysql负重前行。一旦redis被keys *给阻塞住了，那么美其他查询redis的命令就超时了，就会直接访问mysql。突然一大波请求发送过来，mysql就会措手不及，容易挂了
exists key [key……] 判断指定的key是否存在
返回值是存在的key的个数
这个命令的时间复杂度是O(1)，因为Redis组织这些key-value键值对是按照hash表的方式来组织的，每次找一个key都是O(1)，所以当key特别多时，时间复杂度就成了O(N),N指的是key的个数。
exists key1 exists key2 与exists key1 key2 达到的效果相同，但实际上差别很大，因为Redis是客户端与服务器之间通过网络进行通信的，第一种查询方式会产生更多轮次的网络通信，这与直接操作内存比的话，效率更低，成本更高。
因为每次网络通信都涉及到封装分用：进行网络通信时，发送放发送一个数据，这个数据就要从应用层到物理层，层层封装（即每一层协议都要加上报头报尾），就像抱一个快递要包很多层。接收方收到后，这个数据就要从物理层到应用层，层层分用（也就是拆快递）
del key [key^] 删除指定的key
返回值是成功删除掉的key的个数
时间复杂度是O(1)。其实还是和exists一样，有几个key就是O几的时间复杂度
我们知道在MySQL中删除数据是很危险的操作，那么del在redis中是不是危险操作呢？
当redis作为缓存存储热点数据时，由于全量数据依然安安全全的在MySQL中，所以redis这里误删了几个数据没有太大影响，只要通过mysql再把数据给映射到redis就可以了。不过要是突然一下子一大半热点数据，redis就大概率无法替mysql负重前行了，就可能使得很多的请求突然到了MySQL那里，可能会导致MySQL挂掉。
当redis作为MQ（消息队列）时，影响程度就要分情况来看了
当redis代替mysql作为数据库时，影响就很大啦
expire key seconds 为指定的key添加过期时间
ttl key 查看当前key剩余的时间
如上，过期时间的单位是秒级，当到期时ttl的返回值就是-2
expire的应用场景有很多：比如点外卖，优惠券在指定时间内有效；比如手机验证码的有效时间；比如分布式锁的实现，有多种实现方式，其中redis就是一种（所谓redis实现分布式锁，其实就是给redis加一个特殊的key-value，把它删了就是解锁），为了避免不能正确解锁的情况，redis就会给锁设置过期时间。
pexpire key也是设定过期时间，不过它的单位是毫秒
注意，当expire和pexpire后面的key不存在时，返回值就是0
ttl key 查看当前key剩余的时间
ttl获取指定key的过期时间，它的单位也是秒级，ttl即Time To Live
当没有关联过期时间时，它的返回值就是-1，当key不存在时，它的返回值就是-2
在IP协议的报头也有一个ttl，但那个TTL不是用时间来衡量过期的，而是用次数
Redis的过期策略如何实现？
一个Redis中存在很多key，这些key中可能大部分都有过期时间，此时redis服务器咋知道那些key过期了？
redis的整体策略就是定期删除和惰性删除。惰性删除就是当key到期时，先不删，紧接着后面又访问到的时候redis就发现这个key过期了，再把它删了，同时返回nil；而上述过程也要结和定期删除，就是每次抽取一小部分key，看看有没有到期的，有的话就删了。（只取一小部分就能够保证这个抽取检查的过程足够快，防止redis线程阻塞）。
为啥对于定期删除的时间有明确规定？因为redis时单线程程序，它主要的任务（处理命令，扫描过期的key……）都是在一个线程中执行的，如果扫描key这个操作消耗的时间太多或这个操作太频繁，就会影响其他命令执行，就可能达到和keys*一样的效果.
虽然有了上述两种策略，但整体效果还是一般，仍然会有key没能及时删除。因此redis也提供了一系列内存淘汰策略（这个以后会讲到）
注意，redis没有使用定时器的策略来实现过期key的删除。但这里我们也简单复习一下定时器的实现
定时器的实现：
1.基于优先级队列/堆
在redis的过期key中，通过”过期时间越早，优先级越高，越先出队列，队首元素，最早过期”的方式实现key的删除。此时定时器秩序分配一个线程，让线程去检查队首元素，看是否过期。但扫描线程检查队首元素的过期时间时，也不能太频繁，否则会出现忙等。此时就可更具队首元素的过期时间设置一个等待时间，当时间差不多了，系统就唤醒线程。这样的话，扫描线程就不用高频率扫描队首元素了，就能省下cpu开销。但万一要是在休眠的时候来了一个新任务要执行该怎么办？那就直接唤醒这个扫描线程，重新检查队首元素，再根据过期时间去重新调整等待时间。如果key特别多，就可以多来几个扫描线程。
当然redis没有采用这个方法，因为redis是单线程程序。
2.基于时间轮实现的定时器
把时间划分成很多很多的小段（划分的粒度看实际需求），把小段分配到一个圆环上，每一个小段都是一个链表，都代表要执行的任务。假设每一个小段代表100毫秒，有一个key是300毫秒后过期，那么他就被添加到第三个小格上。然后指针就会每隔100毫秒向下走一小格，每次走到一个格子就会把这个格子链表上的任务尝试执行一下，看是不是真的到时间了（就比如一个任务是3000ms过期，那么指针就要转好几圈才能执行到）。
对于时间轮来说，一共多少格子，每个格子多长时间，都是可以灵活调配的。但redis也没有采取这个定时器的策略，不过redis源码里面有个比较核心的机制：事件循环，与时间轮优点类似
type key 查看指定key对应的value的数据类型
key不存在时返回null
lpush，sadd，hset等命令会在后面讲到
2.Redis数据结构及内部编码
Redis支持很多数据结构，指的是一个value可以是一些复杂的结构，然而它的这些键值对都是通过hash表的形式来组织的，而且key的类型只能是string类型。在redis官方文档上，列出了12中数据结构，如下，不过我们常用的就是5种：String，List，Set，Hash，Zset(有序集合).
但注意，这些只是redis对外的数据结构，它内部可不一定真的是使用这个结构存储value的：Redis底层在实现上述数据结构时，会在源码层面上，针对上述实现进行特定的优化，来达到节省空间/时间的效果。内部具体实现的数据结构（编码方式），还会有变数。
就比如：redis承诺，现在我这里有关hash表，你进行查询删除插入操作时，都保证O(1)，但是，这背后的实现，可不一定是标准的hash表，可能在特定场景下使用别的数据结构实现，从而保证承诺
String的内部编码： raw，int，embstr
raw：表示最基本的字符串，底层持有一个byte数组
int：当value是一个整数时，redis就会使用int来存储，从而更快实现计数，加减这样的操作
embstr：这个是用来针对短字符串进行特殊优化的。但要是字符串太长，就会使用raw
hash的内部编码：hashtable和ziplist
hashtable：注意，它与java标准库中的hashtable不一样
ziplist：压缩列表，在hash表中的元素较少时，使用ziplist来进行优化，但是当元素很多时，就不能使用ziplist而是使用hashtable。压缩列表能够节省空间，但是它的遍历就会变成顺序遍历（那这样的话还能是O(1)的时间复杂度吗？可以，因为元素很少，遍历起来很快）。
为啥要压缩？redis上有很多key，可能某些key的value是hash类型，此时，若这样的key特别多，那么对应的hash结构就很多，那肯定要占用很多内存空间。但要是每个hash都不大，那就用ziplist尽量去压缩，从而使整体占用的内存空间减小。到这里有人会说，那不应该hash越大，越要压缩吗？注意，节省了空间，那肯定在压缩是有其他开销！！，比如时间……
list的内部编码：linkedlist和ziplist
linkedlist：就是链表
ziplist：压缩链表
但是，这是旧版本的redis的list实现方式，从redis3.2版本开始，list的实现方式是quicklist，它代替了linkedlist和ziplist，兼顾两者的优点。quicklist就是一个链表，每一个节点的元素又是一个ziplist。也就是说，quicklist的空间和效率都折中兼顾了
set的编码方式：hashtable和intset
intset：当集合中都是整数时，就是用intset
zset的编码方式：skiplist和ziplist
skiplist：跳表，每个节点上有多个指针域，巧妙搭配这些指针域的指向，就可以达到查询的时间复杂度为O(log2N)，就近似于二叉平衡搜索树
通过 object encoding key 的命令可以查看指定key的内部编码方式
3.redis的单线程架构
redis只是用一个线程来处理所有的命令和请求，但不是说redis真的只有一个线程，其实它也有多个线程，只不过其他的线程都是在处理网络IO罢了。
假设有两个请求同时要求key自增，那么key最终的结果是加一还是加二呢？
首先回顾一下：在多线程中，自增操作存在线程安全问题，因为自增操作在cpu角度是分成三个指令执行的，它不是原子的，因此可能当两个线程（两个cpu核，共用同一个内存空间）同时要求key自增时，key只自增一次。
redis这里，两个请求同时要求key自增，这也相当于“并行”发起。但是redis服务器这里不会有线程安全问题。因为reids是单线程模型，而不是多线程，这两个请求看似是同时到达redis服务器，但最终还是得在队列里排队，一个一个进行。
redis能使用单线程模型很好的工作，主要是因为redis的核心业务逻辑都是短平快的，不太消耗cpu资源，不太吃多核cpu。
但这样的弊端就是：redis必须要特别小心，若某个操作占用时间特别长，那么就会阻塞其他命令的执行
相关面试题：Redis虽然是单线程模型，但为啥效率这么高，速度这么快？（参照物是数据库）
1.redis访问内存，而数据库访问硬盘
2.redis的核心功能比数据库简单，干的活少，提供的功能比数据库少了不少
3.redis单线程模型，避免了不必要的线程竞争开销。redis每个基本操作都是短平快的，就是简单的操作内存数据结构，不是什么特别消耗cpu的操作，就算是搞个多线程，也没多大意义，提升也不大，甚至可能降低效率
4.redis处理网络IO时，使用了epoll这样的IO多路复用的机制
什么是IO多路复用？就是指一共线程可以管理多个socket。针对TCP来说，服务器这边每次要服务多个客户端，都要给每一个客户端安排一个socket，通过此socket来和客户端进行通信。一个服务器要服务多个客户端，所以自然而然就有多个socket。这些socket难道都是无时无刻不在传输数据吗？当然不是，大多数情况下，这些socket是静默的，上面是没有数据要传输的，也就是说，同一时刻只有少数socket是活跃的。
在以前介绍TCP服务器的时候，有个版本是每个客户端给分配一个线程，这就导致客户端很多时，线程就很多，系统开销就很大。但上面咱们说了大多是线程是不活跃的。所以就可以引入IO多路复用，让一个线程同时去处理多个socket（这是操作系统给程序员提供的机制，即API，内部的功能是操作系统内核实现的。
在linux上，IO多路复用的实现主要是三套API：select，poll，epoll。
什么是epoll呢？好比我们去小吃街买炒饭、肉夹馍和饺子，我们先去让老板做炒饭，在等的过程中去买肉夹馍，再在等的过程中去买饺子。这三份饭，那个先做好了，对应的老板就来喊我，最大限度的节省了时间。这就是epoll，事件通知/回调机制，此时，我一个线程，就同时做了三件事情，但能够同时做这撒气那件事情的前提是这三件事情的交互不太频繁，大部分时间都在等待。
那什么是select呢？那就是老板不喊我，我不停的在三个窗口之间来回跑，问老板饭好了没有
对于IO多路复用，java中使用的是NIO（标准库中提供的一组类，底层封装了epoll）
