Redis基础知识总结概述

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。 --------出自百度百科

redis是属于非关系型数据库，其实呢它只是一种结构化储存方法的集合，储存结构就是key-value，说到redis就不得不提memcache，两者区别就在于memcache是纯内存的数据库而redis是内存+磁盘，从redis3.0之后集群技术就相对成熟了，可以用于生产环境。

综上可以简单总结redis是内存数据库，基于key-velue储存数据，支持持久存储，支持事务，支持主从，支持cluster（集群）。 redis官网：redis.io，redis命令参考手册：http://redisdoc.com 手册中详细解释并演示了命令的使用。

yum安装redis

[root@BIGBOSS local]# yum install redis -y
[root@BIGBOSS local]# rpm -q redis
redis-3.2.12-1.el7.x86_64
# 启动并检查
[root@BIGBOSS local]# systemctl start redis
[root@BIGBOSS local]# ss -tnl |grep 6379
LISTEN     0      128    127.0.0.1:6379                     *:*
# 此时并没有配置端口和密码可以直接连接
[root@BIGBOSS ~]# redis-cli
127.0.0.1:6379>

保护模式

早期redis试运行在内网环境中的，是没有烤炉安全认证问题的，也就是说只要服务启动了任何人都能访问redis中的数据，但是后来有了云，有人就把redis用在云环境中，而且把监听的IP设置成了0.0.0.0，所以就出现了安全漏洞，容易被人黑，从3.2开始就增加了一个认证的特性protected-mode yes但是只这一条还是不行的，还需要添加一条密码 requirepass 12345。

配置文件如下

[root@BIGBOSS ~]# vim /etc/redis.conf
protected-mode yes
bind 0.0.0.0
requirepass 12345

重启服务登录测试

[root@BIGBOSS ~]# systemctl restart redis
[root@BIGBOSS ~]# redis-cli      >>>当执行这个命令的时候能登陆
127.0.0.1:6379> set name tom
(error) NOAUTH Authentication required. >>> 但是执行命令的时候会提示没有权限

认证方式如下

127.0.0.1:6379> auth 12345    >>>做认证
OK
127.0.0.1:6379> set name tom
OK                            >>>认证后就能执行命令了

redis的应用场景

数据缓存：提高访问性能
session共享：会话保持
做为计数器：nginx+lua+redis实现计数器，实现ip的自动封禁。
消息队列：构建实时消息系统，聊天、群聊

redis的持久化储存

redis不同于memcahed的地方就是他的数据不仅在内存中也存在于磁盘上，而将数据从内存中保存到磁盘上就叫做数据的持久化储存。
数据持久化的两种机制：RDB、AOF
RDB可以每个一段时间进行一次持久化，并且是基于快照的方式实现的。储存文件的位置/var/lib/redis下。

AOF的持久化，就是借助一个日志文件，这个日志文件只记录所执行的写的命令，不会记录读命令，再重启服务器的时候，如果会九华数据中没有，就会去都取日志中的内容进行重写操作。

一般在使用持久化的是我们都是两种方式结合使用，当然也可以只是用其中一个，或者禁用持久化功能。

redis中的数据类型

字符串类型：可以是字符串，也可以是数字
哈希（hash）类型：redis中的hash其实就是键值对的集合
列表（list）类型：列表中的元素是有顺序的，列表中匀速是从0开始的，列表其实是双向的（左L 右R）
集合类型：有序集合类型，无序集合类型

redis中的消息模式

队列模式
在列队模式中其实就是每次插入数据都是载入在最前面的，而先插入的数据在后面，列表中始终维持了一个队列所以称之为队列模式。

10.220.5.171:6379> lpush  list1 q1
(integer) 1
10.220.5.171:6379> lpush  list1 q2
(integer) 2
10.220.5.171:6379> lpush  list1 q3
(integer) 3
10.220.5.171:6379> lpush  list1 q4
(integer) 4
10.220.5.171:6379> lrange list1 0 10
1) "q4"
2) "q3"
3) "q2"
4) "q1"

发布-订阅模式
发布-订阅模式下，每个消息被广播到所有消费者中

resis中的事务

事务的隔离性：每个事务都是一个隔离的操作，事务中所有的命令都会按照顺序执行，并且执行过程不会被其他事物打断。
原子性：事务中的明亮要么都执行，要么都不执行。

redis使用事务的过程：

启动事务（MULTI）
写入要执行的操作
执行事务（EXEC）

演示事务：模拟场景tom银行卡里有3000元，jerry银行卡中有5000元，jerry给tom转账1000元，结果是两人卡中都为4000元。

创建一个有序集合叫做salary，tom的值为3000，jerry得知为5000

127.0.0.1:6379> zadd selary 3000 tom
(integer) 1
127.0.0.1:6379> zadd selary 5000 jerry
(integer) 1
127.0.0.1:6379> zrange selary 0 10 withscores
1) "tom"
2) "3000"
3) "jerry"
4) "5000"

使用事务完成转账

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> ZINCRBY selary 1000 tom
QUEUED                              >>>操作并没有被执行而是加入到了队列中
127.0.0.1:6379> ZINCRBY selary -1000 jerry
QUEUED                              >>>操作并没有被执行而是加入到了队列中
127.0.0.1:6379> EXEC                >>>执行事务队列中的操作
1) "4000"
2) "4000"
127.0.0.1:6379> ZRANGE selary 0 10 WITHSCORES
1) "jerry"
2) "4000"
3) "tom"
4) "4000"

注意：如果不使用事务如下，当执行完ZINCRBY selary 1000 tom的操作，tom的账户里已经是4000了，此时jerry的账户里仍有5000，那么这1000是从哪里来的呢？很明显这种不使用事务的操作会带来数据不一致的问题

127.0.0.1:6379> ZINCRBY selary 1000 tom
"4000"
127.0.0.1:6379> ZINCRBY selary -1000 jerry
"4000"
127.0.0.1:6379> ZRANGE selary 0 10 withscores
1) "jerry"
2) "4000"
3) "tom"
4) "4000"

慢日志查询

慢日志主要依靠两个变量来设置

slowlog-log-slower-than：指定面日志查询的时间，单位是毫秒
slowlog-max-len：指定最多纪录多少条慢日志

慢日志的设定可以再配置文件中修改，也可以直接在命令行修改参数，但是在命令行修改只是修改内存中的但能立即生效，想要永久生效需要修改配置文件。

本博文中提到的有些概念并没有进行深入的剖析，知识做了整体的概述，后续博文中会有更详细的讲解。

------做运维之前很矫情的小年轻-----