[TOC]

一、Redis介绍

redis是一种基于键值对（key-value）数据库，其中value可以为string、hash、list、set、zset等多种数据结构，可以满足很多应用场景。还提供了键过期，发布订阅，事务，流水线，等附加功能

二、Redis特性

1 速度快
2 键值对的数据结构服务器
3 丰富的功能
4 简单稳定
5 持久化
6 主从复制
8 高可用和分布式转移
9 客户端语言多

三、使用场景

1 缓存数据库
2 排行榜
3 计数器应用
4 社交网络
5 消息队列

四、数据类型

1.String

字符串类型是redis最基础的数据结构，首先键是字符串类型，而且其他几种结构都是在字符串类型基础上构建的，所以字符串类型能为其他四种数据结构的学习尊定基础。

字符串类型实际上可以是字符串（简单的字符串、复杂的字符串（xml、json）、数字（整数、浮点数）、二进制（图片、音频、视频）），但最大不能超过512M。

使用实例：

redis 127.0.0.1:6379> SET name "runoob"
OK
redis 127.0.0.1:6379> GET name
"runoob"

使用场景：

缓存功能：字符串最经典的使用场景，redis最为缓存层，Mysql作为储存层，绝大部分请求数据都是 redis中获取，由于redis具有支撑高并发特性，所以缓存通常能起到加速读写和降低后端压力的作用。

计数器：许多运用都会使用redis作为计数的基础工具，他可以实现快速计数、查询缓存的功能，同时数据可以一步落地到其他的数据源。如：视频播放数系统就是使用redis作为视频播放数计数的基础组件。

共享session：出于负载均衡的考虑，分布式服务会将用户信息的访问均衡到不同服务器上，用户刷新一次访问可能会需要重新登录，为避免这个问题可以用redis将用户session集中管理，在这种模式下只要保证redis的高可用和扩展性的，每次获取用户更新或查询登录信息都直接从redis中集中获取。

限速：处于安全考虑，每次进行登录时让用户输入手机验证码，为了短信接口不被频繁访问,会限制用户每分钟获取验证码的频率。

2.Hash（哈希）

在redis中哈希类型是指键本身又是一种键值对结构，如value={{field1,value1},......{fieldN,valueN}} 。

Redis hash 是一个键值(key=>value)对集合。

Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

每个 hash 可以存储 232 -1 键值对（40多亿）

使用实例

redis> HMSET myhash field1 "Hello" field2 "World"
"OK"
redis> HGET myhash field1
"Hello"
redis> HGET myhash field2
"World"

使用场景

哈希结构相对于字符串序列化缓存信息更加直观，并且在更新操作上更加便捷。所以常常用于用户信息等管理，但是哈希类型和关系型数据库有所不同，哈希类型是稀疏的，而关系型数据库是完全结构化的，关系型数据库可以做复杂的关系查询，而redis去模拟关系型复杂查询，开发困难，维护成本高。

3.List（列表）

列表类型是用来储存多个有序的字符串，列表中的每个字符串成为元素（element）,一个列表最多可以储存 2的32次方-1个元素，在redis中，可以队列表两端插入（pubsh）和弹出（pop），还可以获取指定范围的元素列表、获取指定索引下表的元素等，列表是一种比较灵活的数据结构，它可以充当栈和队列的角色，实际开发中有很多应用场景。

列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。

使用实例：

redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

使用场景

消息对列： redis的lpush+brpop命令组合即可实现阻塞队列，生产者客户端是用lupsh从列表左侧插入元素，多个消费者客户端使用brpop命令阻塞时的“抢”列表尾部的元素，多个客户端保证了消费的负载均衡和高可用性

文章列表：每个用户都有属于自己的文章列表，现在需要分页展示文章列表，此时可以考虑使用列表，列表不但有序，同时支持按照索引范围获取元素。

使用技巧：

lpush+lpop=Stack(栈)
lpush+rpop=Queue（队列）
lpush+ltrim=Capped Collection（有限集合）
lpush+brpop=Message Queue（消息队列）

4.Set （集合）

集合类型也是用来保存多个字符串的元素，但和列表不同的是集合中不允许有重复的元素，并且集合中的元素是无序的，不能通过索引下标获取元素，redis除了支持集合内的增删改查，同时还支持多个集合取交集、并集、差集，并合理的使用好集合类型，能在实际开发中解决很多实际问题。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

