redis

redis中数据均以key/value键值对形式保存,包含一下五种基本数据类型:

  • String: 字符串,可以包含任何数据,比如一个序列号对象或一张jpg图片,上限大小为512MB
  • List:字符串列表,按照插入顺序排序,类似双端队列,可从头部或者尾部操作数据
  • Hash:类似Map,是一个键值对集合,可用于存储对象
  • Set:String的无须集合,元素不可重复
  • Zset:与set一样,也是string类型的集合,但是Zset中的每个元素均会关联一个double类型的分数,zset中成员也唯一,但是关联的分数可重复

一、基础概念:

1、基本数据类型:

Redis支持5种数据类型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)

1、String

​ String 是 redis 最基本的类型,你可以理解成与 Memcached 一模一样的类型,一个 key 对应一个 value。value其实不仅是String,也可以是数字。string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。string 类型是 Redis 最基本的数据类型,string 类型的值最大能存储 512MB。

​ 应用场景:String是最常用的一种数据类型,普通的key/ value 存储都可以归为此类,即可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受Redis的定时持久化,操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外,Redis还提供了下面一些操作:

  • 获取字符串长度

  • 往字符串append内容

  • 设置和获取字符串的某一段内容

  • 设置及获取字符串的某一位(bit)

  • 批量设置一系列字符串的内容

​ 使用场景:常规key-value缓存应用。常规计数: 微博数, 粉丝数。 实现方式:String在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。

2、Hash

Hash 是一个键值(key => value)对集合,类似map的一种结构。Redis hash 是一个 string 类型的 field 和 value 的映射表,一般可以将结构化的数据,比如一个对象(前提是这个对象没嵌套其他的对象)给缓存在redis里,然后每次读写缓存的时候,可以就操作hash里的某个字段,而不是把整个对象都拿出来,这样节省了IO操作,效率更高。 常用命令:hget,hset,hgetall 等。 应用场景:我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:

用户ID为查找的key,存储的value用户对象包含姓名,年龄,生日等信息,如果用普通的key/value结构来存储,主要有以下2种存储方式:

image

​ 第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。

image

​ 第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口,如下图:

image

​ 也就是说,Key仍然是用户ID, value是一个Map,这个Map的key是成员的属性名,value是属性值,这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题,很好的解决了问题。

​ 这里同时需要注意,Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多,那么涉及到遍历整个内部Map的操作,由于Redis单线程模型的缘故,这个遍历操作可能会比较耗时,而另其它客户端的请求完全不响应,这点需要格外注意。 使用场景:存储部分变更数据,如用户信息等。 实现方式:上面已经说到Redis Hash对应Value内部实际就是一个HashMap,实际这里会有2种不同实现,这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

1
2
3
4
redis> HSET myhash field1 "Hello" field2 "World"
"OK" redis> HGET myhash field1
"Hello" redis> HGET myhash field2
"World"

实例中我们使用了 Redis HMSET, HGET 命令,HMSET 设置了两个 field=>value 对, HGET 获取对应 field 对应的 value。每个 hash 可以存储 232 -1 键值对(40多亿)。

3、list

​ list列表是简单的字符串列表,按照插入顺序排序。可以从列表的头部或者尾部插入一个元素。

​ 常用命令:lpush(添加头部元素),rpush(添加尾部元素),lpop(移除头部第一个元素),rpop(移除尾部第一个元素),lrange(获取列表片段,lrange key start stop)等。

​ 应用场景:Redis list的应用场景非常多,也是Redis最重要的数据结构之一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现。比如在微博里,有个大v的粉丝,就可以以list的格式放在Redis里去缓存。比如可以通过list存储一些列表型的数据结构,类似粉丝列表了、文章的评论列表了之类的东西。还可以通过lrange命令,从某个元素开始读取多少个元素,还可以基于list实现分页查询,这个很棒的一个功能。基于redis实现简单的高性能分页,可以做类似微博那种下拉不断分页的东西,性能很高,一页一页的走。比如还可以用来搞个简单的消息队列,从list头塞进去,从list尾巴那里弄出来。

1
2
key=某大v
value=[zhangsan, lisi, wangwu]

