Redis总结

发布于 / redis / 0 条评论

Redis 简介

Redis 是完全开源免费的,遵守BSD协议,是一个高性能的key-value数据库。

Redis 与其他 key – value 缓存产品有以下三个特点:

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

Redis 配置

Redis 的配置文件位于 Redis 安装目录下,文件名为 redis.conf

可以通过

CONFIG GET NAME   查看配置

也可以使用

CONFIG GET * 查看所有配置项

参数说明:

1daemonize noRedis 默认不是以守护进程的方式运行,可以通过该配置项修改,使用 yes 启用守护进程(Windows 不支持守护线程的配置为 no )
2pidfile /var/run/redis.pid当 Redis 以守护进程方式运行时,Redis 默认会把 pid 写入 /var/run/redis.pid 文件,可以通过 pidfile 指定
3port 6379指定 Redis 监听端口,默认端口为 6379,作者在自己的一篇博文中解释了为什么选用 6379 作为默认端口,因为 6379 在手机按键上 MERZ 对应的号码,而 MERZ 取自意大利歌女 Alessia Merz 的名字
4bind 127.0.0.1绑定的主机地址
5timeout 300当客户端闲置多长时间后关闭连接,如果指定为 0,表示关闭该功能
6loglevel notice指定日志记录级别,Redis 总共支持四个级别:debug、verbose、notice、warning,默认为 notice
7logfile stdout日志记录方式,默认为标准输出,如果配置 Redis 为守护进程方式运行,而这里又配置为日志记录方式为标准输出,则日志将会发送给 /dev/null
8databases 16设置数据库的数量,默认数据库为0,可以使用SELECT 命令在连接上指定数据库id
9save <seconds> <changes>Redis 默认配置文件中提供了三个条件:save 900 1save 300 10save 60 10000分别表示 900 秒(15 分钟)内有 1 个更改,300 秒(5 分钟)内有 10 个更改以及 60 秒内有 10000 个更改。指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合
10rdbcompression yes指定存储至本地数据库时是否压缩数据,默认为 yes,Redis 采用 LZF 压缩,如果为了节省 CPU 时间,可以关闭该选项,但会导致数据库文件变的巨大
11dbfilename dump.rdb指定本地数据库文件名,默认值为 dump.rdb
12dir ./指定本地数据库存放目录
13slaveof <masterip> <masterport>设置当本机为 slav 服务时,设置 master 服务的 IP 地址及端口,在 Redis 启动时,它会自动从 master 进行数据同步
14masterauth <master-password>当 master 服务设置了密码保护时,slav 服务连接 master 的密码
15requirepass foobared设置 Redis 连接密码,如果配置了连接密码,客户端在连接 Redis 时需要通过 AUTH <password> 命令提供密码,默认关闭
16 maxclients 128设置同一时间最大客户端连接数,默认无限制,Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis 会关闭新的连接并向客户端返回 max number of clients reached 错误信息
17maxmemory <bytes>指定 Redis 最大内存限制,Redis 在启动时会把数据加载到内存中,达到最大内存后,Redis 会先尝试清除已到期或即将到期的 Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis 新的 vm 机制,会把 Key 存放内存,Value 会存放在 swap 区
18appendonly no指定是否在每次更新操作后进行日志记录,Redis 在默认情况下是异步的把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 redis 本身同步数据文件是按上面 save 条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为 no
19appendfilename appendonly.aof指定更新日志文件名,默认为 appendonly.aof
20appendfsync everysec指定更新日志条件,共有 3 个可选值:no:表示等操作系统进行数据缓存同步到磁盘(快)always:表示每次更新操作后手动调用 fsync() 将数据写到磁盘(慢,安全)everysec:表示每秒同步一次(折中,默认值)
21vm-enabled no指定是否启用虚拟内存机制,默认值为 no,简单的介绍一下,VM 机制将数据分页存放,由 Redis 将访问量较少的页即冷数据 swap 到磁盘上,访问多的页面由磁盘自动换出到内存中(在后面的文章我会仔细分析 Redis 的 VM 机制)
22vm-swap-file /tmp/redis.swap虚拟内存文件路径,默认值为 /tmp/redis.swap,不可多个 Redis 实例共享
23vm-max-memory 0将所有大于 vm-max-memory 的数据存入虚拟内存,无论 vm-max-memory 设置多小,所有索引数据都是内存存储的(Redis 的索引数据 就是 keys),也就是说,当 vm-max-memory 设置为 0 的时候,其实是所有 value 都存在于磁盘。默认值为 0
24vm-page-size 32Redis swap 文件分成了很多的 page,一个对象可以保存在多个 page 上面,但一个 page 上不能被多个对象共享,vm-page-size 是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page 大小最好设置为 32 或者 64bytes;如果存储很大大对象,则可以使用更大的 page,如果不确定,就使用默认值
25vm-pages 134217728设置 swap 文件中的 page 数量,由于页表(一种表示页面空闲或使用的 bitmap)是在放在内存中的,,在磁盘上每 8 个 pages 将消耗 1byte 的内存。
26vm-max-threads 4设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4
27glueoutputbuf yes设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启
28hash-max-zipmap-entries 64 hash-max-zipmap-value 512指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法
29activerehashing yes指定是否激活重置哈希,默认为开启(后面在介绍 Redis 的哈希算法时具体介绍)
30include /path/to/local.conf指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件

