- 浏览: 2662054 次
- 来自: 杭州
文章分类
- 全部博客 (1188)
- webwork (4)
- 网摘 (18)
- java (103)
- hibernate (1)
- Linux (85)
- 职业发展 (1)
- activeMQ (2)
- netty (14)
- svn (1)
- webx3 (12)
- mysql (81)
- css (1)
- HTML (6)
- apache (3)
- 测试 (2)
- javascript (1)
- 储存 (1)
- jvm (5)
- code (13)
- 多线程 (12)
- Spring (18)
- webxs (2)
- python (119)
- duitang (0)
- mongo (3)
- nosql (4)
- tomcat (4)
- memcached (20)
- 算法 (28)
- django (28)
- shell (1)
- 工作总结 (5)
- solr (42)
- beansdb (6)
- nginx (3)
- 性能 (30)
- 数据推荐 (1)
- maven (8)
- tonado (1)
- uwsgi (5)
- hessian (4)
- ibatis (3)
- Security (2)
- HTPP (1)
- gevent (6)
- 读书笔记 (1)
- Maxent (2)
- mogo (0)
- thread (3)
- 架构 (5)
- NIO (5)
- 正则 (1)
- lucene (5)
- feed (4)
- redis (17)
- TCP (6)
- test (0)
- python,code (1)
- PIL (3)
- guava (2)
- jython (4)
- httpclient (2)
- cache (3)
- signal (1)
- dubbo (7)
- HTTP (4)
- json (3)
- java socket (1)
- io (2)
- socket (22)
- hash (2)
- Cassandra (1)
- 分布式文件系统 (5)
- Dynamo (2)
- gc (8)
- scp (1)
- rsync (1)
- mecached (0)
- mongoDB (29)
- Thrift (1)
- scribe (2)
- 服务化 (3)
- 问题 (83)
- mat (1)
- classloader (2)
- javaBean (1)
- 文档集合 (27)
- 消息队列 (3)
- nginx,文档集合 (1)
- dboss (12)
- libevent (1)
- 读书 (0)
- 数学 (3)
- 流程 (0)
- HBase (34)
- 自动化测试 (1)
- ubuntu (2)
- 并发 (1)
- sping (1)
- 图形 (1)
- freemarker (1)
- jdbc (3)
- dbcp (0)
- sharding (1)
- 性能测试 (1)
- 设计模式 (2)
- unicode (1)
- OceanBase (3)
- jmagick (1)
- gunicorn (1)
- url (1)
- form (1)
- 安全 (2)
- nlp (8)
- libmemcached (1)
- 规则引擎 (1)
- awk (2)
- 服务器 (1)
- snmpd (1)
- btrace (1)
- 代码 (1)
- cygwin (1)
- mahout (3)
- 电子书 (1)
- 机器学习 (5)
- 数据挖掘 (1)
- nltk (6)
- pool (1)
- log4j (2)
- 总结 (11)
- c++ (1)
- java源代码 (1)
- ocr (1)
- 基础算法 (3)
- SA (1)
- 笔记 (1)
- ml (4)
- zokeeper (0)
- jms (1)
- zookeeper (5)
- zkclient (1)
- hadoop (13)
- mq (2)
- git (9)
- 问题,io (1)
- storm (11)
- zk (1)
- 性能优化 (2)
- example (1)
- tmux (1)
- 环境 (2)
- kyro (1)
- 日志系统 (3)
- hdfs (2)
- python_socket (2)
- date (2)
- elasticsearch (1)
- jetty (1)
- 树 (1)
- 汽车 (1)
- mdrill (1)
- 车 (1)
- 日志 (1)
- web (1)
- 编译原理 (1)
- 信息检索 (1)
- 性能,linux (1)
- spam (1)
- 序列化 (1)
- fabric (2)
- guice (1)
- disruptor (1)
- executor (1)
- logback (2)
- 开源 (1)
- 设计 (1)
- 监控 (3)
- english (1)
- 问题记录 (1)
- Bitmap (1)
- 云计算 (1)
- 问题排查 (1)
- highchat (1)
- mac (3)
- docker (1)
- jdk (1)
- 表达式 (1)
- 网络 (1)
- 时间管理 (1)
- 时间序列 (1)
- OLAP (1)
- Big Table (0)
- sql (1)
- kafka (1)
- md5 (1)
- springboot (1)
- spring security (1)
- Spring Boot (3)
- mybatis (1)
- java8 (1)
- 分布式事务 (1)
- 限流 (1)
- Shadowsocks (0)
- 2018 (1)
- 服务治理 (1)
- 设计原则 (1)
- log (0)
- perftools (1)
最新评论
-
siphlina:
课程——基于Python数据分析与机器学习案例实战教程分享网盘 ...
Python机器学习库 -
san_yun:
leibnitz 写道hi,我想知道,无论在92还是94版本, ...
hbase的行锁与多版本并发控制(MVCC) -
leibnitz:
hi,我想知道,无论在92还是94版本,更新时(如Puts)都 ...
hbase的行锁与多版本并发控制(MVCC) -
107x:
不错,谢谢!
Latent Semantic Analysis(LSA/ LSI)算法简介 -
107x:
不错,谢谢!
Python机器学习库
redis数据持久化的策略主要有:
1. 内存快照
2. AOF
数据持久化通俗讲就是把数据保存到磁盘上,保证不会因为断电等因素丢失数据。
redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式,一种是 Snapshotting(快照)也是默认方式,另一种是Append-only file(缩写aof)的方式。先介绍下这两种dump方式再讲讲自己遇到的一些现象和想法,前面的内容是从网上整理出来的。
Snapshotting
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久 化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照,下面是默认的快照保存配置
save 900 1 #900秒内如果超过1个key被修改,则发起快照保存
save 300 10 #300秒内容如超过10个key被修改,则发起快照保存
save 60 10000
下面介绍详细的快照保存过程
- 1.redis调用fork,现在有了子进程和父进程。
- 2. 父进程继续处理client请求,子进程负责将内存内容写入到临时文件。由于os的写时复制机制(copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时os会为父进程要修改的页面创建副本,而不是写共享的页面。所以子进程的地址空间内的数 据是fork时刻整个数据库的一个快照。
- 3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。
client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的,由于redis是用一个主线程来处理所有 client的请求,这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不 是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。
另外由于快照方式是在一定间隔时间做一次的,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话,可以采用aof持久化方式。下面介绍
Append-only file
aof 比快照方式有更好的持久化性,是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改,所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下(默认是:每秒fsync一次)
appendonly yes //启用aof持久化方式
# appendfsync always //每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
appendfsync everysec //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐
# appendfsync no //完全依赖os,性能最好,持久化没保证
aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次,文件中必须保存全部的100条命令,其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中,最后替换原来的文件。具体过程如下
- redis调用fork ,现在有父子两个进程
- 子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令
- 父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
- 当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
- 现在父进程可以使用临时文件替换老的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。
需要注意到是重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
运维上的想法
其实快照和aof一样,都使用了Copy-on-write技术。多次试验发现每次做数据dump的时候,内存都会扩大一倍(关于这个问题可以参考我去年写的redis的内存陷阱,很多人用redis做为缓存,数据量小,dump耗时非常短暂,所以不太容易发现),这个时候会有三种情况:
一:物理内存足以满足,这个时候dump非常快,性能最好
二:物理内存+虚拟内存可以满足,这个时候dump速度会比较慢,磁盘swap繁忙,服务性能也会下降。所幸的是经过一段比较长的时候数据dump完成了,然后内存恢复正常。这个情况系统稳定性差。
三: 物理内存+虚拟内存不能满足,这个时候dump一直死着,时间久了机器挂掉。这个情况就是灾难!
如果数据要做持久化又想保证稳定性,建议留空一半的物理内存。如果觉得无法接受还是有办法,下面讲:
快照和aof虽然都使用Copy-on-write,但有个不同点,快照你无法预测redis什么时候做dump,aof可以通过bgrewriteaof命令控制dump的时机。
根据这点我可以在一个服务器上开启多个redis节点(利用多CPU),使用aof的持久化方式。
例如在24G内存的服务器上开启3个节点,每天用bgrewriteaof定期重新整理数据,每个节点dump的时间都不一样,这样理论上每个节点可以消耗6G内存,一共使用18G内存,另外6G内存在单个节点dump时用到,内存一下多利用了6G! 当然节点开的越多内存的利用率也越高。如果带宽不是问题,节点数建议 = CPU数。
我的应用里为了保证高性能,数据没有做dump,也没有用aof。因为不做dump发生的故障远远低于做dump的时候,即使数据丢失了,自动修复脚本可以马上数据恢复。毕竟对海量数据redis只能做数据分片,那么落到每个节点上的数据量也不会很多。
redis的虚拟内存建议也不要用,用redis本来就是为了达到变态的性能,虚拟内存、aof看起来都有些鸡肋。
现在还离不开redis,因为它的mget是现在所有db里性能最好的,以前也考虑过用tokyocabinet hash方式做mget,性能不给力。直接用redis,基本上单个redis节点mget可以达到10W/s
纠错
之前说过redis做数据dump的时候内容会扩大一倍,后来我又做了些测试,发现有些地方说的不对。
top命令并不是反映真实的内存占用情况,在top里尽管fork出来的子进程占了和父进程一样的内存,但是当做dump的时候没有写操作,实际使用的是同一份内存的数据。当有写操作的时候内存才会真实的扩大(具体是不是真实的扩大一倍不确定,可能数据是按照页分片的),这才是真正的Copy-on-write。
基于这点在做数据持久化会更加灵活。
发表评论
-
新浪微博 Redis 实战经验分享
2014-02-07 13:36 837Tape is Dead,Disk is Tape,Flas ... -
redis常用使用场景
2013-02-20 14:14 18171.将Redis用作消息队列 采用的当然是Redis的Li ... -
redis 文档集合
2012-12-22 15:52 777由于xmemcached不是很给力,最近想把memcach ... -
redis 重启主意事项
2012-12-18 13:07 21871. 先info 命令查看db0和db1的占用情况,然后确保c ... -
redis expires key不会自动删除的问题
2012-12-18 12:06 8881最近发现线上的session 服务器每隔一段时间内存占用就达到 ... -
redis 安装 配置解析
2012-12-18 11:51 1114一、 下载安装 Wget http://redis ... -
redis 挂掉
2012-09-18 17:12 1872线上报错: [25136] 18 Sep 16:24:38 ... -
Redis学习笔记II-Working with Multiple Databases
2012-09-09 20:35 735翻译自:http://rediscookbook.org/mu ... -
python reids client
2012-09-06 00:02 85391. 安装 1. redis-py git clone ... -
Redis学习手册(Sorted-Sets数据类型)
2012-09-07 16:36 1033一、概述: Sorted-S ... -
Redis学习手册(Set数据类型)
2012-09-07 16:36 765一、概述: ... -
redis 适用场景与实现
2012-09-05 16:23 1300redis 127.0.0.1:6379> za ... -
Redis学习手册(String数据类型)
2012-09-05 16:05 1120一、概述: ... -
Redis学习手册(List数据类型)
2012-09-05 16:02 911参考:http://www.cnblogs.com/ste ... -
Redis学习手册(Hashes数据类型)
2012-09-05 16:03 1035一、概述: 我们可以将Red ... -
Redis学习手册(内存优化)
2012-09-05 16:04 942一、特殊编码: 自从Redis 2.2之 ...
相关推荐
Redis是一种内存数据库,它支持数据的持久化,确保数据的持久性和安全性。持久化是指将内存中的数据保存到磁盘上,以便在Redis服务器重启或者系统崩溃之后,数据依然能够得以保存和恢复。Redis提供了两种持久化方案...
内容概要:本文详细介绍了Redis的持久化策略,特别是RDB(Redis Database Backup)和AOF(Append Only File)两种主要的持久化方法。RDB通过在某个时间点创建数据集的快照来实现数据持久化,其优点包括数据恢复快、...
Redis 是一个高性能的键值数据库,广泛应用于缓存、数据持久化等场景。在 Windows 上测试 Redis 的持久化功能,主要是确保数据在系统重启或异常情况后能够被正确地保存和恢复。以下将详细介绍如何在 Windows 环境下...
### Redis持久化方式详解 Redis 是一款高性能的键值存储系统,因其卓越的读写速度、丰富的数据结构以及灵活的应用场景而备受青睐。...在实际应用中,可以根据业务需求灵活配置,以达到最优的数据持久化效果。
Redis 是一款高性能的键值存储系统,广泛应用于缓存和数据持久化。持久化是Redis的一个重要特性,确保即使在服务器崩溃或系统断电后,数据也能得以恢复。本文将深入解析Redis的持久化机制,主要包括RDB快照和AOF日志...
用户可以根据应用场景的需求选择适合的持久化策略,或者结合使用以达到更好的平衡。 Redis还支持网络通信,意味着它可以作为一个分布式缓存系统在多台服务器之间同步数据,通过主从复制和Sentinel哨兵系统实现高...
### Redis 数据持久化 #### 一、Redis 数据持久化的重要性 Redis 作为一种内存数据库,在运行过程中将所有的数据存储于内存中。虽然这种设计能够极大提高数据的读写速度,但同时也带来了一个问题:一旦服务器断电...
RDB 是 Redis 默认的持久化方式,它会在指定的时间点创建数据集的快照。通过执行 `SAVE` 或者 `BGSAVE` 命令来触发。`BGSAVE` 会在后台异步执行,不会阻塞主进程。 - **优点**: - 数据恢复速度快,重启后可以直接...
Redis是一款高性能的键值对数据库,它以其出色的性能和丰富的数据结构被广泛应用于缓存、消息中间件以及数据持久化等多个场景。而Jedis是Java社区中常用的Redis客户端库,它提供了与Redis服务器进行交互的基本功能。...
②根据业务需求选择合适的持久化策略,确保数据不丢失;③了解如何配置和优化持久化性能。 其他说明:文章详细介绍了RDB和AOF两种持久化方式的具体流程和优劣势,有助于读者在实际工作中灵活应用。
Redis是一款高性能的键值对内存数据库,常用于缓存、消息队列以及数据持久化等场景。本资料包主要探讨Redis的三个核心概念:持久化、主从复制和哨兵架构,这些都是确保Redis高可用性和数据安全的重要机制。 首先,...
在实际应用中,根据不同的业务场景和需求,可以选择合适的持久化策略。 在选择持久化方式时,需要根据业务的数据安全要求、数据一致性要求、性能要求以及磁盘资源等多方面因素综合考虑。对于业务数据不允许任何丢失...
根据不同的业务需求,可以选择适合的持久化策略。如果对数据的一致性要求较高,愿意牺牲一些性能,AOF 是更合适的选择;如果优先考虑性能,可以采用 RDB,尤其在大数据集场景下。有时,为了兼顾性能和数据安全性,也...
RDB是Redis默认的持久化策略。它会在特定的时间间隔内,如果满足特定的写操作次数,将内存中的数据快照写入到磁盘上的一个文件,通常命名为`dump.rdb`。这种快照式的备份提供了快速的数据恢复能力,特别适合于大规模...
本篇将深入探讨 Redis 的持久化策略,帮助你应对相关的面试问题。 1. RDB (Redis Database Persistence) RDB 是 Redis 默认的持久化方式,它会定期创建数据库的一个快照(snapshot)。当满足特定条件(如指定时间...
Redis持久化机制包括RDB快照和AOF(Append Only File)两种方式,它们有不同的特点和使用场景,下面将详细分析这两种机制。...用户应当根据具体的业务需求和对数据安全性的要求来选择最合适的持久化策略。
然而,内存中的数据在服务器断电或宕机后会丢失,因此,为了保证数据的持久性,Redis 提供了两种持久化策略:RDB(Redis Database Backup)模式和AOF(Append Only File)模式。 **RDB 模式** RDB 是一种快照式的...
Redis 是一个高性能的键值数据库,它提供了多种持久化策略以确保数据的可靠性。本文主要讨论Redis的两种持久化方式:RDB(Redis Database)和AOF(Append-only File)。 **RDB 持久化** RDB 是通过创建数据库在...
在实际应用中,用户可以根据业务需求和性能要求,选择单一或结合使用RDB和AOF来实现Redis的数据持久化。例如,可以使用RDB作为定期备份,AOF作为实时数据保护,以达到最佳的数据安全性与性能平衡。 总之,Redis的...