​ List 就是链表,相信略有数据结构知识的人都应该能理解其结构。使用List结构,我们可以轻松地实现最新消息排行等功能。List的另一个应用就是消息队列, 可以利用List的PUSH操作,将任务存在List中,然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段的api,你可以直接查询,删除List中某一段的元素。

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

​ Redis的list是每个子元素都是String类型的双向链表,可以通过push和pop操作从列表的头部或者尾部添加或者删除元素,这样List即可以作为栈,也可以作为队列。 获取越接近两端的元素速度越快,但通过索引访问时会比较慢。

​ 使用场景: 消息队列系统:使用list可以构建队列系统,使用sorted set甚至可以构建有优先级的队列系统。比如:将Redis用作日志收集器,实际上还是一个队列,多个端点将日志信息写入Redis,然后一个worker统一将所有日志写到磁盘。

​ 取最新N个数据的操作:记录前N个最新登陆的用户Id列表,超出的范围可以从数据库中获得。

1
2
3
4
//把当前登录人添加到链表里
ret = r.lpush("login:last_login_times", uid) //保持链表只有N位
ret = redis.ltrim("login:last_login_times", 0, N-1) //获得前N个最新登陆的用户Id列表
last_login_list = r.lrange("login:last_login_times", 0, N-1)

​ 比如微博: 在Redis中我们的最新微博ID使用了常驻缓存,这是一直更新的。但是我们做了限制不能超过5000个ID,因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候,才需要去访问数据库。我们的系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

1
2
3
4
5
6
7
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>

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

4、Set

set 是string类型的无序集合。集合是通过hashtable实现的,概念和数学中个的集合基本类似,可以交集,并集,差集等等,set中的元素是没有顺序的。所以添加,删除,查找的复杂度都是O(1)。

sadd 命令:添加一个 string 元素到 key 对应的 set 集合中,成功返回1,如果元素已经在集合中返回 0,如果 key 对应的 set 不存在则返回错误。

常用命令:sadd,spop,smembers,sunion 等。

​ 应用场景:Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。 如果你需要对一些数据进行快速的全局去重,你当然也可以基于jvm内存里的HashSet进行去重。但是如果你的某个系统部署在多台机器上呢?就得基于Redis进行全局的set去重了。

Set 就是一个集合,集合的概念就是一堆不重复值的组合。利用Redis提供的Set数据结构,可以存储一些集合性的数据。

​ 案例:在微博中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

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

使用场景: ①交集,并集,差集:(Set)

1
2
3
4
5
6
7
8
9
10
11
12
//book表存储book名称
set book:1:name ”The Ruby Programming Language”
set book:2:name ”Ruby on rail”
set book:3:name ”Programming Erlang” //tag表使用集合来存储数据,因为集合擅长求交集、并集
sadd tag:ruby 1
sadd tag:ruby 2
sadd tag:web 2
sadd tag:erlang 3
//即属于ruby又属于web的书?
inter_list = redis.sinter("tag.web", "tag:ruby") //即属于ruby,但不属于web的书?
inter_list = redis.sdiff("tag.ruby", "tag:web") //属于ruby和属于web的书的合集?
inter_list = redis.sunion("tag.ruby", "tag:web")

②获取某段时间所有数据去重值 这个使用Redis的set数据结构最合适了,只需要不断地将数据往set中扔就行了,set意为集合,所以会自动排重。

1
sadd key member
1
2
3
4
5
6
7
8
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"

注意:以上实例中 rabitmq 添加了两次,但根据集合内元素的唯一性,第二次插入的元素将被忽略。集合中最大的成员数为 232 - 1(4294967295, 每个集合可存储40多亿个成员)。

5、Zset

zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。 zadd 命令:添加元素到集合,元素在集合中存在则更新对应score。 常用命令:zadd,zrange,zrem,zcard等

​ 使用场景:Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,那么可以选择sorted set数据结构,比如twitter 的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。和Set相比,Sorted Set关联了一个double类型权重参数score,使得集合中的元素能够按score进行有序排列,redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。比如一个存储全班同学成绩的Sorted Set,其集合value可以是同学的学号,而score就可以是其考试得分,这样在数据插入集合的时候,就已经进行了天然的排序。另外还可以用Sorted Set来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