Redis 远程连接

通过 redis-cli -h host -p port

Redis 发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

PUBLISH 频道 发送内容    # 发送命令
SUBSCRIBE 频道   # 接受命令

下表列出了 redis 发布订阅常用命令:

PSUBSCRIBE pattern [pattern ...] 订阅一个或多个符合给定模式的频道。

PUBSUB subcommand [argument [argument ...]] 查看订阅与发布系统状态。

PUBLISH channel message 将信息发送到指定的频道。

PUNSUBSCRIBE [pattern [pattern ...]] 退订所有给定模式的频道。

SUBSCRIBE channel [channel ...] 订阅给定的一个或多个频道的信息。

UNSUBSCRIBE [channel [channel ...]] 指退订给定的频道。

Redis 事务

Redis 事务可以一次执行多个命令, 并且带有以下三个重要的保证:

  • 批量操作在发送 EXEC 命令前被放入队列缓存。
  • 收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行。
  • 在事务执行过程,其他客户端提交的命令请求不会插入到事务执行命令序列中

相关命令:

1 DISCARD  # 取消事务,放弃执行事务块内的所有命令。
2 EXEC     # 执行所有事务块内的命令。
3 MULTI    # 标记一个事务块的开始。
4 UNWATCH  # 取消 WATCH 命令对所有 key 的监视。
5 WATCH key [key ...] # 监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。
linux操作
windows上操作

由上图我们可以看出,我在执行multi的命令以后,ld的值为1,然后我又在windows上对ld的值进行了改变,最后结果为3,可以使用watch指令去监视他,watch的命令要在multi命令之前,并且watch的作用我在上面已经描述过,另外事务中某一命令的失败,不会影响正确命令的执行,但是语法错误会导致事务的终止

Redis 数据备份与持久化

数据备份:

(1)save命令:这个命令是同步的命令,首先是client请求redis执行命令save,这个过程会阻塞后面的命令,当这个命令执行完之后,redis会创建一个RDB的二进制文件。如果有老的RDB文件,那么新的会替换掉老的文件。我们可以通过

CONFIG GET dir  # 得到dump.rdb的路径  当然我们也可以在conf里找到dirb并进行更改

之后将它复制到redis安装目录的bin目录下即可

2)bgsave命令:这个是异步的命令,client请求redis的时候,redis会创建一个fork的子进程,来备份数据,从而生成一个RDB文件,这个过程是在后台执行的,后面的命令就不会被阻塞掉

持久化

1.RDB

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

我们查看conf文件,找到如下内容

解说:save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。

触发RDB:

