redis快速入门手册_redis使用手册

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。它在企业级应用中被广泛的使用，已经成为web开发者必须具备的技能之一。

目录

1. 概述

1.1 介绍

1.2 优缺点

1.3 应用场景

1.4 Raft协议

1.5 安装

2. 特性

2.1 数据库

2.2 文件夹

2.3  管道

2.4 发布订阅

2.5 事务

2.6 文件导入

3. 命令集

3.1 常见命令

3.1.1 connection

3.1.2 server

3.1.3 key

3.2 string

3.2.1 bitmap

3.3 list

3.4 hash

3.5 set

3.6 sorted set

3.7 hyperLogLog

3.8 geospatial

4. 持久化配置

4.1 rdb

4.2 aof

4.3 数据恢复

5. 集群 

5.1 redis sentinel

5.2 redis cluster

6. 客户端 Jedis

7. 示例：位图法统计活跃用户

8. Q&A

---

1. 概述

1.1 介绍

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。

1.2 优缺点

优点：

1. 性能极高，Redis能支持10万每秒的读写频率
2. 丰富的数据类型及对应的操作
3. Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行，也即支持事务
4. 丰富的特性，Redis还支持publish/subscribe，key过期等特性

性能（以下摘自官方测试描述）：

在50个并发的情况下请求10W次，写的速度是11W次/s，读的速度是8.1w次/s。测试环境：

1）50个并发，请求10W次

2）读和写大小为256bytes的字符串

3）Linux2.6 Xeon X3320 2.5GHz的服务器上

4）通过本机的loopback interface接口上执行

缺点：

1. Redis具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复；
2. 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性；
3. Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦；
4. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费；

1.3 应用场景

• Counting（计数）
• Reverse cache（反向cache）
• Top 10 list
• Last Index
• Relation List/Message Queue
• Fast transaction with Lua
• Instead of Memcache

1.4 Raft协议

redis sentinel实现了著名的RAFT选主协议

1.5 安装

wget http://download.redis.io/releases/redis-3.2.5.tar.gz
tar xzf redis-3.2.5.tar.gz
cd redis-3.2.5
make
#启动服务器端:
src/redis-server
#启动客户端:
src/redis-cli
#redis> set foo bar
#OK
#redis> get foo
#"bar"

2. 特性

2.1 数据库

Redis中默认设置了16个数据库,编号为0~15,可以通过修改配置文件来修改数据库个数.可以使用select(databaseNo)方法来选择使用的数据库。

使用场景：

一台服务器上都快开启200个redis实例了，看着就崩溃了。这么做无非就是想让不同类型的数据属于不同的应用程序而彼此分开。那么，redis有没有什么方法使不同的应用程序数据彼此分开同时又存储在相同的实例上呢？就相当于mysql数据库，不同的应用程序数据存储在不同的数据库下。

2.2 文件夹

Redis的Key中使用冒号作为分隔符,在RedisDesktopManager中查看可以看到分级的文件夹.需要注意的是,这种方式只有在客户端中查看才能看到分级效果,实际的Key并没有变化。

2.3  管道

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。

而管道（Pipelining）：学习如何一次发送多个命令，节省往返时间。客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。

2.4 发布订阅

发布端: publish 频道名称 发布内容

订阅端: subscribe 频道名称

Redis的发布/订阅目前是即发即弃(fire and forget)模式的，因此无法实现事件的可靠通知。也就是说，如果发布/订阅的客户端断链之后又重连，则在客户端断链期间的所有事件都丢失了。

数据库与作用域：

发布/订阅与key所在空间没有关系，它不会受任何级别的干扰，包括不同数据库编码。 发布在db 10,订阅可以在db 1。 如果你需要区分某些频道，可以通过在频道名称前面加上所在环境的名称（例如：测试环境，演示环境，线上环境等）。

模式匹配订阅：

Redis 的Pub/Sub实现支持模式匹配。客户端可以订阅全风格的模式以便接收所有来自能匹配到给定模式的频道的消息。比如:PSUBSCRIBE news.*

2.5 事务

Redis与 mysql事务的对比

注：Redis使用的是队列，没有回滚只有取消(队列)

Redis的事务中,Watch命令启用的是乐观锁,只负责监测key没有被改动，如果有其他客户端修改了key的值，当前客户端的事务就要失败。

2.6 文件导入

导入使用cat和redis-cli命令组合,使用--pipe 这个参数来启用pipe协议，它不仅仅能减少返回结果的输出，还能更快的执行指令。更多

3. 命令集

3.1 常见命令

3.1.1 connection

3.1.2 server

3.1.3 key

3.2 string

• 常用命令

set、get、decr、incr、mget、setnx等

• 应用场景

String是最常用的一种数据类型，普通的key/value存储

• 实现方式

String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr，decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int.

• 命令及描述

3.2.1 bitmap

Bitmaps本身不是一种数据结构，实际上就是字符串，但是它可以对字符串的位进行操作。可以把Bitmaps想象成一个以位为单位数组，数组中的每个单元只能存0或者1，数组的下标在bitmaps中叫做偏移量。单个bitmaps的最大长度是512MB，即2^32个比特位。

3.3 list

简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。一个列表最多可以包含 232- 1 个元素 (4294967295, 每个列表超过40亿个元素)。

• 常用命令

lpush、rpush、lpop、rpop、lrang等;

• 应用场景

Redis list应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现;

• 实现方式

Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构;

• 命令及描述

3.4 hash

一个string类型的field和value的映射表，hash特别适合用于存储对象，每个 hash 可以存储 232 - 1 键值对（40多亿）。

• 常用命令

hget，hset，hgetall 等；

• 应用场景

比如，我们存储供应商酒店价格的时候可以采取此结构，用酒店编码作为Key，RatePlan+RoomType作为Filed，价格信息作为Value；

• 实现方式

Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap；当成员数量增大时会自动转成真正的HashMap，此时encoding为ht；

• 命令及描述

3.5 set

集合成员是唯一的，这就意味着集合中不能出现重复的数据。集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。唯一性,无序性,确定性

• 常用命令

sadd、spop、smembers、sunion等;

• 应用场景

Set对外提供的功能与list类似，当你需要存储一个列表数据，又不希望出现重复数据时，set 是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的接口，这个也是list所不能提供的;

• 实现方式

Set的内部实现是一个value永远为null的HashMap，实际就是通过计算hash的方式来快速排除重复的，这也是set能提供判断一个成员是否在集合内的原因;

• 命令及描述

3.6 sorted set

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的,但分数(score)却可以重复。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

• 常用命令

zadd，zrange，zrem，zcard等；

• 应用场景

Sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序.当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构；

• 实现方式

Sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率

• 命令及描述

3.7 hyperLogLog

HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。

3.8 geospatial

地理坐标信息，更多

4. 持久化配置

Redis的持久化有2种方式：

• RDB：对内存中数据库状态进行快照；
• AOF：把每条写命令都写入文件，类似mysql的binlog日志

4.1 rdb

工作原理：rdb主进程满足触发条件调用rdbdump子进程

优势:从内存dump数据形成rdb二进制文件，恢复很快

缺陷：触发条件有时间间隔(会丢失几分钟)

• 执行命令手动生成

有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE，

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求；

BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求，创建RDB文件结束之前，客户端发送的BGSAVE和SAVE命令会被服务器拒绝。

• 通过配置自动生成

可以设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令；

可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。

#Rdb快照的配置选项(这3个选项都屏蔽,则rdb禁用)redis.conf
save 900 1      # 900秒内,有1条写入,则产生快照
save 300 1000   # 如果300秒内有1000次写入,则产生快照
save 60 10000   # 如果60秒内有10000次写入,则产生快照
stop-writes-on-bgsave-error yes  # 后台备份进程出错时,主进程停不停止写入
rdbcompression yes    # 导出的rdb文件是否压缩
Rdbchecksum   yes     # 导入rbd恢复时数据时,要不要检验rdb的完整性
dbfilename dump.rdb   # 导出来的rdb文件名
dir ./                # rdb的放置路径

4.2 aof

AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。文件刷新的方式有三种：

• appendfsync always - 每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；
• appendfsync everysec - 每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；
• appendfsync no - 依靠OS进行刷新，Redis不主动刷新AOF，这样最快，但安全性就差。

默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。

appendonly no # 是否打开 aof日志功能
appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢
appendfsync everysec # 折衷方案,每秒写1次
appendfsync no      #写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
no-appendfsync-on-rewrite  yes: # 正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写
 
#命令方式：
lastsave        #上次保存时间
bgrewriteaof 	#后台进程重写AOF

4.3 数据恢复

• RDB方式

       RDB文件的载入工作是在服务器启动时自动执行的，没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，它就会自动载入RDB文件，服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。

• AOF方式

     服务器在启动时，通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态，具体过程：

   （1）载入AOF文件
   （2）创建模拟客户端
   （3）从AOF文件中读取一条命令
   （4）使用模拟客户端执行命令
   （5）循环读取并执行命令，直到全部完成

如果同时启用了RDB和AOF方式，AOF优先，启动时只加载AOF文件恢复数据。

5. 集群 

5.1 redis sentinel

稳定版本的redis(2.8)只支持简单的master-slave replication: 一个master写，多个slave读。只能通过客户端一致性哈希自己做sharding（感觉用这个集群在生产环境用途不大）。

它推出了一个集群管理工具，叫作哨兵（Sentinel）。Redis Sentinel是社区版本推出的原生高可用解决方案，Redis Sentinel部署架构主要包括两部分：

• Redis Sentinel集群，实现了著名的RAFT选主协议，可以实现故障发现、故障自动转移、配置中心和客户端通知，且从而保证了系统选主的一致性。节点数量要满足2n+1（n>=1）的奇数个。
• Redis数据集群

 

Sentinel功能

1. monitoring——redis实例是否正常运行；
2. notification——通知application错误信息；
3. failover——某个master死掉，选择一个slave升级为master，修改其他slave的slaveof关系，更新client连接；
4. configurationprovider——client通过sentinel获取redis地址，并在failover时更新地址；

sentinels and slaves autodiscovery

• sentinels——sentinel之间通过redis pub/sub交换信息获得；
• slaves——询问master获得；

sdown、odown、failover

故障检测一般都是通过ping-pong机制，sentinel引入sdown（主观下线）和odown（客观下线）机制，目的应该是在集群规模较大时，检测更客观。

• sdwon——is-master-down-after-milliseconds（可配置）时间内ping-pong失败。sdown的slave不能升级为master。
• odown——超过一定数目（可配置）的sentinel认为sdown，odown只针对master。
• failover——多数sentinel认为odown。

sentinel集群

• 至少需要部署三台以上，形成一个sentinel集群，
• Sentinels之间的数据同步，包括redis状态（odown,sdown），通过redis pub/sub实现，
• 执行failover需要选举一个sentinel作为leader去执行（添加sentinel：自动发现）（移除sentinel：stopsentinel process/reset all sentinel/check sentinel num）

执行failver

• slave leader升级为master、
• 其他slave修改为新master的slave、
• 客户端修改连接、
• 老的master如果重启成功，变为新master的slave、

参考配置

Master配置:
1. 关闭rdb快照(备份工作交给slave)
2. 可以开启aof
slave配置:
1. 声明slave-of
2. 配置密码[如果master有密码]
3. [某1个]slave打开 rdb快照功能
4. 配置是否只读[slave-read-only]

缺点:

• 资源浪费，Redis数据节点中slave节点作为备份节点不提供服务
• Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移
• 不能解决读写分离问题，实现起来相对复杂

建议：

• 同一业务可以选择一套Sentinel集群监控多组Redis数据节点的方案
• sentinel monitor配置中的<quorum>建议设置成Sentinel节点的一半加1
• 合理设置参数，防止误切，控制切换灵敏度控制

down-after-milliseconds 30000
failover-timeout 180000
maxclient
timeout

• 部署的各个节点服务器时间尽量要同步，否则日志的时序性会混乱
• 自行搞定配置中心（zookeeper），方便客户端对实例的链接访问
• Redis建议使用pipeline和multi-keys操作，减少RTT次数，提高请求效率

5.2 redis cluster

Redis在3.0中也引入了集群的概念，也叫无中心高可用架构，用于解决一些大数据量和高可用的问题。

设计目标

数据分布

数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布

• 不使用一致性hash，使用hashslot（哈希槽），共有16384个slot。
• hash_slot = crc16(key) mod 16384
• 每个node负责slot的一个子集，增加或者删除节点修改slot分布
• hash-slot灵活性不如一致性hash，但便于实现数据迁移

核心部分

缺点：

1. 节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的
2. 数据通过异步复制,不保证数据的强一致性
3. Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率
4. 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况
5. Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
6. key批量操作限制，如使用mset、mget目前只支持具有相同slot值的key执行批量操作
7. key事务操作支持有限，只支持多key在同一节点上的事务操作
8. key作为数据分区的最小粒度，因此不能将一个很大的键值对象如hash、list等映射到不同的节点
9. Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景

6. 客户端 Jedis

使用Jedis连接Redis服务器有四种方式

7. 示例：位图法统计活跃用户

场景描述：1亿个用户，用户有频繁登陆的，也有不经常登陆的，如果记录用户的登陆信息？

如何查询用户的活跃度，1周内登陆三次的？

思路：

UserId      dt                        active

1                2015-3-21         1

1                2015-5-5-5        1

不合理，表数据增长快,量大,group,sum运算计算较慢

用：位图法 bit*map

log0021: 01100...0

......

log0723: 01101...0

log0726: 01100...1

1、记录用户登陆

每天按日期生成一个位图，用户登陆后把user_id位的bit值设置为1

2、把1周的位图 and计算

位上为1的即是连续登陆的用户

>setbit mon 0000000000

>setbit mon 3 1

>setbit mon 5 1

>setbit mon 7 1

>bitop and res mon tur wen

以上优点

1、节约空间,1亿人每天登陆情况,用1亿bit约1200wbyte,约10M的字节表示

2、位运算计算方便

8. Q&A

8.1 redis是个单线程的程序,为什么会这么快？

总体来说快速的原因如下：  

1. 绝大部分请求是纯粹的内存操作（非常快速）;
2. 采用单线程,避免了不必要的上下文切换和竞争条件；
3. 非阻塞IO；内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。

这3个条件不是相互独立的，特别是第一条，如果请求都是耗时的（都会导致卡顿和其他命令的执行），采用单线程吞吐量及性能可想而知了。应该说redis为特殊的场景选择了合适的技术方案。

我怎么提高多核CPU的利用率？

为了最大限度的使用CPU，可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的，所以，如果你想使用多个CPU，你可以考虑一下分片（shard）

注：对于请求耗时的命令，可采用提供异步命令（scan、bgsave、bgrewriteaof）。

8.2 如何1亿个key中找某些前缀开头的？

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

8.3 做异步队列你是怎么用的?

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

如果对方追问可不可以不用sleep呢？list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

如果对方追问能不能生产一次消费多次呢？使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

如果对方追问pub/sub有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

如果对方追问redis如何实现延时队列？我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话，怎么问的这么详细。但是你很克制，然后神态自若的回答道：使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

8.4 大量的key设置同一时间过期需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

8.5 如何做持久化的？

bgsave做快照全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，会使用bgsave持久化文件重新构建内存，再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

对方追问那如果突然机器掉电会怎样？取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

对方追问bgsave的原理是什么？你给出两个词汇就可以了，fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。