​ 实现方式:Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

1
zadd key score member
1
2
3
4
5
6
7
8
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"

2、基本操作命令:

SET:插入key

1
2
127.0.0.1:6379> get a
"xiejy"

DEL:删除key

1
2
3
4
127.0.0.1:6379> del a           #存在key
(integer) 1
127.0.0.1:6379> del b #不存在key
(integer) 0

DUMP:序列化key

1
2
3
4
127.0.0.1:6379> GET a
"xiejy"
127.0.0.1:6379> DUMP a
"\x00\x05xiejy\t\x00\t\x19\xf4\xd6\x14Y\xcb:"

EXISTS:判断key是否存在

1
2
3
4
127.0.0.1:6379> EXISTS a		#存在key
(integer) 1
127.0.0.1:6379> EXISTS b #不存在key
(integer) 0

EXPIRE:为key设置有效时间,过期后key会自动销毁,单位秒。 PEXPIRE:为kye设置有效时间,单位为毫秒

1
2
127.0.0.1:6379> EXPIRE a 15		#为a设置15秒过期时间
(integer) 1

TTL:查看key的有效时间,单位秒。 PTTL:查看key有效时间,单位毫秒

1
2
3
4
5
6
7
8
127.0.0.1:6379> TTL a		#该key剩余9s
(integer) 9

127.0.0.1:6379> TTL a #-2表示key不存在或者已过期
(integer) -2

127.0.0.1:6379> TTL b #-1表示key存在但为设置有效时间(永久有效)
(integer) -1

PERSIST:移除key的过期时间。

1
2
3
4
5
6
7
8
9
10
11
12
127.0.0.1:6379> EXPIRE a 99
(integer) 1

127.0.0.1:6379> TTL a
(integer) 94

127.0.0.1:6379> PERSIST a #移除a过期时间
(integer) 1

127.0.0.1:6379> TTL a #a永久有效
(integer) -1

KEYS:获取满足条件的所有key

1
2
3
4
5
6
7
127.0.0.1:6379> KEYS a*			#匹配以a开头的key
1) "as"
2) "abb"
3) "a"

127.0.0.1:6379> KEYS a? #匹配以a开头,后一个通配符的
1) "as"

TYPE:获取key的存储类型

MOVE key db:将当前数据库的 key 移动到给定的数据库 db 当中。如果当前数据库(源数据库)和给定数据库(目标数据库)有相同名字的给定 key ,或者 key 不存在于当前数据库,那么 MOVE 没有任何效果。因此,也可以利用这一特性,将 MOVE 当作锁(locking)原语(primitive)。移动成功返回1,失败返回0

RENAME key newkey:重命名key

1
2
3
4
5
6
7
8
127.0.0.1:6379> get a
"99"
127.0.0.1:6379> get c
(nil)
127.0.0.1:6379> RENAME a c
OK
127.0.0.1:6379> get c
"99"

3、应用场景

类型 简介 特性 场景
String(字符串) 二进制安全 可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M
Hash(字典) 键值对集合,即编程语言中的Map类型 适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去) 存储、读取、修改用户属性
List(列表) 链表(双向链表) 增删快,提供了操作某一段元素的API 1、最新消息排行等功能(比如朋友圈的时间线) 2、消息队列
Set(集合) 哈希表实现,元素不重复 1、添加、删除、查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作 1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐
Sorted Set(有序集合) 将Set中的元素增加一个权重参数score,元素按score有序排列 数据插入集合时,已经进行天然排序 1、排行榜 2、带权重的消息队列

二、底层数据结构

三、持久化

redis持久化有两种方式:快找持久化及AOF。

1、快照持久化RDB

在某个时间点上对内存中的数据创建副本文件,redis重启时会自动加载副本文件中的数据。

配置持久化快照,编辑redis.conf

1
2
3
4
5
6
7
save 900 1		#900秒内至少有1个key被更改则进行快照
save 300 10 #300秒内至少有10个key被更改则进行快照
save 60 50 #60秒内至少有50个key被更改则进行快照
stop-writes-on-bgsave-error yes #创建快照出错后,是否继续执行写命令
rdbcompression yes #是否对快照文件进行压缩
dbfilename dump.rdb #生成快照文件的名字
dir ./ #生成快照文件的位置

