Redis基础入门

简介

Redis是一个开源的使用ANSI C语言编写、基于内存亦可持久化的日志型、Key-Value数据库，并提供了对多种编程语言的支持。

Redis的外围由一个键、值映射的字典构成，Redis提供五种数据类型：string，hash，list，set及zset(sorted set)，所以Redis也被称为数据结构服务器。

redis是一个key-value存储系统，支持存储的value类型包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希），这些数据类型都支持push/pop、add/remove及取交集并集和差集等操作，且Redis支持各种不同方式的排序。为了保证效率，数据都是缓存在内存中。redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis支持主从同步，数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。

流水线，Redis 的流水线功能允许客户端一次将多个命令请求发送给服务器，并将被执行的多个命令请求的结果在一个命令回复中全部返回给客户端，使用这个功能可以有效地减少客户端在执行多个命令时需要与服务器进行通信的次数

Redis的特点

Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
Redis是完全在内存中保存数据的数据库，使用磁盘只是为了持久化。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
Redis支持数据的备份，即master-slave模式的数据备份。

Redis 优势

性能极高：Redis 是一个高性能的key-value数据库，读的速度能达到110000次/s,写的速度能达到81000次/s 。
Redis有丰富的数据类型：相比于许多键值数据存储系统， Redis支持string，hash，list，set及zset(sorted set)等数据类型。
简单稳定：单线程
原子性：Redis的所有操作都是原子性的，要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
丰富的特性：Redis支持 publish/subscribe, 通知, key 过期等特性

高可用和分布式：哨兵机制实现高可用，保证 redis 节点故障发现和自动转移
客户端语言多： java php python c c++ nodejs 等
持久化：发生断电或机器故障，数据可能会丢失，持久化到硬盘

单线程

你可能听说过 Redis 是单线程的，那会不会很慢呢？

为什么 Redis 是单线程的 ?

Redis 的数据存储在内存中，如果数据全都在内存里，单线程的去操作就是效率最高的。

为什么呢？因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。因为上下文切换所花费的时间远大于直接从内存中读取数据所花费的时间。

Redis 用单个 CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案。

这里我们一直在强调的单线程，只是在处理我们的网络请求的时候只有一个线程来处理，一个正式的 Redis Server 运行的时候肯定是不止一个线程的，例如 Redis 进行持久化的时候会以子进程或者子线程的方式执行。

Redis 数据类型

String

String 数据结构是简单的 key-value 类型，value 其实不仅可以是 String，也可以是数字。需要注意是一个键值最大存储 512MB。

> set myName "redis"
OK
> get myName
redis
> set myName "memcache"
OK
> get myName
memcache
> set count 1
OK
> get count
1
> incr count
2

Hash（哈希）

Hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。比如我们可以 Hash 数据结构来存储用户信息，商品信息等等。

> hmset lilei name "LiLei" age 26 title "Senior"
OK
> hget lilei age
26
> hget lilei title
Senior
> hset lilei title "Primary"
> hget lilei title
Primary

List（列表）

是 Redis 的简单的字符串列表。list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。

> lpush mylist aaa
(integer) 1
> lpush mylist bbb
(integer) 2
> rpush mylist ccc
(integer) 3
> llen mylist
(integer) 3
> lrange mylist 0 2
1) "bbb"
1) "aaa"
1) "ccc"

Set

Set 对外提供的功能与 list 类似是一个列表的功能，特殊之处在于 set 不允许重复元素，可以自动排重的，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的。

在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis 可以非常方便的实现如共同关注、共同喜好、二度好友等功能。

> sadd myset 111
(integer) 1
> sadd myset 222
(integer) 1
> sadd myset 333
(integer) 1
> sadd myset 222
(integer) 0
> smembers myset
1) "111"
2) "222"
3) "333"

Sorted Set

与 set 相比，Sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列。

举例：在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息，适合使用 Sorted set 结构进行存储。

