目录
前言：
环境安装和配置文件
通用命令
Redis的过期策略
前言：
前文我们对于分布式系统有了一个简单的认识，并且我们理解Redis的作用可以用来当作缓存热点数据，并且可以作为消息队列的中间件，不过用在中间件的时候其实是Redis的初心，到了后面有了更多的，更加优质的中间件作为消息队列的，所以Redis可能征战其他的战场更加合适了。
比如热点数据的缓存，比如基于Redis做一个分布式锁之内的，并且我们还通过分布式系统对微服务有了一个简单的认识，微服务就是把一个业务拆分成了许多不同的小点，比如对于MySQL中的表，我们可以利用微服务，引入多个服务器，并且每个服务器解决每个小业务，就像服务器A处理某个库中的某个表，B处理另一个表，所以微服务出来之后是基于分库分表的操作。
所以现在我们简单的总结一下分布式系统，我们从单机架构，到了引入多台服务器，然后引入负载均衡的概念将请求比较均匀的分发给集群中的每个应用服务器，接着我们发现应用服务器的压力减轻了，但是数据库的压力变的很大了，所以引入了读写分离的操作，可是发现读的频率是远远大于写的频率的，那么我们就引入了缓存的概念，并且用Redis作为缓存来使用，借助Redis快的特点，我们就可以解决冷热数据的读取问题，最后引入了微服务，即分库分表的概念。
现在，我们就了解了Redis的背景，然后就应该讨论Redis的环境安装以及通用命令的使用了，话不多说，直接进入正题吧！
环境安装和配置文件
因为笔者使用的是Ubuntu环境，所以环境安装使用进行介绍的是Ubuntu下如何安装的，我们首先切换到root下，因为安装东西那些我们都是要管理员权限的。
首先，我们可以apt search redis查看有哪些Redis安装包：
我们可以看到有这么多的东西，当然，笔者只截图了部分，实际上是非常多的，而我们要安装的就是redis，后面没有带任何东西的那种，它后面带的是版本，我们考虑的版本是5或者6，因为7版本安装起来相对比较麻烦。
那么我们直接apt install redis就可以了。
安装好了之后，我们需要修改一下配置文件，因为当我们查看运行的网络服务的时候：
啊……这里比较尴尬，因为笔者已经把Redis的配置文件修改了，如果没有修改的，会发现在tcp这里显示的是127.0.0.1的，这是本地环回的，不过问题来了，如果IP地址显示的是本地环回的，那么意味着我们没有办法跨主机访问，因为Ip地址只有自己的，所以我们需要修改配置文件为上面的。
这个点其实非常的像网络通信中服务端的家族簇设置为INET_ANY。接受任意的IP地址的访问嘛，有意思的是，其实这里我们差了一个东西，如果Redis只是一个单机程序，我们就完全不用担心网络通信的问题。
不过我们要记住的点是，Redis快，是因为Redis基于网络通信，访问内存中的数据，这个肯定是比直接修改硬盘里面的数据快的，而且还有几个点，咱们就当延申一下，Redis虽然是单线程，但是它处理问题都是在内存上处理的，既然是内存级别的处理，所以快，并且我们从网络角度来看，它是采取了IO多路复用的方式，即使用一个线程，管理多个Socket，而且它操作的都是简单数据结构，不至于说是那种非常复杂的数据结构，这也是一个快的原因。
好了，我们现在就修改一下配置文件，对于配置文件我们要修改两个点，首先进入到/etc/redis：
我们要修改的就是redis.conf的这个文件内容。
修改两个点，一个是bind后面全部改成0.0.0.0 并且后面的protected-mode修改为no。
第一个点我们能理解，第二个是因为如果我们没有配置对应的IP或者设置对应的密码，它的这个功能可能就不让我们连接Redis了，因为我们目前只是用来本地学习，所以就不用管那么多了。
然后我们重启一下服务器就可以了：service redis-server restart。
之后，我们就可以成功的连接上客户端了：redis-cli。
到这里，我们需要清楚，Redis它也是一个结构化的客户端和服务端的程序们，这里是和MySQL一摸一样的。
既然是分为了CS，目前来说我们的CS都在一台机器上，那么也有客户端和服务端不在一个机器上的，而Redis服务器，也就是Redis的本体负责存储和管理数据，Redis客户端就是用来请求和响应某些需求的了。
对于Redis的客户端可以有很多的界面，可以是命令行客户端，也可以是图形化界面客户端，但是老实说，对于图形化客户端来说，较为依赖Windows系统，而实际开发中，几乎没有使用Windows系统来使用Redis的，连接上就会有较多问题，所以~~咱们就了解了解。
通用命令
好了，进入到了Redis的实战部分了，咱们叭叭了这么多，也是终于能写上一点内容了，首先，我们学习的第一组命令是get和set，它们是最重要也是最为基础的。
get/set
因为redis是基于键值对存储的，所以get就是获取values值，set就是设置键值对，就像这样：
使用set的时候，我们也是难得的发现它有对应的提示了，在命令行客户端也是不容易了哈哈哈，那么根据提示，我们发现只需要整上对应的key value就可以了：
到这里我们也是惊奇的发现似乎就有覆盖的功能？那么这个猜测我们先保留，毕竟目前的现象是这样的。
所以也是非常简单，不过既然是设置键值对，对于key来说，它的类型是雷打不动的字符串类型，对于value类型就有很多了，比如字符串，列表，集合，哈希表等类型。
那么既然key是固定的字符串类型，我们为什么不带引号也可以？可以就是可以啦，所以我们后面看自己喜好带不带引号了。
到这里，我们如果会查阅官方文档的话，我们也会发现对于官方对于命令来说一般是大写的，这点和MySQL一样，Redis是不区分大小写的，所以我们平常也是根据自己的喜好来写命令。
keys命令
对于这个命令来说，就像是一个查询命令，它可以搭配一些特殊符号，比如通配符来使用。
为了方便测试，我们先加入一些键值对来测试：
对于keys命令，我们可以这样使用：
使用*，*代表任何字符，有0个或者多个字符都可以。
使用?，?代表一个字符，只能找一个字符的：
使用[]，方括号里面的代表要找的元素：
同样使用[]，方括号里面加^，就代表不要这些元素：
同样使用[]，[a-c]，代表从英文字母a到c挨个匹配：
这是keys的基本使用，你要说死记硬背呢，实在没必要，咱们用多了也就熟悉了。
而我们要注意的一个点是keys的时间复杂度是O(N)因为它需要一个一个的去遍历字符串，那么它的效率肯定就不高了。
所以这里我们可以延申出一个话题是：key *是否危险？
答案是在生产环境中相当的危险，因为生产环境是用户可以访问到的，而一旦我们使用了key *我们就相当于要对所有的数据遍历，那么因为Redis是单线程的，所以有执行这个命令结束之前是不能执行其他命令的，那么因为Redis用于缓存数据的访问是常见的，如果Redis被阻塞了，那么热点数据只能从MySQL中来，而一旦大量的数据冲了MySQL，MySQL很大概率崩，那么对于整个公司的影响是非常大的，所以在生产环境几乎是禁止key *这条命令的。
exists命令
这个命令非常的简单，用来判断key是否存在:
但是本文的重点不是这里，你说我们是一次性请求多个数据还是一次一次的请求好呢？
首先我们要明白一个点是Redis是单线程的，那么我们作为客户端访问服务端的时候，用的是网络通信吧？通信两次的成本比一次大吧？
大的原因咱也不细说了，封装知道吧？分用知道吧？路由知道吧？更何况主机的距离还是一个未知数，所以Redis也意识到了这个问题，那么就肯定要做出解决，也就是一次性可以处理多个数据。
del命令
删除命令嘛，也是一样的，可以一次性删除多个数据，没有什么好说的，不过有同学疑惑的点是，在MySQL中，我们常常说到，删除操作是非常危险的，最好不要轻易删除。
那么在Redis里面好像对于删除没有多大的危害？因为对于Redis来说，它缓存的是热点数据，也就是该数据是可以在MySQL中找到的，并且MySQL中存储的是全量数据，你删除缓存数据没有什么实际的影响。
可是如果，Redis删除的缓存数据多了，访问不到了，那么大多数请求直冲MySQL，这就很难受了，可能会导致MySQL崩溃进而系统瘫痪。
或者说Redis作为数据库的时候，也就是它存放的是全量数据的时候，也是不能轻易删除的，同样会导致崩溃。
所以del的危害我们还是要根据情况来看的~
expire和ttl命令
既然是热点数据，那么它要是冷下来了，我们是不是就不用缓存了？甚至说我们可以给这个数据删除了，比如验证码，它一般有一个使用期限，比如5分钟什么的。
那么expire就是用来给某个key设置过期时间的，如果超过了这个时间，这个键值对就删除了，ttl的全程是time to live，也就是存活时间，我们结合使用看看：
我们给abc设置了10秒的过期时间，过期了之后，就发现时间为-2，也就是说已经过期了，并且把该key删除了，如果返回的是-1是代表key存在，但是没有设置过期时间：
就像这样。
type命令
对于type命令就是用来查询key的类型是什么，就像C++语言里面的typeid或者是decltype：
像这样。
Redis的过期策略
对于Redis的过期策略也是一个经久不衰的老话题了，一般别人都会问你什么是过期策略？
首先我们要知道是什么引出了过期策略的这个问题：
如果redis中存在了很多很多key，这里面有的key是快要过期的，有的是已经过期的，有的没有过期的，对于Redis来说怎么知道哪些过期了哪些没有过期的呢？
有的同学会这样想，那这不非常简单嘛，我遍历一遍就可以了，可是你要知道，key *这么危险的原因就是因为它会遍历整个数据，从而导致MySQL崩溃，即便就是不崩，查询的时间你如何和过期的时间相互平衡呢？
所以对于Redis来说，过期策略需要好好斟酌。
那么牛逼的大佬们想出来了两种策略，一种是惰性删除一种是定期删除
对于惰性删除来说，就是key已经过期了，但是Redis还不知道，随着下次访问的时候，咱们发现key过期了，那么就删除，并且给客户说，它不存在了。
这个就像老板卖给你方便面，你拿到手发现过期了，给老板说，老板说：哦！它过期了，那不卖给你了。就是这种感觉。
对于定期删除来说，就是每次抽取一部分，快速验证过期时间，并且要保证这个快速是非常非常快的，不然Redis就会堵塞，主要还是为了保证单线程能够正常运行。
那么实际运行中一般都是结合惰性删除和定期删除一起的，这样效率更高嘛。
当然了，在网上还有一种说法是定时器，即为每个key创建一个定时器，如果定时器响了就删除key，但是这个想法并没有被采用，可能是因为引入定时器的话就要引入多线程，用另一个线程来管理这个定时器的基本逻辑了。这就违背了Redis是单线程的初衷了。
那么是否没有好的定时器方案供Redis选择呢？当然是有的。
基于时间轮转实现定时器的功能和利用优先级堆或者队列来实现定时的功能。
基于时间轮转是这样的：
我们将一段循环分为多个时间片，每个时间片上连接链表，每个链表代表一个任务，假设我们指定100秒之后删除某个key，那么我们明显可以根据取模和除法的操作确定它在哪个时间片上，甚至可以确定它在哪个链表上。
这是一个非常高效的方案。
优先级队列或堆：
队列知道吧？我们在队列的基础上，添加一个优先级的属性，谁的优先级高谁就插入到队列中，而对于线程来说，只需要查询队头的优先级代表的属性就可以，在这里我们可以用过期时间来代表优先级，线程只需要查看队头的就可以。
如果来了一个优先级更高的，咱们插入就是了，当过期时间没到的时候，扫描线程就可以休眠，直到系统把它唤醒，也就代表了队头的过期时间要到了，那如果是线程休眠的时候来了新任务，很简单，只需要重新唤醒它再查看一下对头元素就可以了。
当然了，实际的操作远比这个要复杂，我们先有一个简单的认识就可以了。
以上就是Redis的基本认识Plus和Redis的通用命令。
感谢阅读！