集合中最大的成员数为 232 - 1(4294967295, 每个集合可存储40多亿个成员)。

使用实例：

redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob

1) "redis"
2) "rabitmq"
3) "mongodb"

使用场景

标签（tag）：集合类型比较典型的使用场景，如一个用户对娱乐、体育比较感兴趣，另一个可能对新闻感兴趣，这些兴趣就是标签，有了这些数据就可以得到同一标签的人，以及用户的共同爱好的标签，这些数据对于用户体验以及曾强用户粘度比较重要。（用户和标签的关系维护应该放在一个事物内执行，防止部分命令失败造成数据不一致）

其他
sadd=tagging（标签）
spop/srandmember=random item（生成随机数，比如抽奖）
sadd+sinter=social Graph(社交需求)

5.Zset(sorted set：有序集合)

有序集合和集合有着必然的联系，他保留了集合不能有重复成员的特性，但不同得是，有序集合中的元素是可以排序的，但是它和列表的使用索引下标作为排序依据不同的是，它给每个元素设置一个分数，作为排序的依据。（有序集合中的元素不可以重复，但是csore可以重复，就和一个班里的同学学号不能重复，但考试成绩可以相同）。

使用实例

redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"

使用场景

排行榜：有序集合经典使用场景。例如视频网站需要对用户上传的视频做排行榜，榜单维护可能是多方面：按照时间、按照播放量、按照获得的赞数等。

不同类型比较

五、发布与订阅功能

redis提供了“发布、订阅”模式的消息机制，其中消息订阅者与发布者不直接通信，发布者向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以接收到消息。

redis主要提供发布消息、订阅频道、取消订阅以及按照模式订阅和取消订阅。

1.发布与订阅命令

发布消息

publish channel:test "hello world

订阅消息

subscrible channel:test

查看订阅数

pubsub numsub channel:test

取消订阅

unsubscribe channel:test

按模式订阅和按模式取消订阅

psubscribe ch* 

punsubscribe ch*

2.使用场景

1、今日头条订阅号、微信订阅公众号、新浪微博关注、邮件订阅系统
2、即使通信系统
3、群聊部落系统（微信群）

六、 Redis持久化

redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化，持久化可以避免因进程退出而造成数据丢失。

1.持久化方式

RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发。

手动触发

save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它.

bgsave命令：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave

自动触发

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决开启：redis.conf设置：appendonly yes (默认不开启，为no) 默认文件名：appendfilename "appendonly.aof"

2.bgSave 运行流程

运行流程示意图如下：

3.RDB文件的操作

设置RDB的文件保存路径

config set dir /usr/local   # 将dump.rd 保存到/usr/local/目录下

开始持久化数据

bgsave

恢复数据

将dump.rdb放到redis安装目录与redis.conf同级目录，重启redis即可

优点：

1.压缩后的二进制文，适用于备份、全量复制，用于灾难恢复
2.载RDB恢复数据远快于AOF方式

缺点：

1.无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2.保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题.

4.AOF持久化

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决

开始持久化

redis.conf设置：appendonly yes (默认不开启，为no)
默认文件名：appendfilename "appendonly.aof"

AOF持久化流程

1.所有的写入命令(set hset)会append追加到aof_buf缓冲区中

2.AOF缓冲区向硬盘做sync同步

3.随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩

4.当redis服务重启，可load加载AOF文件进行恢复

命令写入(append), 文件同步(sync), 文件重写(rewrite), 重启加载(load)

AOF配置参数详解

appendonly yes           //启用aof持久化方式
#appendfsync always      //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec    //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐
#appendfsync no         //完全依赖os，性能最好,持久化没保证（操作系统自身的同步）
no-appendfsync-on-rewrite  yes  //正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100  //aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb   //aof文件,至少超过64M时,重写

AOF恢复

1.设置appendonly yes
2.将appendonly.aof放到dir参数指定的目录
3.启动Redis，Redis会自动加载appendonly.aof文件

AOF与RDB的加载顺序

1.当AOF和RDB文件同时存在时，优先加载AOF
2.若关闭了AOF，加载RDB文件
3.加载AOF/RDB成功，redis重启成功
4.AOF/RDB存在错误，启动失败打印错误信息