> zadd myzset 3 a
(integer) 1
> zadd myzset 1 b
(integer) 1
> zadd myzset 2 c
(integer) 1
> zadd myzset 2 c
(integer) 0
> zadd myzset 1 d
(integer) 1
> zrangebyscore myzset 0 3
1) "b"
2) "d"
3) "c"
4) "a"

Redis的过期策略

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理，过期策略通常有以下三种：

定时过期

每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

惰性过期

只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

定期过期

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

Redis的内存淘汰策略

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

我们知道，redis设置配置文件的maxmemory参数，可以控制其最大可用内存大小（字节）。

那么当所需内存，超过maxmemory怎么办？

这个时候就该配置文件中的maxmemory-policy出场了。

其默认值是 noeviction。

下面我将列出当可用内存不足时，删除redis键具有的淘汰规则。

规则名称	规则说明
volatile-lru	使用LRU算法删除一个键（只对设置了生存时间的键）
allkeys-lru	使用LRU算法删除一个键
volatile-random	随机删除一个键（只对设置了生存时间的键）
allkeys-random	随机删除一个键
volatile-ttl	删除生存时间最近的一个键
noeviction	不删除键，只返回错误

Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。

注意

LRU算法，least RecentlyUsed，最近最少使用算法。也就是说默认删除最近最少使用的键。

但是一定要注意一点！redis中并不会准确的删除所有键中最近最少使用的键，而是随机抽取3个键，删除这三个键中最近最少使用的键。

那么3这个数字也是可以设置的，对应位置是配置文件中的maxmeory-samples.

缓存

对于热点数据，缓存以后可能读取数十万次，因此，对于热点数据，缓存的价值非常大。例如，分类栏目更新频率不高，但是绝大多数的页面都需要访问这个数据，因此读取频率相当高，可以考虑基于 Redis 实现缓存。

会话缓存

此外，还可以考虑使用 Redis 进行会话缓存。例如，将 web session 存放在 Redis 中，例如最常用的session共享技术。

访问频率限制

出于减轻服务器的压力或防止恶意的洪水攻击的考虑，需要控制访问频率，例如限制 IP 在一段时间的最大访问量。

交集、并集和差集

在某些场景中，例如社交场景，通过交集、并集和差集运算，可以非常方便地实现共同好友，共同关注，共同偏好等社交关系。

记录用户判定信息

记录用户判定信息的需求也非常普遍，可以知道一个用户是否进行了某个操作。例如，用户是否点赞、用户是否收藏、用户是否分享等。

热点数据的缓存

由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据，另外结合expire，我们可以设置过期时间然后再进行缓存更新操作，这个功能最为常见，我们几乎所有的项目都有所运用。

排行榜

关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。

在奶茶活动中，我们需要展示各个部门的点赞排行榜，所以我针对每个部门做了一个SortedSet,然后以用户的openid作为上面的username,以用户的点赞数作为上面的score, 然后针对每个用户做一个hash,通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息，这个当时在实际运用中性能体验也蛮不错的。

计数器应用

redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。

限时业务的运用

redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。

分布式锁

这个主要利用redis的setnx命令进行，setnx：”set if not exists”就是如果不存在则成功设置缓存同时返回1，否则返回0 ，这个特性在俞你奔远方的后台中有所运用，因为我们服务器是集群的，定时任务可能在两台机器上都会运行，所以在定时任务中首先通过setnx设置一个lock，如果成功设置则执行，如果没有成功设置，则表明该定时任务已执行。当然结合具体业务，我们可以给这个lock加一个过期时间，比如说30分钟执行一次的定时任务，那么这个过期时间设置为小于30分钟的一个时间就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。

当然我们可以将这个特性运用于其他需要分布式锁的场景中，结合过期时间主要是防止死锁的出现。

延时操作

这个目前我做过相关测试，但是还没有运用到我们的实际项目中，下面我举个该特性的应用场景。比如在订单生产后我们占用了库存，10分钟后去检验用户是够真正购买，如果没有购买将该单据设置无效，同时还原库存。由于redis自2.8.0之后版本提供Keyspace Notifications功能，允许客户订阅Pub/Sub频道，以便以某种方式接收影响Redis数据集的事件。所以我们对于上面的需求就可以用以下解决方案，我们在订单生产时，设置一个key，同时设置10分钟后过期，我们在后台实现一个监听器，监听key的实效，监听到key失效时将后续逻辑加上。当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。

分页、模糊搜索

redis的set集合中提供了一个zrangebylex方法，语法如下：

ZRANGEBYLEX key min max [LIMIT offset count]

通过ZRANGEBYLEX zset - + LIMIT 0 10 可以进行分页数据查询，其中- +表示获取全部数据

zrangebylex key min max 这个就可以返回字典区间的数据，利用这个特性可以进行模糊查询功能，这个也是目前我在redis中发现的唯一一个支持对存储内容进行模糊查询的特性。

前几天我通过这个特性，对学校数据进行了模拟测试，学校数据60万左右，响应时间在700ms左右，比mysql的like查询稍微快一点，但是由于它可以避免大量的数据库io操作，所以总体还是比直接mysql查询更利于系统的性能保障。

点赞、好友等相互关系的存储

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。又或者在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。

这个在奶茶活动中有运用，就是利用set存储用户之间的点赞关联的，另外在点赞前判断是否点赞过就利用了sismember方法，当时这个接口的响应时间控制在10毫秒内，十分高效。

队列

Redis 能作为一个很好的消息队列来使用，依赖 List 类型利用 LPUSH 命令将数据添加到链表头部，通过 BRPOP 命令将元素从链表尾部取出。同时，市面上成熟的消息队列产品有很多，例如 RabbitMQ。因此，更加建议使用 RabbitMQ 作为消息中间件。

Redis 数据持久化存储

Redis 是基于内存的数据库，一旦进程退出，数据就会丢失，所以我们需要它也可以把数据写到磁盘上，当 Redis 重启后，可以从磁盘中恢复数据。

Redis 提供了两种解决方案将内存中的数据保存到磁盘上。一种是 RDB 持久化，原理是将 Reids 在内存中的全部数据库记录定时 dump 到磁盘上的 RDB 持久化；另外一种是 AOF 持久化，原理是将 Reids 的操作日志以追加的方式写入文件。

RDB(Redis DataBase)

RDB 是 Redis 用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照所有数据。恢复时是将快照文件直接读到内存里。

简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
Redis默认为该方式，内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb（如果需要恢复数据，只需将备份文件dump.rdb 移动到 redis 安装目录并启动服务即可）。可以通过配置设置自动做快照持久化的方式。配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置。

1
2
3

save 900 1         #900秒内如果超过1个key被修改，则发起快照保存
save 300 10        #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000      #60秒内容如超过10000个key被修改，则发起快照保存

client 也可以使用save或者bgsave命令手动通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求，不推荐使用。

RDB利弊	原因
优点1	压缩后的二进制文，适用于备份、全量复制，用于灾难恢复
优点2	大数据量时，加载RDB恢复数据远快于AOF方式
缺点1	无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
缺点2	保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题

AOF(Append Only File)

AOF 持久化：记录除了查询以外，所有变更数据库状态的指令，以 append 的形式追加保存到 AOF 文件中。AOF 文件通常会比 RDF 文件体积更大。

AOF则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了，相关配置如下：

appendonly  no         # redis默认关闭AOF机制，可以将no改成yes实现AOF持久化
appendfsync always     # 每次有数据修改发生时都会写入AOF文件。
appendfsync everysec   # 每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no         # 从不同步。高效但是数据不会被持久化。

具体操作方式：如何从AOF恢复数据?

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

RDB-AOF 混合模式

混合模式是先使用 bgsave 以 RDB 形式将内存中的全部数据写入磁盘，之后当有新的数据时，再使用 AOF 的形式追加到文件中。

如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

重启时恢复加载AOF与RDB顺序及流程

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

Redis主从下的持久化方案设计

Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

尽量避免在压力很大的主库上增加从库

主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…。这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。