1 在指定的时间间隔内,执行指定次数的写操作
2 执行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (异步)命令
3 执行flushall 命令,清空数据库所有数据,意义不大。
4 执行shutdown 命令,保证服务器正常关闭且不丢失任何数据,意义…也不大。

通过RDB文件恢复数据:

将dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。

RDB 的优缺点

优点:
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高,RDB是很好的选择。

缺点:
1 数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

2.AOF

AOF以日志的形式记录Redis每一个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件不可以改写文件,redis启动之后会读取appendonly.aof文件来实现重新恢复数据,完成恢复数据的工作。

Redis服务器默认开启RDB,关闭AOF;要开启AOF,需要在配置文件中配置:

appendonly yes

通过配置文件我们可以看到这样几行

appendfsync always:每修改同步,每一次发生数据变更都会持久化到磁盘上,性能较差,但数据完整性较好。
appendfsync everysec: 每秒同步,每秒内记录操作,异步操作,如果一秒内宕机,有数据丢失。
appendfsync no:不同步

数据恢复
重启Redis时,如果dump.rdb与appendfsync.aof同时都存在时,Redis会自动读取appendfsync.aof文件,通过该文件中对数据库的日志操作,来实现数据的恢复。当然如果该文件被破坏,我们可以通过redis-check-aof工具来修复,如redis-check-aof –fix能修复破损的appendfsync.aof文件,当然如果dump.rdb文件有破损,我们也可以用redis-check-rdb工具来修复,如果appendfsync.aof文件破损了,是启动不客户端的,也就是无法完成数据的恢复。

重写
当然如果AOF 文件一直被追加,这就可能导致AOF文件过于庞大。因此,为了避免这种状况,Redis新增了重写机制,当AOF文件的大小超过所指定的阈值时,Redis会自动启用AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewiteaof。
重写原理:AOF文件持续增长过大时,会fork出一条新进程来将文件重写(也是临时文件最后再rename),遍历新进程的内存中的数据,每条记录都会有一条set语句,重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,有点类似于快照。
触发机制:Redis会记录上一次重写时的AOF大小,默认配置是当AOF文件大小是上一次的一倍并且大于64m时,会触发从写机制。

文件重写的触发
文件重写的触发,分为手动触发和自动触发:
手动触发:直接调用bgrewriteaof命令,该命令的执行与bgsave有些类似:都是fork子进程进行具体的工作,且都只有在fork时阻塞。
自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数,以及aof_current_size和aof_base_size状态确定触发时机。
auto-aof-rewrite-min-size:执行AOF重写时,文件的最小体积,默认值为64MB。
auto-aof-rewrite-percentage:执行AOF重写时,当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。

AOF的优点:
(1)AOF可以更好的保护数据不丢失,一般AOF会以每隔1秒,通过后台的一个线程去执行一次fsync操作,如果redis进程挂掉,最多丢失1秒的数据。
(2)AOF以appen-only的模式写入,所以没有任何磁盘寻址的开销,写入性能非常高。
(3)AOF日志文件的命令通过非常可读的方式进行记录,这个非常适合做灾难性的误删除紧急恢复,如果某人不小心用flushall命令清空了所有数据,只要这个时候还没有执行rewrite,那么就可以将日志文件中的flushall删除,进行恢复。
AOF的缺点
(1)对于同一份文件AOF文件比RDB数据快照要大。
(2)AOF开启后支持写的QPS会比RDB支持的写的QPS低,因为AOF一般会配置成每秒fsync操作,每秒的fsync操作还是很高的
(3)数据恢复比较慢,不适合做冷备。

RDB和AOF到底如何选择
(1)不要仅仅使用RDB这样会丢失很多数据。
(2)也不要仅仅使用AOF,因为这一会有两个问题,第一通过AOF做冷备没有RDB做冷备恢复的速度快;第二RDB每次简单粗暴生成数据快照,更加健壮。
(3)综合AOF和RDB两种持久化方式,用AOF来保证数据不丢失,作为恢复数据的第一选择;用RDB来做不同程度的冷备,在AOF文件都丢失或损坏不可用的时候,可以使用RDB进行快速的数据恢复。

Redis 安全

通过设置requirepass的值给定密码
然后再通过AUTH 密码
之后才能进行下一步的操作

Redis 客户端连接

Redis 通过监听一个 TCP 端口或者 Unix socket 的方式来接收来自客户端的连接,当一个连接建立后,Redis 内部会进行以下一些操作:

  • 首先,客户端 socket 会被设置为非阻塞模式,因为 Redis 在网络事件处理上采用的是非阻塞多路复用模型。
  • 然后为这个 socket 设置 TCP_NODELAY 属性,禁用 Nagle 算法
  • 然后创建一个可读的文件事件用于监听这个客户端 socket 的数据发送
config get maxclients    # 得到最大连接数
1) "maxclients"
2) "10000"

redis-server --maxclients 100000   # 我们也可以在启动时指定最大连接数

客户端命令:

CLIENT LIST 返回连接到 redis 服务的客户端列表
CLIENT SETNAME 设置当前连接的名称
CLIENT GETNAME 获取通过 CLIENT SETNAME 命令设置的服务名称
CLIENT PAUSE 挂起客户端连接,指定挂起的时间以毫秒计
CLIENT KILL 关闭客户端连接

Redis 分区

分区类型

Redis 有两种类型分区。 假设有4个Redis实例 R0,R1,R2,R3,和类似user:1,user:2这样的表示用户的多个key,对既定的key有多种不同方式来选择这个key存放在哪个实例中。也就是说,有不同的系统来映射某个key到某个Redis服务。

范围分区

最简单的分区方式是按范围分区,就是映射一定范围的对象到特定的Redis实例。

比如,ID从0到10000的用户会保存到实例R0,ID从10001到 20000的用户会保存到R1,以此类推。

这种方式是可行的,并且在实际中使用,不足就是要有一个区间范围到实例的映射表。这个表要被管理,同时还需要各 种对象的映射表,通常对Redis来说并非是好的方法。

哈希分区

另外一种分区方法是hash分区。这对任何key都适用,也无需是object_name:这种形式,像下面描述的一样简单:

  • 用一个hash函数将key转换为一个数字,比如使用crc32 hash函数。对key foobar执行crc32(foobar)会输出类似93024922的整数。
  • 对这个整数取模,将其转化为0-3之间的数字,就可以将这个整数映射到4个Redis实例中的一个了。93024922 % 4 = 2,就是说key foobar应该被存到R2实例中。注意:取模操作是取除的余数,通常在多种编程语言中用%操作符实现。

Redis 主从复制

我们来看一下简单的实现:

通过SLAVEOG IP PORT 指定自己的master,当成为slave以后,就只能已读

复制原理

1.Slave启动成功连接到master后会发送一个sync命令;
2.Master接到命令启动后的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步;
3. 全量复制:而slave服务在数据库文件数据后,将其存盘并加载到内存中;
4.增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步;
5.但是只要是重新连接master,一次完全同步(全量复制)将被自动执行。

哨兵模式(sentinel)
反客为主的自动版,能够后台监控Master库是否故障,如果故障了根据投票数自动将slave库转换为主库。一组sentinel能
同时监控多个Master。

使用步骤:
1、在Master对应redis.conf同目录下新建sentinel.conf文件,名字绝对不能错;
2、配置哨兵,在sentinel.conf文件中填入内容:sentinel monitor 被监控数据库名字(自己起名字) ip port 1
说明:上面最后一个数字1,表示主机挂掉后slave投票看让谁接替成为主机,得票数多少后成为主机。
3、启动哨兵模式:
命令键入:redis-sentinel  /redis/sentinel.conf
注:上述sentinel.conf路径按各自实际情况配置

主从复制的缺点:

延时,由于所有的写操作都是在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定 的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使得这个问题更加严重。

有关redis数据的操作我就不在这总结了,小伙伴可以自行百度!

转载原创文章请注明,转载自: ت » Redis总结
Not Comment Found