biancheng-Redis教程
目录http://c.biancheng.net/redis/
1Redis是什么
2Windows下载安装Redis
3Ubuntu下载安装Redis
4Redis配置文件
5Redis数据类型
6Redis命令行模式
7Redis key键
8Redis string字符串
9Redis bitmap位图
10Redis数值操作命令
11Redis list列表
12Redis hash哈希散列
13Redis set集合
14Redis zset有序集合
15Redis连接命令
16Redis安全策略
17Redis客户端命令
18Redis服务器命令
19Redis基数统计
20Redis发布订阅
21Redis消息队列
22Redis布隆过滤器
23Redis地理位置
24Redis事务
25Redis Lua脚本
26Redis性能测试
27Redis分区技术
28Redis管道技术
29Redis数据备份和还原
30Redis RDB持久化
31Redis AOF持久化
32Redis主从模式
33Redis哨兵模式
34Redis分布式锁
35Redis缓存问题
36Java使用Redis
37PHP使用Redis
38Python使用Redis
39Redis配置项汇总
Redis是什么
与其他内存型数据库相比,Redis 具有以下特点:
- Redis 不仅可以将数据完全保存在内存中,还可以通过磁盘实现数据的持久存储;
- Redis 支持丰富的数据类型,包括 string、list、set、zset、hash 等多种数据类型,因此它也被称为“数据结构服务器”;
- Redis 支持主从同步,即 master-slave 主从复制模式。数据可以从主服务器向任意数量的从服务器上同步,有效地保证数据的安全性;
- Redis 支持多种编程语言,包括 C、C++、Python、Java、PHP、Ruby、Lua 等语言。
与 SQL 型数据库截然不同,Redis 没有提供新建数据库的操作,因为它自带了 16 (0—15)个数据库(默认使用 0 库)。在同一个库中,key 是唯一存在的、不允许重复的,它就像一把“密钥”,只能打开一把“锁”。键值存储的本质就是使用 key 来标识 value,当想要检索 value 时,必须使用与 value 相对应的 key 进行查找。
Redis 数据库没有“表”的概念,它通过不同的数据类型来实现存储数据的需求,不同的数据类型能够适应不同的应用场景,从而满足开发者的需求。
Redis架构
Redis体系架构主要分为两个部分:
- Redis服务端
- Redis客户端
客户端和服务端可以位于同一台计算机上,也可以位于不同的计算机上。服务端是整个架构的“大脑”,能够把数据存储到内存中,并且起到管理数据的作用。
Redis优势
下面对 Redis 的优势进行了简单总结:
- 性能极高:Redis 基于内存实现数据存储,它的读取速度是 110000次/s,写速度是 81000次/s;
- 多用途工具: Redis 有很多的用途,比如可以用作缓存、消息队列、搭建 Redis 集群等;
- 命令提示功能:Redis 客户端拥有强大的命令提示功能,使用起来非常的方便,降低了学习门槛;
- 可移植性:Redis 使用用标准 C语言编写的,能够在大多数操作系统上运行,比如 Linux,Mac,Solaris 等。
Redis应用场景
Redis 用来缓存一些经常被访问的热点数据、或者需要耗费大量资源的内容,通过把这些内容放到 Redis 中,可以让应用程序快速地读取它们。例如,网站的首页需要经常被访问,并且在创建首页的过程中会消耗的较多的资源,此时就可以使用 Redis 将整个首页缓存起来,从而降低网站的压力,减少页面访问的延迟时间。
我们知道,数据库的存储方式大体可分为两大类,基于磁盘存储和基于内存存储。磁盘存储的数据库,因为磁头机械运动以及系统调用等因素导致读写效率较低。Redis 基于内存来实现数据存取,相对于磁盘来说,其读写速度要高出好几个数量级。下表将 Redis 数据库与其他常用数据库做了简单对比:
名称 | 类型 | 数据存储选项 | 附加功能 |
---|---|---|---|
Redis | 基于内存存储的键值非关系型数据库 | 字符串、列表、散列、有序集合、无序集合 | 发布与订阅、主从复制、持久化存储等 |
Memcached | 基于内存存储的键值缓存型数据库 | 键值之间的映射 | 为提升性能构建了多线程服务器 |
MySQL | 基于磁盘的关系型数据库 | 每个数据库可以包含多个表,每个表可以包含多条记录; 支持第三方扩展。 |
支持 ACID 性质、主从复制和主主复制 |
MongoDB | 基于磁盘存储的非关系文档型数据库 | 每个数据库可以包含多个集合,每个集合可以插入多个文档 | 支持聚合操作、主从复制、分片和空间索引 |
Redis 基于内存来实现数据的存储,因此其速度非常快。但是我们知道,计算机的内存是非常珍贵的资源,所以 Redis 不适合存储较大的文件或者二进制数据,否则会出现错误,Redis 适合存储较小的文本信息。理论上 Redis 的每个 key、value 的大小不超过 512 MB。
总结
下面对安装过程中涉及到的命令进行总结,主要包括以下命令:
安装服务:redis-server --service-install 卸载服务:redis-server --service-uninstall 开启服务:redis-server --service-start 停止服务:redis-server --service-stop 服务端启动时重命名:redis-server --service-start --service-name Redis1
Redis配置文件
配置项说明
下表对一些配置项做了简单地说明:
配置项 | 参数 | 说明 |
---|---|---|
daemonize | no/yes | 默认为 no,表示 Redis 不是以守护进程的方式运行,通过修改为 yes 启用守护进程。 |
pidfile | 文件路径 | 当 Redis 以守护进程方式运行时,会把进程 pid 写入自定义的文件中。 |
port | 6379 | 指定 Redis 监听端口,默认端口为 6379。 |
bind | 127.0.0.1 | 绑定的主机地址。 |
timeout | 0 | 客户端闲置多长秒后关闭连接,若指定为 0 ,表示不启用该功能。 |
loglevel | notice | 指定日志记录级别,支持四个级别:debug、verbose、notice、warning,默认为 notice。 |
logfile | stdout | 日志记录方式,默认为标准输出。 |
databases | 16 | 设置数据库的数量(0-15个)共16个,Redis 默认选择的是 0 库,可以使用 SELECT 命令来选择使用哪个数据库储存数据。 |
save[seconds] [changes] |
可以同时配置三种模式: save 900 1 save 300 10 save 60 10000 |
表示在规定的时间内,执行了规定次数的写入或修改操作,Redis 就会将数据同步到指定的磁盘文件中。比如 900s 内做了一次更改,Redis 就会自动执行数据同步。 |
rdbcompression | yes/no | 当数据存储至本地数据库时是否要压缩数据,默认为 yes。 |
dbfilename | dump.rdb | 指定本地存储数据库的文件名,默认为 dump.rdb。 |
dir | ./ | 指定本地数据库存放目录。 |
slaveof |
主从复制配置选项 | 当本机为 slave 服务时,设置 master 服务的 IP 地址及端口,在 Redis 启动时,它会自动与 master 主机进行数据同步。 |
requirepass | foobared 默认关闭 | 密码配置项,默认关闭,用于设置 Redis 连接密码。如果配置了连接密码,客户端连接 Redis 时需要通过 |
maxmemory |
最大内存限制配置项 | 指定 Redis 最大内存限制,Redis 在启动时会把数据加载到内存中,达到最大内存后,Redis 会尝试清除已到期或即将到期的 Key,当此方法处理 后,若仍然到达最大内存设置,将无法再进行写入操作,但可以进行读取操作。 |
appendfilename | appendonly.aof | 指定 AOF 持久化时保存数据的文件名,默认为 appendonly.aof。 |
glueoutputbuf | yes | 设置向客户端应答时,是否把较小的包合并为一个包发送,默认开启状态。 |
如果想全面了解配置选项
Redis数据类型
Redis 是 Key-Value 类型缓存型数据库,Redis 为了存储不同类型的数据,提供了五种常用数据类型,如下所示:
- string(字符串)
- hash(哈希散列)
- list(列表)
- set(集合)
- zset(sorted set:有序集合)
Redis命令行模式
在 CMD 命令行输入以下命令启动一个 Redis 客户端:
redis-cli
远程服务器上运行命令
远程服务器顾名思义指的是服务器安装在另外一台计算机上,而非本地。这台远程计算机可以是局域网中的一台,也可以是 Internet 联网状态下的远程计算机。Redis 提供了连接远程服务器的命令,格式如下:
C:\Users\Administrator>redis-cli -h host -p port -a password
参数说明:
- -h:用于指定远程 Redis 服务器的 IP 地址;
- -p:用于指定 Redis 远程服务器的端口号;
- -a:可选参数,若远程服务器设置了密码,则需要输入。
Redis key键
Redis键命令汇总
下表对常用的 Redis 键命令做了简单的总结:
命令 | 说明 |
---|---|
DEL key | 若键存在的情况下,该命令用于删除键。 |
DUMP key | 用于序列化给定 key ,并返回被序列化的值。 |
EXISTS key | 用于检查键是否存在,若存在则返回 1,否则返回 0。 |
EXPIRE key | 设置 key 的过期时间,以秒为单位。 |
EXPIREAT key | 该命令与 EXPIRE 相似,用于为 key 设置过期时间,不同在于,它的时间参数值采用的是时间戳格式。 |
PEXPIRE key | 设置 key 的过期,以毫秒为单位。 |
PEXPIREAT key | 与 PEXPIRE 相似,用于为 key 设置过期时间,采用以毫秒为单位的时间戳格式。 |
KEYS pattern | 此命令用于查找与指定 pattern 匹配的 key。 |
MOVE key db | 将当前数据库中的 key 移动至指定的数据库中(默认存储为 0 库,可选 1-15中的任意库)。 |
PERSIST key | 该命令用于删除 key 的过期时间,然后 key 将一直存在,不会过期。 |
PTTL key | 用于检查 key 还剩多长时间过期,以毫秒为单位。 |
TTL key | 用于检查 key 还剩多长时间过期,以秒为单位。 |
RANDOMKEY | 从当前数据库中随机返回一个 key。 |
RENAME key newkey | 修改 key 的名称。 |
RENAMENX key newkey | 如果新键名不重复,则将 key 修改为 newkey。 |
SCAN cursor | 基于游标的迭代器,用于迭代数据库中存在的所有键,cursor 指的是迭代游标。 |
TYPE key | 该命令用于获取 value 的数据类型。 |
Redis字符串命令
常用命令
命令 | 说明 |
---|---|
SET key value | 用于设定指定键的值。 |
GET key | 用于检索指定键的值。 |
GETRANGE key start end | 返回 key 中字符串值的子字符。 |
GETSET key value | 将给定 key 的值设置为 value,并返回 key 的旧值。 |
GETBIT key offset | 对 key 所存储的字符串值,获取其指定偏移量上的位(bit)。 |
MGET key1 [key2..] | 批量获取一个或多个 key 所存储的值,减少网络耗时开销。 |
SETBIT key offset value | 对 key 所储存的字符串值,设置或清除指定偏移量上的位(bit)。 |
SETEX key seconds value | 将值 value 存储到 key中 ,并将 key 的过期时间设为 seconds (以秒为单位)。 |
SETNX key value | 当 key 不存在时设置 key 的值。 |
SETRANGE key offset value | 从偏移量 offset 开始,使用指定的 value 覆盖的 key 所存储的部分字符串值。 |
STRLEN key | 返回 key 所储存的字符串值的长度。 |
MSET key value [key value ...] | 该命令允许同时设置多个键值对。 |
MSETNX key value [key value ...] | 当指定的 key 都不存在时,用于设置多个键值对。 |
PSETEX key milliseconds value | 此命令用于设置 key 的值和有过期时间(以毫秒为单位)。 |
INCR key | 将 key 所存储的整数值加 1。 |
INCRBY key increment | 将 key 所储存的值加上给定的递增值(increment)。 |
INCRBYFLOAT key increment | 将 key 所储存的值加上指定的浮点递增值(increment)。 |
DECR key | 将 key 所存储的整数值减 1。 |
DECRBY key decrement | 将 key 所储存的值减去给定的递减值(decrement)。 |
APPEND key value | 该命令将 value 追加到 key 所存储值的末尾。 |
Redis string 的SET/GET
命令只能一次设置/查询一个键值对,这样虽然简单,但是效率不高。为了提高命令的执行效率,Redis 提供了可以批量操作多个字符串的读写命令 MSET/MGET(“M”代表“Many”),它们允许你一次性设置或查询多个键值对,这样就有效地减少了网络耗时。
redis list列表
常用命令
命令 | 说明 |
---|---|
LPUSH key value1 [value2] | 在列表头部插入一个或者多个值。 |
LRANGE key start stop | 获取列表指定范围内的元素。 |
RPUSH key value1 [value2] | 在列表尾部添加一个或多个值。 |
LPUSHX key value | 当储存列表的 key 存在时,用于将值插入到列表头部。 |
RPUSHX key value | 当存储列表的 key 存在时,用于将值插入到列表的尾部。 |
LINDEX key index | 通过索引获取列表中的元素。 |
LINSERT key before|after pivot value | 指定列表中一个元素在它之前或之后插入另外一个元素。 |
LREM key count value | 表示从列表中删除元素与 value 相等的元素。count 表示删除的数量,为 0 表示全部移除。 |
LSET key index value | 表示通过其索引设置列表中元素的值。 |
LTRIM key start stop | 保留列表中指定范围内的元素值。 |
LPOP key | 从列表的头部弹出元素,默认为第一个元素。 |
RPOP key | 从列表的尾部弹出元素,默认为最后一个元素。 |
LLEN key | 用于获取列表的长度。 |
RPOPLPUSH source destination | 用于删除列表中的最后一个元素,然后将该元素添加到另一个列表的头部,并返回该元素值。 |
BLPOP key1 [key2 ] timeout | 用于删除并返回列表中的第一个元素(头部操作),如果列表中没有元素,就会发生阻塞, 直到列表等待超时或发现可弹出元素为止。 |
BRPOP key1 [key2 ] timeout | 用于删除并返回列表中的最后一个元素(尾部操作),如果列表中没有元素,就会发生阻塞, 直到列表等待超时或发现可弹出元素为止。 |
BRPOPLPUSH source destination timeout | 从列表中取出最后一个元素,并插入到另一个列表的头部。如果列表中没有元素,就会发生 阻塞,直到等待超时或发现可弹出元素时为止。 |
在线练习工具:https://try.redis.io/
Redis hash哈希散列(图解)
常用命令汇总
命令 | 说明 |
---|---|
HDEL key field2 [field2] | 用于删除一个或多个哈希表字段。 |
HEXISTS key field | 用于确定哈希表字段是否存在。 |
HGET key field | 获取 key 关联的哈希字段的值。 |
HGETALL key | 获取 key 关联的所有哈希字段值。 |
HINCRBY key field increment | 给 key 关联的哈希字段做整数增量运算 。 |
HINCRBYFLOAT key field increment | 给 key 关联的哈希字段做浮点数增量运算 。 |
HKEYS key | 获取 key 关联的所有字段和值。 |
HLEN key | 获取 key 中的哈希表的字段数量。 |
HMSET key field1 value1 [field2 value2 ] | 在哈希表中同时设置多个 field-value(字段-值) |
HMGET key field1 [field2] | 用于同时获取多个给定哈希字段(field)对应的值。 |
HSET key field value | 用于设置指定 key 的哈希表字段和值(field/value)。 |
HSETNX key field value | 仅当字段 field 不存在时,设置哈希表字段的值。 |
HVALS key | 用于获取哈希表中的所有值。 |
HSCAN key cursor | 迭代哈希表中的所有键值对,cursor 表示游标,默认为 0。 |
Redis set集合
命令 | 说明 |
---|---|
SADD key member1 [member2] | 向集合中添加一个或者多个元素,并且自动去重。 |
SCARD key | 返回集合中元素的个数。 |
SDIFF key1 [key2] | 求两个或多个集合的差集。 |
SDIFFSTORE destination key1 [key2] | 求两个集合或多个集合的差集,并将结果保存到指定的集合中。 |
SINTER key1 [key2] | 求两个或多个集合的交集。 |
SINTERSTORE destination key1 [key2] | 求两个或多个集合的交集,并将结果保存到指定的集合中。 |
SISMEMBER key member | 查看指定元素是否存在于集合中。 |
SMEMBERS key | 查看集合中所有元素。 |
SMOVE source destination member | 将集合中的元素移动到指定的集合中。 |
SPOP key [count] | 弹出指定数量的元素。 |
SRANDMEMBER key [count] | 随机从集合中返回指定数量的元素,默认返回 1个。 |
SREM key member1 [member2] | 删除一个或者多个元素,若元素不存在则自动忽略。 |
SUNION key1 [key2] | 求两个或者多个集合的并集。 |
SUNIONSTORE destination key1 [key2] | 求两个或者多个集合的并集,并将结果保存到指定的集合中。 |
SSCAN key cursor [match pattern] [count count] | 该命令用来迭代的集合中的元素。 |
Redis zset有序集合(底层原理+图解)
命令 | 说明 |
---|---|
ZADD key score1 member1 [score2 member2] | 用于将一个或多个成员添加到有序集合中,或者更新已存在成员的 score 值 |
ZCARD key | 获取有序集合中成员的数量 |
ZCOUNT key min max | 用于统计有序集合中指定 score 值范围内的元素个数。 |
ZINCRBY key increment member | 用于增加有序集合中成员的分值。 |
ZINTERSTORE destination numkeys key [key ...] | 求两个或者多个有序集合的交集,并将所得结果存储在新的 key 中。 |
ZLEXCOUNT key min max | 当成员分数相同时,计算有序集合中在指定词典范围内的成员的数量。 |
ZRANGE key start stop [WITHSCORES] | 返回有序集合中指定索引区间内的成员数量。 |
ZRANGEBYLEX key min max [LIMIT offset count] | 返回有序集中指定字典区间内的成员数量。 |
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT] | 返回有序集合中指定分数区间内的成员。 |
ZRANK key member | 返回有序集合中指定成员的排名。 |
ZREM key member [member ...] | 移除有序集合中的一个或多个成员。 |
ZREMRANGEBYLEX key min max | 移除有序集合中指定字典区间的所有成员。 |
ZREMRANGEBYRANK key start stop | 移除有序集合中指定排名区间内的所有成员。 |
ZREMRANGEBYSCORE key min max | 移除有序集合中指定分数区间内的所有成员。 |
ZREVRANGE key start stop [WITHSCORES] | 返回有序集中指定区间内的成员,通过索引,分数从高到低。 |
ZREVRANGEBYSCORE key max min [WITHSCORES] | 返回有序集中指定分数区间内的成员,分数从高到低排序。 |
ZREVRANK key member | 返回有序集合中指定成员的排名,有序集成员按分数值递减(从大到小)排序。 |
ZSCORE key member | 返回有序集中,指定成员的分数值。 |
ZUNIONSTORE destination numkeys key [key ...] | 求两个或多个有序集合的并集,并将返回结果存储在新的 key 中。 |
ZSCAN key cursor [MATCH pattern] [COUNT count] | 迭代有序集合中的元素(包括元素成员和元素分值)。 |
Redis连接命令详解
Redis连接命令
命令 | 说明 |
---|---|
AUTH password | 验证密码是否正确 |
ECHO message | 打印字符串 |
PING | 查看服务是否运行正常 |
QUIT | 关闭当前连接 |
SELECT index | 切换到指定的数据库 |
Redis客户端(client)命令
Redis IO多路复用
Redis 的底层是一个单线程模型,单线程指的是使用一个线程来处理所有的网络事件请求,这样就避免了多进程或者多线程切换导致的 CPU 消耗,而且也不用考虑各种锁的问题。
Redis 为了充分利用单线程,加快服务器的处理速度,它采用 IO 多路复用模型来处理客户端与服务端的连接,这种模型有三种实现方式,分别是 select、poll、epoll。Redis 正是采用 epoll 的方式来监控多个 IO 事件。当客户端空闲时,线程处于阻塞状态;当一个或多个 IO 事件触发时(客户端发起网路连接请求),线程就会从阻塞状态唤醒,并同时使用epoll
来轮询触发事件,并依次提交给线程处理。
注意:“多路”指的是多个网络连接,“复用”指的是复用同一个线程。多路 IO 复用技术可以让单个线程高效的处理多个连接请求。
常用命令
命令 | 说明 |
---|---|
CLIENT LIST | 以列表的形式返回所有连接到 Redis 服务器的客户端。 |
CLIENT SETNAME | 设置当前连接的名称。 |
CLIENT GETNAME | 获取通过 CLIENT SETNAME 命令设置的服务名称。 |
CLIENT PAUSE | 挂起客户端连接,将所有客户端挂起指定的时间(以毫秒为计算)。 |
CLIENT KILL | 关闭客户端连接。 |
CLIENT ID | 返回当前客户端 ID。 |
CLIENT REPLY | 控制发送到当前连接的回复,可选值包括 on|off|skip。 |
Redis服务器命令
下表介绍了 Redis 服务器的常用命令:
命令 | 说明 |
---|---|
BGREWRITEAOF | 在后台以异步的方式执行一个 AOF 文件的重写操作,对源文件进行压缩,使其体积变小。 AOF 是实现数据持久化存储的方式之一。 |
BGSAVE | 在后台执行初始化操作,并以异步的方式将当前数据库的数据保存到磁盘中。 |
CLIENT KILL [ip:port] [ID client-id] | 关闭客户端连接。 |
CLIENT LIST | 获取连接到服务器的客户端连接列表。 |
CLIENT GETNAME | 获取当前连接客户端的名称。 |
CLIENT PAUSE timeout | 使服务器在指定的时间停止执行来自客户端的命令。 |
CLIENT SETNAME connection-name | 设置当前连接客户端的名称。 |
COMMAND | 返回所有 Redis 命令的详细描述信息。 |
COMMAND COUNT | 此命令用于获取 Redis 命令的总数。 |
COMMAND GETKEYS | 获取指定命令的所有键。 |
INFO [section] | 获取 Redis 服务器的各种信息和统计数值。 |
COMMAND INFO command-name [command-name ...] | 用于获取指定 Redis 命令的描述信息。 |
CONFIG GET parameter | 获取指定配置参数的值。 |
CONFIG REWRITE | 修改启动 Redis 服务器时所指定的 redis.conf 配置文件。 |
CONFIG SET parameter value | 修改 Redis 配置参数,无需重启。 |
CONFIG RESETSTAT | 重置 INFO 命令中的某些统计数据。 |
DBSIZE | 返回当前数据库中 key 的数量。 |
DEBUG OBJECT key | 获取 key 的调试信息。当 key 存在时,返回有关信息;当 key 不存在时,返回一个错误。 |
DEBUG SEGFAULT | 使用此命令可以让服务器崩溃。 |
FLUSHALL | 清空数据库中的所有键。 |
FLUSHDB | 清空当前数据库的所有 key。 |
LASTSAVE | 返回最近一次 Redis 成功将数据保存到磁盘上的时间,以 UNIX 格式表示。 |
MONITOR | 实时打印出 Redis 服务器接收到的命令。 |
ROLE | 查看主从实例所属的角色,角色包括三种,分别是 master、slave、sentinel。 |
SAVE | 执行数据同步操作,将 Redis 数据库中的所有数据以 RDB 文件的形式保存到磁盘中。 RDB 是 Redis 中的一种数据持久化方式。 |
SHUTDOWN [NOSAVE] [SAVE] | 将数据同步到磁盘后,然后关闭服务器。 |
SLAVEOF host port | 此命令用于设置主从服务器,使当前服务器转变成为指定服务器的从属服务器, 或者将其提升为主服务器(执行 SLAVEOF NO ONE 命令)。 |
SLOWLOG subcommand [argument] | 用来记录查询执行时间的日志系统。 |
SYNC | 用于同步主从服务器。 |
SWAPDB index index | 用于交换同一 Redis 服务器上的两个数据库,可以实现访问其中一个数据库的客户端连接,也可以立即访问另外一个数据库的数据。 |
TIME | 此命令用于返回当前服务器时间。 |
注意:上述一些命令在后续内容还会做相应介绍,比如 Redis 主从服务器设置,以及 Redis 数据持久化等。
Redis PubSub发布订阅(详细图解)
发布/订阅流程
下面的示例演示了“发布/订阅者”模式的工作流程,示意图如下所示:
1) 订阅者/等待接收消息
首先打开 Redis 客户端,然后订阅了一个名为“www.biancheng.net”的 channel,使用如下命令:
#订阅channel 127.0.0.1:6379> SUBSCRIBE www.biancheng.net Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "www.biancheng.net" 3) (integer) 1
上述示例使用SUBSCRIBE
命令订阅了名为 www.biancheng.net 的 channel。命令执行后该客户端会出处于等待接收消息的阻塞状态。
2) 发布者/发送消息
下面再启动一个 Redis 客户端,输入如下命令:
127.0.0.1:6379> PUBLISH www.biancheng.net "this is website" (integer) 1 127.0.0.1:6379> PUBLISH www.biancheng.net "hello world" (integer) 1 127.0.0.1:6379> PUBLISH www.biancheng.net "how are you" (integer) 1
通过上述PUBLISH
命令发布了三条信息。现在两个客户端在处于同一个名为“www.biancheng.net”的频道上,前者负责接收消息,后者负责发布消息。
3) 订阅者/成功接收消息
完成了上述操作后,您会在接收消息的客户端得到如下输出结果:
127.0.0.1:6379> SUBSCRIBE www.biancheng.net Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "www.biancheng.net" 3) (integer) 1 1) "message" 2) "www.biancheng.net"
命令 | 说明 |
---|---|
PSUBSCRIBE pattern [pattern ...] | 订阅一个或多个符合指定模式的频道。 |
PUBSUB subcommand [argument [argument ...]] | 查看发布/订阅系统状态,可选参数 1) channel 返回在线状态的频道。 2) numpat 返回指定模式的订阅者数量。 3) numsub 返回指定频道的订阅者数量。 |
PUBSUB subcommand [argument [argument ...]] | 将信息发送到指定的频道。 |
PUNSUBSCRIBE [pattern [pattern ...]] | 退订所有指定模式的频道。 |
SUBSCRIBE channel [channel ...] | 订阅一个或者多个频道的消息。 |
UNSUBSCRIBE [channel [channel ...]] | 退订指定的频道。 |
Redis Stream消息队列
什么是Stream?
Stream 实际上是一个具有消息发布/订阅功能的组件,也就常说的消息队列。其实这种类似于 broker/consumer(生产者/消费者)的数据结构很常见,比如 RabbitMQ 消息中间件、Celery 消息中间件,以及 Kafka 分布式消息系统等,而 Redis Stream 正是借鉴了 Kafaka 系统。
1) 优点
Strean 除了拥有很高的性能和内存利用率外, 它最大的特点就是提供了消息的持久化存储,以及主从复制功能,从而解决了网络断开、Redis 宕机情况下,消息丢失的问题,即便是重启 Redis,存储的内容也会存在。
2) 流程
Stream 消息队列主要由四部分组成,分别是:消息本身、生产者、消费者和消费组,对于前述三者很好理解,下面了解什么是消费组。
一个 Stream 队列可以拥有多个消费组,每个消费组中又包含了多个消费者,组内消费者之间存在竞争关系。当某个消费者消费了一条消息时,同组消费者,都不会再次消费这条消息。被消费的消息 ID 会被放入等待处理的 Pending_ids 中。每消费完一条信息,消费组的游标就会向前移动一位,组内消费者就继续去争抢下消息。
Redis Stream 消息队列结构程如下图所示:
下面对上图涉及的专有名词做简单解释:
- Stream direction:表示数据流,它是一个消息链,将所有的消息都串起来,每个消息都有一个唯一标识 ID 和对应的消息内容(Message content)。
- Consumer Group :表示消费组,拥有唯一的组名,使用 XGROUP CREATE 命令创建。一个 Stream 消息链上可以有多个消费组,一个消费组内拥有多个消费者,每一个消费者也有一个唯一的 ID 标识。
- last_delivered_id :表示消费组游标,每个消费组都会有一个游标 last_delivered_id,任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动。
- pending_ids :Redis 官方称为 PEL,表示消费者的状态变量,它记录了当前已经被客户端读取的消息 ID,但是这些消息没有被 ACK(确认字符)。如果客户端没有 ACK,那么这个变量中的消息 ID 会越来越多,一旦被某个消息被 ACK,它就开始减少。
3) ACK
ACK(Acknowledge character)即确认字符,在数据通信中,接收方传递给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。在 TCP/IP 协议中,如果接收方成功的接收到数据,那么会回复一个 ACK 数据。通常 ACK 信号有自己固定的格式,长度大小,由接收方回复给发送方。
常用命令汇总
命令 | 说明 |
---|---|
XADD | 添加消息到末尾。 |
XTRIM | 对 Stream 流进行修剪,限制长度。 |
XDEL | 删除指定的消息。 |
XLEN | 获取流包含的元素数量,即消息长度。 |
XRANGE | 获取消息列表,会自动过滤已经删除的消息。 |
XREVRANGE | 反向获取消息列表,ID 从大到小。 |
XREAD | 以阻塞或非阻塞方式获取消息列表。 |
XGROUP CREATE | 创建消费者组。 |
XREADGROUP GROUP | 读取消费者组中的消息。 |
XACK | 将消息标记为"已处理"。 |
XGROUP SETID | 为消费者组设置新的最后递送消息ID。 |
XGROUP DELCONSUMER | 删除消费者。 |
XGROUP DESTROY | 删除消费者组。 |
XPENDING | 显示待处理消息的相关信息。 |
XCLAIM | 转移消息的归属权。 |
XINFO | 查看 Stream 流、消费者和消费者组的相关信息。 |
XINFO GROUPS | 查看消费者组的信息。 |
XINFO STREAM | 查看 Stream 流信息。 |
XINFO CONSUMERS key group | 查看组内消费者流信息。 |
Redis布隆过滤器(原理+图解)
安装与使用
在 Redis 4.0 版本之后,布隆过滤器才作为插件被正式使用。布隆过滤器需要单独安装,下面介绍安装 RedisBloom 的几种方法:
1) docker安装
docker 安装布隆过滤器是最简单、快捷的一种方式:
docker pull redislabs/rebloom:latest docker run -p 6379:6379 --name redis-redisbloom redislabs/rebloom:latest docker exec -it redis-redisbloom bash redis-cli #测试是否安装成功 127.0.0.1:6379> bf.add www.biancheng.net hello
2) 直接编译安装
如果您对 docker 不熟悉,也可以采用直接编译的方式来安装。
下载地址: https://github.com/RedisBloom/RedisBloom 解压文件: unzip RedisBloom-master.zip 进入目录: cd RedisBloom-master 执行编译命令,生成redisbloom.so 文件: make 拷贝至指定目录: cp redisbloom.so /usr/local/redis/bin/redisbloom.so 在redis配置文件里加入以下配置: loadmodule /usr/local/redis/bin/redisbloom.so 配置完成后重启redis服务: sudo /etc/init.d/redis-server restart #测试是否安装成功 127.0.0.1:6379> bf.add www.biancheng.net hello
常用命令汇总
命令 | 说明 |
---|---|
bf.add | 只能添加元素到布隆过滤器。 |
bf.exists | 判断某个元素是否在于布隆过滤器中。 |
bf.madd | 同时添加多个元素到布隆过滤器。 |
bf.mexists | 同时判断多个元素是否存在于布隆过滤器中。 |
bf.reserve | 以自定义的方式设置布隆过滤器参数值,共有 3 个参数分别是 key、error_rate(错误率)、initial_size(初始大小)。 |
1) 命令应用
127.0.0.1:6379> bf.add spider:url www.biancheng.net (integer) 1 127.0.0.1:6379> bf.exists spider:url www.biancheng.net (integer) 1 127.0.0.1:6379> bf.madd spider:url www.taobao.com www.123qq.com 1) (integer) 1 2) (integer) 1 127.0.0.1:6379> bf.mexists spider:url www.jd.com www.taobao.com 1) (integer) 0 2) (integer) 1
Redis Transaction事务
Redis事务特性
Redis 事务具有两个重要特性:
1) 单独的隔离操作
事务中的所有命令都会被序列化,它们将按照顺序执行,并且在执行过的程中,不会被其他客户端发送来的命令打断。
2) 不保证原子性
在 Redis 的事务中,如果存在命令执行失败的情况,那么其他命令依然会被执行,不支持事务回滚机制。
Redis事务命令
命令 | 说明 |
---|---|
MULTI | 开启一个事务 |
EXEC | 执行事务中的所有命令 |
WATCH key [key ...] | 在开启事务之前用来监视一个或多个key 。如果事务执行时这些 key 被改动过,那么事务将被打断。 |
DISCARD | 取消事务。 |
UNWATCH | 取消 WATCH 命令对 key 的监控。 |
Redis Lua脚本
第一个Lua脚本命令
Lua 是一种轻量小巧、开源的脚本语言,用标准 C语言编写。其设计目的就是为了嵌入应用程序中,从而为应用程序提供灵活的扩展和定制功能。它被广泛的应用于:游戏开发、独立应用脚本、Web 应用脚本、扩展和数据库插件等。
Redis 使用EVAL
命令编写 lua 脚本,其语法格式如下:
127.0.0.1:6379> EVAL script numkeys key [key ...] arg [arg ...]
参数说明如下:
- script: 该参数表示使用 Lua 语言编写的一段脚本程序,该脚本不必定义为 Lua 函数格式;
- numkeys: 用于指定 key 参数的数量;
- key [key ...]: 从 EVAL 命令的第三个参数算起,表示脚本中用到的所有 key。这些 key 可以使用全局变量 KEYS 数组来访问,比如 KEYS[1] 、KEYS[2] 以此类推。
- arg [arg ...]:表示附加参数,在 Lua 语言中通过全局变量 ARGV 数组访问,访问的形式与 KEYS 数组相同,比如 ARGV[1] 、 ARGV[2]。
举一个简单的示例:在 Redis 客户端使用 Lua 语言编写“Hello World”并将其输出。
127.0.0.1:6379> EVAL "return 'Hello world'" 0 "Hello world"
常用脚本命令
命令 | 说明 |
---|---|
EVAL script numkeys key [key ...] arg [arg ...] | 使用 Lua 解释器执行脚本。 |
EVALSHA sha1 numkeys key [key ...] arg [arg ...] | Lua 解释器根据 sha1 校验码执行脚本。 |
SCRIPT EXISTS script [script ...] | 查看指定的脚本是否保存在于缓存当中。 |
SCRIPT FLUSH | 从脚本缓存中移除所有脚本。 |
SCRIPT KILL | 杀死当前正在运行的 Lua 脚本。 |
SCRIPT LOAD script | 将脚本 script 添加到脚本缓存中,但不马上执行这个脚本。 |
Redis Benchmark性能测试
Redis 提供了一种行性能测试工具 redis-benchmark(也称压力测试工具),它通过同时执行多组命令实现对 Redis 的性能测试。
性能测试的作用是让我们了解 Redis 服务器的性能优劣。在实际的业务场景中,性能测试是必不可少的。在业务系统上线之前,我们都需要清楚地了解 Redis 服务器的性能,从而避免发生某些意外情况,比如数据量过大会导致服务器宕机等。
测试命令格式
执行测试命令,要在 Redis 的安装目录下执行,命令如下所示:
redis-benchmark [option] [option value]
其中 option 为可选参数, option value 为具体的参数值。 redis-benchmark 命令的可选参数如下所示:
参数选项 | 说明 |
---|---|
-h | 指定服务器主机名。 |
-p | 指定服务器端口。 |
-s | 指定服务器 socket。 |
-c | 指定并发连接数。 |
-n | 指定请求的具体数量。 |
-d | 以字节的形式指定 SET/GET 值的数据大小。 |
-k | 1 表示 keep alive;0 表示 reconnect,默认为 1。 |
-r | SET/GET/INCR 使用随机 key, SADD 使用随机值。 |
-P | Pipeline 请求 |
-q | 强制退出 Redis,仅显示 query/sec 值。 |
--csv | 以 CSV 格式输出。 |
-l | 生成循环,永久执行测试。 |
-t | 仅运行以逗号分隔的测试命令列表。 |
-I(大写i) | 空闲模式,打开 N 个空闲连接并等待连接。 |
在 Windows 系统下,其目录文件如图所示:
Redis分区技术详解
分区常用方法
分区技术有两种常用方法,分别是“范围分区”和“哈希分区”。
Redis Pipeline管道技术
它能够把多次网络请求打包成一次请求发送给服务端,从而减少多次请求的“往返时间”。
执行Pipeline语句
Pipeline 技术有其固定的语法格式,以下是在 Linux 终端执行的语句,具体命令如下:
(echo -en "PING\r\n SET name www.biancheng\r\n GET name\r\n INCR num\r\n INCR num\r\n INCR num\r\n"; sleep 2)|nc localhost 6379
上述语句,首先使用 PING 命令检查 Redis 是否正常工作,然后又分别使用了 SET/GET/INCR 命令,以及 sleep 阻塞 2 秒,最后将这些命令一次性的提交给 Redis 服务器,Redis 服务器在阻塞了 2 秒之后,一次性输出了所有命令的响应信息。
客户端一次性接收到所有命令的执行结果,如下所示:
$(echo -en "PING\r\n SET name www.biancheng\r\n GET name\r\n INCR num\r\n INCR num\r\n INCR num\r\n"; sleep 2)|nc localhost 6379 +PONG +OK www.bianchneg.net :1 :2 :3
Redis数据备份和还原
Redis SAVE 命令用于创建当前数据库的备份文件,文件名默认为dump.rdb
。备份数据库数据可以增强对数据的保护,提升数据的安全性。当数据不小心丢失或者被删除时,我们就可以通过相应的操作进行数据恢复。本节介绍 Redis 的数据备份和数据还原操作。
备份数据
SAVE 命令基本语法如下:
redis 127.0.0.1:6379> SAVE
执行备份命令:
redis 127.0.0.1:6379> SAVE OK
注意:命令执行后,将在 Redis 安装目录中自动创建dump.rdb
文件。如下图所示:
恢复数据
如果您想恢复数据,只需将备份文件 dump.rdb 移动到 Redis 安装目录下,然后重启 Redis 服务器,即可进行数据还原。
下面使用CONFIG
命令获取 Redis 安装目录,如下所示:
127.0.0.1:6379> CONFIG GET dir 1) "dir" 2) "D:\\Redis-x64-5.0.10"
从上述命令可以得知 Redis 的安装目录为 D:\\Redis-x64-5.0.10。
后台备份数据
Redis 还提供了一个BGSAVE
命令,同样也可以创建 Redis 备份文件,它与SAVE
命令的不同之处在于,该命令在后台运行。示例演示:
127.0.0.1:6379> BGSAVE Background saving started
Redis RDB持久化详解(原理+配置策略)
RDB快照模式原理
RDB 即快照模式,它是 Redis 默认的数据持久化方式,它会将数据库的快照保存在 dump.rdb 这个二进制文件中。
提示:所谓“快照”就是将内存数据以二进制文件的形式保存起来。
Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化操作。
RDB 实际上是 Redis 内部的一个定时器事件,它每隔一段固定时间就去检查当前数据发生改变的次数和改变的时间频率,看它们是否满足配置文件中规定的持久化触发条件。当满足条件时,Redis 就会通过操作系统调用 fork() 来创建一个子进程,该子进程与父进程享有相同的地址空间。
RDB持久化触发策略
RDB 持久化提供了两种触发策略:一种是手动触发,另一种是自动触发。
1) 手动触发策略
手动触发是通过SAVAE
命令或者BGSAVE
命令将内存数据保存到磁盘文件中。如下所示:
2) 自动触发策略
自动触发策略,是指 Redis 在指定的时间内,数据发生了多少次变化时,会自动执行BGSAVE
命令。自动触发的条件包含在了 Redis 的配置文件中
save m n 的含义是在时间 m 秒内,如果 Redis 数据至少发生了 n 次变化,那么就自动执行BGSAVE
命令。配置策略说明如下:
- save 900 1 表示在 900 秒内,至少更新了 1 条数据,Redis 自动触发 BGSAVE 命令,将数据保存到硬盘。
- save 300 10 表示在 300 秒内,至少更新了 10 条数据,Redis 自动触 BGSAVE 命令,将数据保存到硬盘。
- save 60 10000 表示 60 秒内,至少更新了 10000 条数据,Redis 自动触发 BGSAVE 命令,将数据保存到硬盘。
Redis AOF持久化详解(含配置策略)
开启AOF持久化
AOF 机制默认处于未开启状态,可以通过修改 Redis 配置文件开启 AOF,如下所示:
1) Windows系统
执行如下操作:
#修改配置文件,把no改为 yes appendonly yes #确定存储文件名是否正确 appendfilename "appendonly.aof" #重启服务器 redis-server --service-stop redis-server --service-start
2) Linux系统
执行如下操作:
#修改配置文件: vim /etc/redis/redis.conf appendonly yes # 把 no 改为 yes #确定存储文件名是否正确 appendfilename "appendonly.aof" #重启服务: sudo /etc/init.d/redis-server restart
AOF持久化机制
1) 写入机制
Redis 在收到客户端修改命令后,先进行相应的校验,如果没问题,就立即将该命令存追加到 .aof 文件中,也就是先存到磁盘中,然后服务器再执行命令。这样就算遇到了突发的宕机情况情况,也只需将存储到 .aof 文件中的命令,进行一次“命令重演”就可以恢复到宕机前的状态。
在上述执行过程中,有一个很重要的环节就是命令的写入,这是一个 IO 操作。Redis 为了提升写入效率,它不会将内容直接写入到磁盘中,而是将其放到一个内存缓存区(buffer)中,等到缓存区被填满时才真正将缓存区中的内容写入到磁盘里。
2) 重写机制
Redis 在长期运行的过程中,aof 文件会越变越长。如果机器宕机重启,“重演”整个 aof 文件会非常耗时,导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。
为了让 aof 文件的大小控制在合理的范围内,Redis 提供了 AOF 重写机制,手动执行BGREWRITEAOF
命令,开始重写 aof 文件,如下所示:
127.0.0.1:6379> BGREWRITEAOF Background append only file rewriting started
通过上述操作后,服务器会生成一个新的 aof 文件,该文件具有以下特点:
- 新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致;
- 新的 aof 文件会使用尽可能少的命令来记录数据库数据,因此新的 aof 文件的体积会小很多;
- AOF 重写期间,服务器不会被阻塞,它可以正常处理客户端发送的命令。
3) 自动触发AOF重写
Redis 为自动触发 AOF 重写功能,提供了相应的配置策略。如下所示:修改 Redis 配置文件,让服务器自动执行 BGREWRITEAOF 命令。
#默认配置项 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。
该配置项表示:触发重写所需要的 aof 文件体积百分比,只有当 aof 文件的增量大于 100% 时才进行重写,也就是大一倍。比如,第一次重写时文件大小为 64M,那么第二次触发重写的体积为 128M,第三次重写为 256M,以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。
上述配置策略说明如下:
- Always:服务器每写入一个命令,就调用一次 fsync 函数,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据,但是其执行速度较慢;
- Everysec(默认):服务器每一秒调用一次 fsync 函数,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据,通常都使用它作为 AOF 配置策略;
- No:服务器不主动调用 fsync 函数,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的,所以这种策略,不确定性较大,不安全。
AOF和RDB对比
RDB持久化 | AOF持久化 |
---|---|
全量备份,一次保存整个数据库。 | 增量备份,一次只保存一个修改数据库的命令。 |
每次执行持久化操作的间隔时间较长。 | 保存的间隔默认为一秒钟(Everysec) |
数据保存为二进制格式,其还原速度快。 | 使用文本格式还原数据,所以数据还原速度一般。 |
执行 SAVE 命令时会阻塞服务器,但手动或者自动触发的 BGSAVE 不会阻塞服务器 | AOF持久化无论何时都不会阻塞服务器。 |
如果进行数据恢复时,既有 dump.rdb文件,又有 appendonly.aof 文件,您应该先通过 appendonly.aof 恢复数据,这能最大程度地保证数据的安全性。
Redis Cluster主从模式详解
主从模式解析
主从模式的结构图如下:
如图 1 所示,Redis 主机会一直将自己的数据复制给 Redis 从机,从而实现主从同步。在这个过程中,只有 master 主机可执行写命令,其他 salve 从机只能只能执行读命令,这种读写分离的模式可以大大减轻 Redis 主机的数据读取压力,从而提高了Redis 的效率,并同时提供了多个数据备份。主从模式是搭建 Redis Cluster 集群最简单的一种方式。
主从模式实现
Redis 提供了两种实现主从模式的方法,下面进行逐一介绍。为了方便演示,我们只从一台机器上搭建主从模式。
1) 使用命令实现
使用命令在服务端搭建主从模式,其语法格式如下:
redis-server --port--slaveof
执行以下命令:
#开启开启一个port为6300的从机,它依赖的主机port=6379 C:\Users\Administrator> redis-server --port 6300 --slaveof 127.0.0.1 6379
主从模式不足
主从模式并不完美,它也存在许多不足之处,下面做了简单地总结:
- 1) Redis 主从模式不具备自动容错和恢复功能,如果主节点宕机,Redis 集群将无法工作,此时需要人为干预,将从节点提升为主节点。
- 2) 如果主机宕机前有一部分数据未能及时同步到从机,即使切换主机后也会造成数据不一致的问题,从而降低了系统的可用性。
- 3) 因为只有一个主节点,所以其写入能力和存储能力都受到一定程度地限制。
- 4) 在进行数据全量同步时,若同步的数据量较大可能会造卡顿的现象。
Redis集群:Sentinel哨兵模式(详细图解)
哨兵模式原理
哨兵模式是一种特殊的模式,Redis 为其提供了专属的哨兵命令,它是一个独立的进程,能够独立运行。下面使用 Sentinel 搭建 Redis 集群,基本结构图如下所示:
在上图过程中,哨兵主要有两个重要作用:
- 第一:哨兵节点会以每秒一次的频率对每个 Redis 节点发送
PING
命令,并通过 Redis 节点的回复来判断其运行状态。 - 第二:当哨兵监测到主服务器发生故障时,会自动在从节点中选择一台将机器,并其提升为主服务器,然后使用 PubSub 发布订阅模式,通知其他的从节点,修改配置文件,跟随新的主服务器。
在实际生产情况中,Redis Sentinel 是集群的高可用的保障,为避免 Sentinel 发生意外,它一般是由 3~5 个节点组成,这样就算挂了个别节点,该集群仍然可以正常运转。其结构图如下所示:
上图所示,多个哨兵之间也存在互相监控,这就形成了多哨兵模式,现在对该模式的工作过程进行讲解,介绍如下:
1) 主观下线
主观下线,适用于主服务器和从服务器。如果在规定的时间内(配置参数:down-after-milliseconds),Sentinel 节点没有收到目标服务器的有效回复,则判定该服务器为“主观下线”。比如 Sentinel1 向主服务发送了PING
命令,在规定时间内没收到主服务器PONG
回复,则 Sentinel1 判定主服务器为“主观下线”。
2) 客观下线
客观下线,只适用于主服务器。 Sentinel1 发现主服务器出现了故障,它会通过相应的命令,询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉,则 Sentinel1 节点判定主服务为“客观下线”。
3) 投票选举
投票选举,所有 Sentinel 节点会通过投票机制,按照谁发现谁去处理的原则,选举 Sentinel1 为领头节点去做 Failover(故障转移)操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器,然后通过发布订功能通知其余的从节点(slave)更改配置文件,跟随新上任的主服务器(master)。至此就完成了主从切换的操作。
sentinel.conf配置项
下面对 Sentinel 配置文件的其他配置项做简单说明:配置项 | 参数类型 | 说明 |
---|---|---|
dir | 文件目录 | 哨兵进程服务的文件存放目录,默认为 /tmp。 |
port | 端口号 | 启动哨兵的进程端口号,默认为 26379。 |
sentinel down-after-milliseconds | <服务名称><毫秒数(整数)> | 在指定的毫秒数内,若主节点没有应答哨兵的 PING 命令,此时哨兵认为服务器主观下线,默认时间为 30 秒。 |
sentinel parallel-syncs | <服务名称><服务器数(整数)> | 指定可以有多少个 Redis 服务同步新的主机,一般而言,这个数字越小同步时间越长,而越大,则对网络资源要求就越高。 |
sentinel failover-timeout | <服务名称><毫秒数(整数)> | 指定故障转移允许的毫秒数,若超过这个时间,就认为故障转移执行失败,默认为 3 分钟。 |
sentinel notification-script | <服务名称><脚本路径> | 脚本通知,配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员。 |
sentinel auth-pass |
<服务器名称><密码> | 若主服务器设置了密码,则哨兵必须也配置密码,否则哨兵无法对主从服务器进行监控。该密码与主服务器密码相同。 |
Redis分布式锁应用(实现+原理)
Redis分布式锁命令
分布式锁的本质其实就是要在 Redis 里面占一个“坑”,当别的进程也要来占时,发现已经有人蹲了,就只好放弃或者稍做等待。这个“坑”同一时刻只允许被一个客户端占据,也就是本着“先来先占”的原则。
1) 常用命令
Redis 分布式锁常用命令如下所示:
- SETNX key val:仅当key不存在时,设置一个 key 为 value 的字符串,返回1;若 key 存在,设置失败,返回 0;
- Expire key timeout:为 key 设置一个超时时间,以 second 秒为单位,超过这个时间锁会自动释放,避免死锁;
- DEL key:删除 key。
上述 SETNX 命令相当于占“坑”操作,EXPIRE 是为避免出现意外用来设置锁的过期时间,也就是说到了指定的过期时间,该客户端必须让出锁,让其他客户端去持有。
但还有一种情况,如果在 SETNX 和 EXPIRE 之间服务器进程突然挂掉,也就是还未设置过期时间,这样就会导致 EXPIRE 执行不了,因此还是会造成“死锁”的问题。为了避免这个问题,Redis 作者在 2.6.12 版本后,对 SET 命令参数做了扩展,使它可以同时执行 SETNX 和 EXPIRE 命令,从而解决了死锁的问题。
直接使用 SET 命令实现,语法格式如下:
SET key value [expiration EX seconds|PX milliseconds] [NX|XX]
- EX second:设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
- PX millisecond:设置键的过期时间为毫秒。SET key value PX millisecond 效果等同于 PSETEX key millisecondvalue 。
- NX:只在键不存在时,才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
- XX:只在键已经存在时,才对键进行设置操作。
Redis缓存问题(图解:三种缓存问题)
缓存穿透
缓存穿透是指当用户查询某个数据时,Redis 中不存在该数据,也就是缓存没有命中,此时查询请求就会转向持久层数据库 MySQL,结果发现 MySQL 中也不存在该数据,MySQL 只能返回一个空对象,代表此次查询失败。如果这种类请求非常多,或者用户利用这种请求进行恶意攻击,就会给 MySQL 数据库造成很大压力,甚至于崩溃,这种现象就叫缓存穿透。
为了避免缓存穿透问题,下面介绍两种解决方案:
1) 缓存空对象
当 MySQL 返回空对象时, Redis 将该对象缓存起来,同时为其设置一个过期时间。当用户再次发起相同请求时,就会从缓存中拿到一个空对象,用户的请求被阻断在了缓存层,从而保护了后端数据库,但是这种做法也存在一些问题,虽然请求进不了 MSQL,但是这种策略会占用 Redis 的缓存空间。
2) 布隆过滤器
我们知道,布隆过滤器判定不存在的数据,那么该数据一定不存在,利用它的这一特点可以防止缓存穿透。
首先将用户可能会访问的热点数据存储在布隆过滤器中(也称缓存预热),当有一个用户请求到来时会先经过布隆过滤器,如果请求的数据,布隆过滤器中不存在,那么该请求将直接被拒绝,否则将继续执行查询。相较于第一种方法,用布隆过滤器方法更为高效、实用。其流程示意图如下:
图2:缓存穿透问题解决
缓存预热:是指系统启动时,提前将相关的数据加载到 Redis 缓存系统中。这样避免了用户请求的时再去加载数据。
缓存击穿
缓存击穿是指用户查询的数据缓存中不存在,但是后端数据库却存在,这种现象出现原因是一般是由缓存中 key 过期导致的。比如一个热点数据 key,它无时无刻都在接受大量的并发访问,如果某一时刻这个 key 突然失效了,就致使大量的并发请求进入后端数据库,导致其压力瞬间增大。这种现象被称为缓存击穿。
缓存击穿有两种解决方法:
1) 改变过期时间
设置热点数据永不过期。
2) 分布式锁
采用分布式锁的方法,重新设计缓存的使用方式,过程如下:
- 上锁:当我们通过 key 去查询数据时,首先查询缓存,如果没有,就通过分布式锁进行加锁,第一个获取锁的进程进入后端数据库查询,并将查询结果缓到Redis 中。
- 解锁:当其他进程发现锁被某个进程占用时,就进入等待状态,直至解锁后,其余进程再依次访问被缓存的 key。
缓存雪崩
缓存雪崩是指缓存中大批量的 key 同时过期,而此时数据访问量又非常大,从而导致后端数据库压力突然暴增,甚至会挂掉,这种现象被称为缓存雪崩。它和缓存击穿不同,缓存击穿是在并发量特别大时,某一个热点 key 突然过期,而缓存雪崩则是大量的 key 同时过期,因此它们根本不是一个量级。
?解决方案
缓存雪崩和缓存击穿有相似之处,所以也可以采用热点数据永不过期的方法,来减少大批量的 key 同时过期。再者就是为 key 设置随机过期时间,避免 key 集中过期。
基本配置
port 6379 # 监听端口号,默认为6379,如果你设为 0 ,redis 将不在 socket 上监听任何客户端连接。 daemonize no #指定redis是否以守护线程的方式启动 databases 16 #创建database的数量,默认为0库 save 900 1 #刷新快照到硬盘中。必须满足下列三个要求之一才会触发,即900秒内至少有1个key发生变化。 save 300 10 #在300秒内至少10个key发生变化。 save 60 10000 #在60秒之内至少有10000个可以发生变化。 stop-writes-on-bgsave-error yes #后台存储错误并停止写入命令。 rdbcompression yes #使用LZF方式压缩rdb文件。如果你想节省一些CPU可设置成'no' rdbchecksum yes #在存储、加载rdb文件时进行校验。 dbfilename dump.rdb #设置rdb文件名。 dir ./ #设置工作目录,rdb文件会自动存放在该目录。
主从服务配置
slaveof#将本机设为某台机器的从服务器 masterauth #连接主服务器的密码 slave-serve-stale-data yes # 当主机和从机断开时或这正处于在复制过程中,是否让从服务器是应答请求 slave-read-only yes #设置从服务器为只读模式 repl-diskless-sync no #是否同时向多个从服务器节点同时发数据 repl-diskless-sync-delay 5 #发送数据的延迟时间 repl-ping-slave-period 10 #主节点默认每隔 10 秒对从节点发送 ping 命令 repl-timeout 60 #主从服务器超时时间(超时认为断线了),要比period设置的时间大 #如果master不能再正常工作,那么会在多个slave中,选择优先值最小的一个slave提升为master, #优先值为0表示不能提升为master,一般在哨兵sentinel环境中使用。 slave-priority 100 #在slave和master同步后,后续的同步是否设置成TCP_NODELAY,设置成no,则redis master会立即发送同步数据,没有延迟 repl-disable-tcp-nodelay no min-slaves-to-write 3 #主节点仅允许当能够通信的从节点数量大于等于此处的值时,才允许接受写操作; min-slaves-max-lag 10 #从节点延迟时长超出此处指定的时间时,主节点会拒绝写入操作;
安全配置
requirepass foobared # 用来配置密码 rename-command CONFIG b84 #在公共环境下重命名部分敏感命令 如config、flushall等
限制配置
maxclients 10000 #最大连接数 maxmemory#最大使用内存 maxmemory-policy volatile-lru #内存到极限后的处理策略 #内存处理策略,用于在超出内存限制时,删除一些key volatile-lru # LRU算法删除过期key allkeys-lru # LRU算法删除key(不区分过不过期) volatile-random # 随机删除过期key allkeys-random # 随机删除key(不区分过不过期) volatile-ttl # 删除快过期的key noeviction # 禁止删除key,这如果内存不足,会直接返回错误。默认配置 #用于提高LRU/TTL算法的精准度,在自动清理内存时,指定的数字越大,CPU消耗就越多,默认为5。 maxmemory-samples 5
AOF日志模式
appendonly no #是否启用日志模式 appendfsync no # 有系统决定何时写,统一写,速度快 appendfsync always # 系统不缓冲,一直写,但是慢,这种方式几乎不丢失数据 appendfsync everysec #每秒写1次 no-appendfsync-on-rewrite no #相当于将appendfsync设置为no,不存在磁盘操作,只是将数据写入了缓冲区,写入速度非常快 auto-AOF-rewrite-percentage 100 #触发aof重写操作,要求本次文件大小比上次重写时要增加1(100%)倍 auto-AOF-rewrite-min-size 64mb #触发aof重写操作,至少要达到的aof文件大小
慢查询配置
Redis slowlog 是一个记录 Redis 执行查询命令时所耗费时间的日志系统,它仅记录执行一个查询命令所耗费的时间,不记录其他内容。
slowlog-log-slower-than 10000 #记录响应时间大于10000微秒的慢查询 slowlog-max-len 128 # 最多记录128条
服务端命令
time #返回时间戳+微秒 dbsize #返回key的数量 bgrewriteaof #重写aof bgsave #后台开启子进程来执行数据持久化 save #以阻塞的方式对数据进行持久化 lastsave #返回最近一次 Redis 成功将数据保存到磁盘上的时间,以 UNIX 时间戳格式表示。 slaveof host port #设置为host:port的从服务器(数据清空,复制新的主服务器内容) slaveof no one #变成主服务器(原数据不丢失,一般用于主服失败后) flushdb 清空当前数据库的所有数据 flushall 清空所有数据库的所有数据 shutdown [save/nosave] 关闭服务器,保存数据,修改AOF slowlog get 获取慢查询日志 slowlog len 获取慢查询日志条数 slowlog reset 清空慢查询
客户端命令
#以易于理解和阅读的方式返回Redis服务器的各种信息、统计数值 info [server|clients|memory|stats|] config get [配置项] #获取配置文件选项 config set [配置项] [参数值] #重新设置配置文件选项和对应参数 config rewrite #对启动Redis服务器时所指定的配置文件进行改写 config resetstat #重置info命令中的某些统计信息 debug object key #调试选项,看一个key的情况 debug segfault #该命令能够让服务器崩溃 object key (refcount|encoding|idletime) monitor #调试用,打开控制台,观察命令 client list #列出所有连接 client kill #杀死某个连接 CLIENT KILL 127.0.0.1:6379 client getname #获取连接的名称 默认nil client setname #设置连接名称,便于调试
连接命令
auth 密码 #验证登录密码(如果设置了密码) ping #测试服务器是否可用 echo "hello www.biancheng.net" #测试服务器是否正常交互 select 0/1/2/3/4... #选择数据库0-15 quit #退出连接