redis默认开启快照持久化

快照持久化流程:

1、在redis运行中,可以通过save命令手动创建快照,save是一个阻塞命令,redis在收到save命令后,开始执行备份操作后,将阻塞其他命令将其挂起,直到备份操作执行完毕。

2、在redis运行中,可以通过bgsave创建快照,该命令会fork一个子进程,该子进程负责执行快照数据写入硬盘,父进程则继续处理其他命令,这样不会阻塞客户端命令。

3、配置文件内有配置时,redis会自动触发bgsave命令进行备份。

4、当执行shutdown命令关闭redis时,会执行save命令进行快照备份,并在备份操作完成后将服务器关闭。

5、有种特殊情况会触发bgsave命令,在主从备份的时候,当slave连接master时,会发送一条sync命令进行同步操作,此时master会开始一次bgsave操作,并在bgsave操作介乎后向slave发送快照数据实现数据同步。

快照持久化的缺点:

save命令会发生阻塞;bgsave会fork子进程小号资源,大数据量的时候,做rdb,redis会暂停服务

2、AOF持久化

AOF持久化在redis种默认不开启,开启方式在redis.conf配置属性:appendonly yes

1
2
3
4
5
6
7
appendfilename "backup.aof"		#AOF备份文件名
# appendfsync always #备份实际,always每执行一个命令就备份一次
appendfsync everysec #everysec表示每秒备份一次
# appendfsync no #no表示备份时机交给操作系统
no-appendfsync-no-rewrite no #在对aof文件进行压缩时,是否执行同步操作
auto-aof-rewrite-percentage 100 #
auto-aof-rewrite-min-size 64mb
  • appendfsync有三种取值,首选everysec,always会严重降低redis性能

AOF文件的重写与压缩

随着系统运行,AOF文件会越来越大,而AOF文件的重写与压缩可一定成都缓解该问题。

bgrewriteaof命令可对文件进行重写,其执行原理与bgsave原理一致。bgrewriteaof也可自动执行,时间依赖于auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置,auto-aof-rewrite-percentage 100 表示当aof文件大小超过上一次重写时的aof文件大小的百分之多少时则再次进行重写,如果之前没有重写,则以启动时的aof文件大小为依据,同时还要求AOF文件大小至少大于64M。

Redis AOF流程

  1. Redis Server启动,如果AOF机制打开那么初始化AOF状态,并且如果存在AOF文件,读取AOF文件。
  2. 随着Redis不断接受命令,每个写命令都被添加到AOF文件,AOF文件膨胀到需要rewrite时又或者接收到客户端的bgrewriteaof命令。
  3. fork出一个子进程进行rewrite,而父进程继续接受命令,现在的写操作命令都会被额外添加到一个aof_rewrite_buf_blocks缓冲中。
  4. 当子进程rewrite结束后,父进程收到子进程退出信号,把aof_rewrite_buf_blocks的缓冲添加到rewrite后的文件中,然后切换AOF的文件fd。rewrite任务完成,继续第二个步骤。

AOF优劣势:

优势:最多丢失1s的更新数据

劣势:aof的文件体积可能会很大(可能比快照的还大),另一方方面,系统重启时会从aof里读命令,aof文件过大读命令会耗时很久。

是 redis 最基本的类型,你可以理解成与 Memcached 一模一样的类型,一个 key 对应一个 value。value其实不仅是String,也可以是数字。string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。string 类型是 Redis 最基本的数据类型,string 类型的值最大能存储 512MB。

四、主从复制

redis的主从复制和关系型数据库的主从复制类似,能实现数据的独写分离,同时实现数据备份。

配置主从复制

  • 在从机上执行命令 SLAVEOF masterip masterport

  • 在redis-conf配置文件种添加如下配置: slaveof 127.0.0.1 6370 配置master redis地址

INFO replication 可查看实例当前状态:

1
2
3
4
role:master
connected_slaves:2
slave0:ip=10.0.100.52,port=6379,state=online,offset=56,lag=1
slave0:ip=10.0.100.53,port=6379

本文参考以下文章: