Redis 学习之持久化机制、发布订阅、虚拟内存

该问使用centos6.5 64位  redis3.2.8

一、持久化机制

Redis是一个支持持久化的内存数据库,redis会经常将内存中的数据同步到硬盘上来保证数据持久化,从而避免服务器宕机数据丢失问题,或者减少服务器内存消耗提高性能。

持久化方式:

1、Snapshotting:快照,redis默认持久化方式,这种方式是将内存中的数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照。

Save 900 1 #900秒内如果有超过1个key被修改,则发起快照保存。

Save 300 10 #300秒内如果有超过10个key被修改,则发起快照保存。

Save 60 1000 #60秒内如果有超过1000个 key被修改,则发起快照保存。

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

注意:该方式每次做快照都有一个时间间隔,如果服务器在间隔内宕机,那在间隔内修改的数据将不能持久化到磁盘中。建议使用 aof方式。

2、Append-only file :aof方式

Aof方式原理:redis会将每一个收到的写命令都通过write函数追加到文件中(aof文件),当redis重启时会通过重新执行该文件保存的写命令来在内存中重建整个数据库的内容。由于操作系统 OS 会在内核中缓存write做的修改,所以可能不会立即写到磁盘中。这样aof方式的持久化也还是可能丢失数据。但我们可以通过配置文件告诉redis我们想通过fsync函数强制os写入到磁盘中。

配置aof:

Appendonly yes #启用aof持久化方式

Appendfsync always #收到写入命令就立即写入磁盘,效率最慢,但会保证完全的数据次持久化

Appendfsync everysec #每秒中写入磁盘一次,在性能和持久化之间做了很好的折中。

Appendfsync no # 完全以来OS,性能最好,但在持久化方面没保证。

实例:

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don‘t fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that‘s usually the right compromise between
# speed and data safety. It‘s up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that‘s snapshotting),
# or on the contrary, use "always" that‘s very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

测试aof是否成功:

重启redis:

[[email protected] etc]# pkill redis-server

[[email protected] etc]# cd ../bin

[[email protected] bin]#  ./redis-server /usr/local/redis/etc/redis.conf

链接客户端:

[[email protected] bin]# ./redis-cli -a jalja

127.0.0.1:6379> set addr bj

OK

查看 bin下是否存在aof文件

[[email protected] bin]# ll

总用量 26356

-rw-r--r--. 1 root root      54 2月  18 22:56 appendonly.aof

-rw-r--r--. 1 root root      97 2月  18 22:55 dump.rdb

-rw-r--r--. 1 root root     566 2月  17 22:51 mkreleasehdr.sh

-rw-r--r--. 1 root root 5578343 2月  17 22:52 redis-benchmark

-rw-r--r--. 1 root root   22217 2月  17 22:51 redis-check-aof

-rw-r--r--. 1 root root 7827978 2月  17 22:52 redis-check-rdb

-rwxr-xr-x. 1 root root 5707211 2月  17 22:52 redis-cli

-rwxr-xr-x. 1 root root 7827978 2月  17 22:52 redis-server

在这里出现了appendonly.aof文件打开该文件

[[email protected] bin]# cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
addr
$2
bj

二、发布及订阅消息

发布订阅(pub/sub)是一种消息通信模式,主要的目的是解耦消息发布者和消息订阅者之间的耦合,这点和设计模式中的观察者模式比较相似。pub /sub不仅仅解决发布者和订阅者直接代码级别耦合也解决两者在物理部署上的耦合。redis作为一个pub/sub server,在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型,redis将消息类型称为通道(channel)。当发布者通过publish命令向redis server发送特定类型的消息时。订阅该消息类型的全部client都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个 channel,也可以向多个channel发送消息。

1、开启两个订阅session

session1:

127.0.0.1:6379> subscribe tv1   订阅频道tv1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1

session2:

127.0.0.1:6379> subscribe tv1 tv2   订阅频道tv1和tv2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1
1) "subscribe"
2) "tv2"
3) (integer) 2

2、开启发布session      在这里我们发布两个频道的信息

127.0.0.1:6379> publish tv1 "Hello word"  #给频道tv1发布信息
(integer) 2     # tv1的订阅者2位
127.0.0.1:6379> publish tv2 "Hello tv2"   #给频道tv2发布信息
(integer) 1    # tv2的订阅者1位
127.0.0.1:6379> 

3、再次查看两个订阅频道

session1:

127.0.0.1:6379> subscribe tv1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1
1) "message"     #获取了tv1发布的信息
2) "tv1"
3) "Hello word"

session2:

127.0.0.1:6379> subscribe tv1 tv2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tv1"
3) (integer) 1
1) "subscribe"
2) "tv2"
3) (integer) 2
1) "message"   #获取了tv1发布的信息
2) "tv1"
3) "Hello word"
1) "message"  #获取了tv2发布的信息
2) "tv2"
3) "Hello tv2"

三、虚拟内存的使用

  Redis的虚拟内存与操作系统中的虚拟内存不是一回事,但思路相同。就是将不经常访问的数据从内存交换到磁盘中,从而腾出宝贵的内存空间用户其他需要访问的数据,这对于redis这样的内存数据库来说很重要,除了可以将数据分割到多个redis server外。另外能够提高数据库容量的方式就是使用虚拟内存把哪些不经常访问的数据交换到磁盘上。

配置方式( redis.conf):

Vm-enable yse #开启虚拟内存

Vm-swap-file /tmp/redis.swap #交换出来的value保存文件路径

Vm-max-memory 1000000 #redis使用最大内存的上限

Vm-page-size 32 #每个页面的大小32字节

Vm-pages 134217728 #最多使用多少个页面

Vm-max-threads 4#用于执行value对象换入缓存的工作线程数量

时间: 2024-10-17 03:12:23

Redis 学习之持久化机制、发布订阅、虚拟内存的相关文章

Redis事务、持久化、发布订阅

一.Redis事物 1. 概念 Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证: 事务是一个单独的隔离操作:事务中的所有命令都会序列化.按顺序地执行.事务在执行的过程中,不会被其他客户端发送来的命令请求所打断. 事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行. 一个事务从开始到执行会经历以下三个阶段: 开始事务. 命令入队. 执行事务. 2. 实例     3. Redis 事务命令 下表列出了 redis 事务的相关命令: 序号 命令及描述 1 DISCA

redis学习教程三《发送订阅、事务、连接》

redis学习教程三<发送订阅.事务.连接> 一:发送订阅      Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息.Redis 发布订阅(pub/sub)实现了消息系统,发送者(在redis术语中称为发布者)在接收者(订阅者)接收消息时发送消息.传送消息的链路称为信道. 示例 以下示例说明了发布用户概念的工作原理. 在以下示例中,一个客户端订阅名为"redisChat"的信道. redis 127.0.0.1:6

Redis提供的持久化机制(RDB和AOF)

Redis提供的持久化机制 Redis是一种高性能的数据库,可以选择持久化,也可以选择不持久化. 如果要保存,就会存在数据同步的问题,可以简单认为一份数据放在内存中(快照),一份数据放在磁盘上,Redis提供了很灵活的持久化办法: Redis提供了RDB持久化和AOF持久化,本篇文章中将会对这两种机制进行一些对比 RDB机制的优势和略施 RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘. 也是默认的持久化方式,这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为

Redis学习手册(持久化)

一.Redis提供了哪些持久化机制: 1). RDB持久化:    该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘.        2). AOF持久化:    该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的.    3). 无持久化:    我们可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的memcached了.    4). 同时应用A

redis学习--的持久化数据备份(RDB和AOF)

接上一篇:安装window下的redis,redis可视化管理工具(Redis Desktop Manager)安装,基础使用,实例化项目 一.dump.rdb文件是怎么生成的 二.什么是redis持久化 三.redis的RDB是什么? 四.redis配置文件redis.config相关配置 五.redis优点 六.redis缺点 redis比memcache作为缓存数据库强大的地方:(1)支持数据类型比较多,(2)redis持久化功能. 一.dump.rdb文件是怎么生成的 在redis服务挂

学习javascript设计模式之发布-订阅(观察者)模式

1.发布-订阅模式又叫观察者模式,它定义对象之间一种一对多的依赖关系. 2.如何实现发布-订阅模式 2-1.首先指定好发布者 2-2.给发布者添加一个缓冲列表,用户存放回调函数以便通知订阅者 2-3.最后发布消息时候,发布者会遍历这个缓存列表,依次触发里面存放的订阅者回调函数 例子: var salesOffice = {};salesOffice.clientList = [];salesOffice.listen = function(key,fn){    if(!this.clientL

我的RabbitMQ学习之旅3 (发布/订阅)

在前面的教程中,我们创建了一个工作队列.工作队列背后的假设是,每个任务只被传递给一个工作人员.在这一部分,我们将做一些完全不同的事情 - 我们会向多个消费者传递信息.这种模式被称为“发布/订阅”. 本质上,发布的日志消息将被广播给所有的接收者 生产者 是发送消息的用户的应用程序. 队列 是存储消息的缓冲器. 消费者 是接收消息的用户的应用程序. RabbitMQ中消息传递模型的核心思想是生产者永远不会将任何消息直接发送到队列中.实际上,生产者通常甚至不知道一个消息是否会被传送到任何队列中. 相反

redis学习之——持久化RDB 和AOF

RDB: 在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里.rdb 保存的是dump.rdb文件 RDB工作原理: Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件.整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方,式要比AOF方式更加

redis学习——数据持久化

一.概述 Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的.所以,我们需要将内存中的数据持久化!典型的需要持久化数据的场景如下: 将Redis作为数据库使用: 将Redis作为缓存服务器使用,但是缓存miss后会对性能造成很大影响,所有缓存同时失效时会造成服务雪崩,无法响应. 本文介绍Redis所支持的两种数据持久化方式. 二.Redis数据持久化 Redis支持两种数据持久化方式:RDB