今天我们来学习一下Redis相关的内容，相信作为一名优秀的程序员，我们对Redis肯定不陌生，所以就不多废话了，我们直接来开干，首先准备一台虚拟机，这里我是用的是CentOS7的环境，准备好了之后我们准备好安装包，并上传至虚拟机
我们都知道，redis是使用C语言编写的，因此我们在安装之前需要检查一下gcc的编译环境，如果没有的话，就需要使用yum install -y gcc-c++ 命令进行安装
好了，安装完成之后我们解压redis的包，进入解压目录，修改一下src目录下的MakeFile这个文件，让redis编译到指定的目录，这里不修改也可以，只是我的强迫症在作祟、每次看到一堆乱的文件就很难受。
这里我是指定到了 /usr/local/redis 路径下了
好了，接下来我们就可以先来使用make命令编译了，编译完成之后的信息如下：
终端上会有一条提示信息，告诉我i们运行一下make test是个good idea ,emmmm.......这里是不是一个good idea 我不清楚，但是我运行了之后很久都没退出来，浪费了一上时间吧，这里大家学习的话不运行也没事，但是生产环境上部署的话可以试着运行一个测试。好了，这里我们就忽略text。我们接下来直接使用make install 命令进行安装。安装完成之后如下图所示：
好吧，这家伙仍然提示make test，我们先不管这个，我们直接来到/usr/local/redis目录下，我们发出现已经安装好了
接下来我们试试能不能启动起来
好了，说明我们的安装 的没问题。但是我们一般在使用的时候需要指定一个配置文件，通过该配置文件进行后台启动。下面我们来看看怎么通过配置文件的形式进行后台启动，我先将redis解压目录下的redis.conf文件复制一份到安装目录下，
接着我们到安装目录下，查看一下配置文件的内容，我们现主要修改一下几个地方
上述的配置意思分别是指定redis的工作目录是/usr/local/redis 输出的日志写入文件/usr/local/redis/redis.log。允许后台启动
好了，配置完成之后我们可以保存退出了 。
我们要想后台启动redis的时候我们就需要使用到这个配制文件，语法是 redis-server文件路径 redis.conf文件路径。但是有时候命令太长了，写起来很不方便，于是我们可以在redis.conf目录下直接使用 redis-server redis.conf命令执行，
如果发现上述错误信息，就需要创建一个软连接，命令如下： ln -s /usr/local/redis/bin/redis-server /usr/bin/redis-server。路径需根据具自己的实际路径修改。
修改完成之后我们继续运行上述命令即可启动redis服务了，启动之后我们可以使用redis-cli 命令来连接一下服务端(同样的建议创建一个软连接，方便操作)
连接上之后我们输入一个ping指令，如果返回了一个PONG字符串，说明我们的客户端和服务端的链接是正常的。如下图所示：
好了，Redis的安装我们已经完成了。
接下来我们回忆下下Redis的5中基本的数据结构。String 、List 、Hash、 Set、Zset。我们最熟悉的肯定是String了,关于String类型大家只需要知道个字符串值的最大容量是512M，该类型可以存任何数据，包括图片文件以及序列化的对象。 好了，List是简单的字符串有序列表，按插入的顺序排序，我们需要知道的它是基于链表的数据结构实现的，因此他的特性是操作头尾效率高，操作中间数据效率偏低。至于Set是一个无序集合，底层使用哈希表来实现。HashSet就是类似我们在Java中使用的HsahMap，是以键值对存在的。最后一种Zset的类型相对于前4中就要稍微的复杂了一些、他和Set一样也是和用来存储String 类型的字符串，无序且不能重复，不同的是每个元素都关联了一个分数。zset可以根据这个分数来给元素排序，需要注意的是分数可以重复。以上就是Redis支持的5种数据类型。关于基本的操作这里不做过多的介绍。下面我们来看一下Redis的持久化操作。
我们都知道Redis是将数据存储在内存中，因此数据的读写速度非常的快，快到什么程度大家可以使用redis-benchmark测试一下：
从上图中我们就可以看到Redis的读写速度了，很快，但是数据全部都是在内存里。这样的话如果机器突然断电或者因为某种原因宕机的话数据全部丢失了，出于这种原因Redis提供了持久化的功能，相信大家也并不陌生，主要分为 两种模式，RDB和AOF。前者是指定时间来持久化一次内存中的数据，后者是根据指定分策略将操作的命令记录到一个文件中。
我们接着回到配置文件中，会发现有一个地方配置的信息如下：
这里就是RDB的默认配置，其含义是 900秒内至少有一次修改则触发保存操作 300秒内10次修改触发保存 60秒内10000次修改触发保存。接着我们可以看到一下这行配置，这个就是RDB持久化之后的文件，当Redis下一次启动的时候就会加载该配置文件。
这里我们需要注意的是RDB的触发时机，主要有以下几个
1、默认配置
2、执行save 或者bgsave
3、执行了flushall命令
4、正常的使用shutdown命令退出redis
好了，我们可以想一下RDB模式是否可以真的保证数据万无一失。
接下来，我们来看一下另外一种持久化的机制AOF，我们回到配置文件中发现有以下配置：
AOF默认是关闭的状态，如果来开启的话就需要将上述no修改成yes 然后制定文件的名字，这种持久化的机制主要是记住运行产生数据的命令，需要注意的是对于一些重复的命令，为了节约时间，通常会有一种AOF重写的机制，但是该机制会影响程序运行的效率占用cpu资源。
需要注意的是当AOF持久化文件损坏了的时候，redis读取了损坏的文件之后会导致启动失败，因此需要对文件进行修复，我们使用 redis-check-aof --fix appendonly.aof 命令进行修复。
好了，我们接下来聊一下这两种持久化的方式各自的优缺点吧，
RDB的优缺点：
适合大规模的数据恢复，速度较快
会丢失最后一次快照后的所有修改，不能绝对保证数据的高度一致性和完整性。
AOF的优缺点：
选择appendfsync always方式运行时理论上能够做到数据完整一致，但此时性能又不好。文件内容具备一定可读性，能够用来分析Redis工作情况。
持久化相同的数据，文件体积比RDB大，恢复速度比RDB慢。效率在同步写入时低于RDB，不同步写入时与RDB相同。
好了，上述就是这两种方式的一个比对，大家在使用的时候可以根据自己的实际情况做出合适的策略。
接下来我们来聊一聊事务，在Redis中有一组命令是关于事务控制的。MULTI表示开始收集命令，后面所有命令都不是马上执行，而是加入到一个队列中。 EXEC执行MULTI后面命令队列中的所有命令。DISCARD放弃执行队列中的命令WATCH“观察“、”监控“一个KEY，在当前队列外的其他命令操作这个KEY时，放弃执行自己队列的命令UNWATCH放弃监控一个KEY。
我们来试试这个；
假如我们在开启了multi的情况下，编写了一条错误的命令，即使即可更正了，但是同样的也是不能提交的，也就是说一系列的操作全部都不生效。再来看看下面这种情况：
我们发现再出错的地方并不会回滚整个一系列的操作，而是停留在出错的那条指令之前。
关于Redis的事务大家需要明确一点，这家伙不可靠，因此在开发的过程中，我们一定不能使用Redis的事务的，关于这个问题，Redis官方因为做过相应的解释，感兴趣的可以取官网了解。这里不做过多的解释。
好了今天主要就给大家介绍下这些，明天继续给大家分享Redis的集群部署。大家晚安！