存储快照

Redis的配置主要放置在redis.conf，可以通过修改配置文件实现Redis许多特性，比如复制，持久化，集群等。 redis.conf部分配置详解 # 启动redis，显示加载配置redis.conf # ./redis-server /path/to/redis.conf # 停止redis # redis-cli -h IP -p PORT shutdown # 可以包含一个或多个其他配置文件，如果多个redis服务器存在标准配置模板，但是每隔redis服务器可能有个性化的配置 # include /path/to/local.conf # include /path/to/other.conf # 这个地方网上存在许多误解，bind的是网络接口。对于一个redis服务器来说可以有一个或者多个网卡。比如服务器上有两个网卡：bind 192.168.1.100 192.168.1.101，如果bind bind 192.168.1.100，则只有该网卡地址接受外部请求，如果不绑定，则两个网卡都接受请求 # bind 192.168.1.100 192.168.1.101 # bind 127.0.0.1 ::1 # 监听端口号，默认为6379，如果为0监听任连接 port 6379 # TCP连接中已完成队列的长度 tcp-backlog 511

关键要点 仅从ACID或非ACID角度考虑问题是不够的，你应知道你的数据库支持何种事务隔离级别。 一些数据库宣称自己具有“最终一致性”，但却可能对重复查询返回不一致的结果。 相比于你所寻求的数据库，一些数据库提供更高的事务隔离级别。 脏读可导致同一记录得到两个版本，或是完全地丢失一条记录。 在同一事务中多次重新运行同一查询后，可能会出现幻读。 最近MongoDB登上了Reddit的头条，因为MongoDB的核心开发者David Glasser痛苦地认识到MongoDB默认会执行脏读( https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827 )。 在本文中，我们将解释什么是事务隔离级别和脏读，并给出一些广受欢迎的数据库是如何实现它们的。ANSI SQL给出了四种标准的事务隔离级别：可序列化(Serializable)（应该翻译为串行化的事务）、可重复读(Repeatable reads)、提交读(Read committed)和未提交读(Read uncommitted)。 许多数据库缺省是提交读的，这保证了在事务运行期间用户看不到转变中的数据。提交读的实现通过在读取时暂时性地获取锁，并持有写入锁直至事务提交

一、redis持久化的意义 redis持久化的意义，在于故障恢复 比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据 如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据 如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的 二、为什么要持久化 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了 很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会去mysql数据库这种数据源头中去找，一下子mysql承接高并发，然后就挂了 mysql挂掉，你都没法去找数据恢复到redis里面去，redis的数据从哪儿来？从mysql来。。。 如果你把redis的持久化做好，备份和恢复方案做到企业级的程度

Redis持久化机制 众所周知，Redis是一个内存数据库。但它与其它内存数据库（如memcache）等有一个很大的区别，就是Redis可以持久化到磁盘。有了持久化方案，Redis就可以对数据进行备份、恢复、复制。 Redis提供了两种持久化方案：RDB和AOF。在Redis 4.0中，提供了一个新特性：两者的混合持久化。下面将介绍Redis的各种持久化方案的原理和配置。 使用 info persistence 命令可以查看当前所有有关持久化的信息： RDB 原理 RDB持久化是通过快照方式来完成的。当达到触发条件时，Redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。 在配置文件可以配置当前配置的备份文件和目录，使用 config 命令也可以查看和设置： 触发条件 RDB分为主动触发和被动触发。 主动触发指的是客户端执行 save 和 bgsave 命令会进行持久化。 执行save会使Redis处于阻塞状态，不会响应任何其他客户端发来的请求，直到RDB快照文件执行完毕，需要谨慎使用。 bgsave即background save，后台保存。当执行bgsave命令时，Redis会 fork 出一个子进程来执行快照操作。需要注意的是，在fork子进程的过程中，Redis是阻塞的。而当子进程创建完成后，Redis就可以继续响应客户端的请求了。 子进程创建完成以后

LVM对LV提供的快照功能，只对LVM有效，但是个人认为，能用到LVM的地方大多是企业，而企业要是对数据真的很在意，推荐还是买一款具快照功能的存储设备，价格也不是很贵，主要是创建和恢复快照比较方便图形化下就可以操作，专业的设备做专业的事。 LVM快照原理 当一个snapshot创建的时候，仅拷贝原始卷里数据的元数据(meta-data)。创建的时候，并不会有数据的物理拷贝，因此snapshot的创建几乎是实时的，当原始卷上有写操作执行时，snapshot跟踪原始卷块的改变，这个时候原始卷上将要改变的数据在改变之前被拷贝到snapshot预留的空间里，因此这个原理的实现叫做写时复制(copy-on-write)。如果源卷的变化达到1GB这么大，快照卷就会消耗掉1G的容量来存放改变的数据。 创建snapshot的大小并不需要和原始卷一样大，其大小仅仅只需要考虑两个方面：从shapshot创建到释放这段时间内，估计块的改变量有多大;数据更新的频率。一旦 snapshot的空间记录满了原始卷改变的数据，那么这个snapshot立刻被释放，从而无法使用，从而导致这个snapshot无效，避免这种事情的发生，第一种解决办法是刚创建完快照之后，立即把快照区中的内容进行备份，这样就不用时刻考虑快照区会失效了，因为我们已经把他的数据备份走了。第二种解决办法是，如果快照卷的存储空间就要殆尽

Redis所有数据都是保存在内存中，Redis数据备份可以定期的通过异步方式保存到磁盘上，该方式称为半持久化模式，如果每一次数据变化都写入aof文件里面，则称为全持久化模式。同时还可以基于Redis主从复制实现Redis备份与恢复。 1. 半持久化RDB模式 半持久化RDB模式也是Redis备份默认方式，是通过快照（snapshotting）完成的，当符合在Redis.conf配置文件中设置的条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上，完成数据备份。 Redis进行RDB快照的条件由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。在配置文件中已经预置了3个条件： save 900 1 #900秒内有至少1个键被更改则进行快照； save 300 10 #300秒内有至少10个键被更改则进行快照； save 60 10000 #60秒内有至少10000个键被更改则进行快照。 默认可以存在多个条件，条件之间是“或”的关系，只要满足其中一个条件，就会进行快照。 如果想要禁用自动快照，只需要将所有的save参数删除即可。Redis默认会将快照文件存储在Redis数据目录，默认文件名为：dump.rdb文件，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名

Dotmemory 内存分析工具 教程一、开始学习dotmemory 在本教程中,我们将学习如何运行dotMemory内存快照。此外,我们将简要地看看dotMemory的用户界面和基本分析的概念。考虑dotMemory本教程作为起点 基本条款： 你可能会问:“什么是内存快照和为什么我要学他们?”这是一个很好的时间来达成一些内存分析 您将在本教程中遇到。 从内存的角度来看,应用程序由连续的工作为新对象分配内存和释放内存的对象不再使用的应用程序。对象分配一个接一个地在所谓的托管堆(关于内存管理.net,遵循这个链接)。在此基础上,我们有两个基本操作内存分析器必须能够做: 1、 得到一个内存快照。快照是一个即时托管堆的形象。每个快照包含信息的所有对象,应用程序在内存中分配此刻你点击获取快照按钮。 2、 收集交通信息记忆。交通向您展示多少内存分配内存和释放字节/秒。这个信息也是非常有价值的,因为它允许您了解应用程序的动态执行。 你收集的时间在交通和快照(或者,换句话说,概要文件应用程序)被称为分析会话。 当然,还有其他一些条款,你会熟悉而教程。但是现在这足以理解发生了什么在接下来的几个步骤。让我们开始吧! 内容： 简单应用程序 1、 打开dotmemory 2、 得到一个快照 3、 熟悉快照的概述 4、 内存分析入门 5、 熟悉用户界面 首先,我们需要一个应用程序概要分析

一、概念 一）redis提供了不同级别的持久化方式： RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。 AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。 如果你只希望你的数据在服务器运行的时候存在，你也可以不适用任何持久化方式。 也可以同时开启两种持久化方式，在这种情况下，当redis重启的时候会有限载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集比RDB文件保存的数据集要完整 二）RDB的优缺点 优点： RDB是一个非常紧凑的文件，它保存了某个时间点的数据集，非常适用于数据集的备份，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。 RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复。 RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。 缺点： 如果希望在redis意外停止工作的情况下丢失的数据最少的话，那么RDB不适合

一、Redis 持久化方式（RDB） 【1】 RDB （ Redis DataBase ）： 在指定的时间间隔内将内存中的数据集以快照的形式写入磁盘，也就是行话讲的 Snapshot (快照)，它恢复时是将快照文件直接读到内存里。Redis 会单独创建（Fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失，RDB 保存的是 dump.rdb 文件。快照也是默认实现 Reids 持久化数据的方式。 Fork ： 作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但新进程是一个全新的进程，并作为原进程的子进程。 【2】 触发 RDB 快照 ：支持 手动触发 和 自动触发 两种模式。 ①、 自动触发 ：在 redis.conf 配置文件中的 SNAPSHOTTING 下，通过配置 save 触发 Redis 的持久化条件。当达到如下条件时，会自动触发 bgsave 命令。当然如果只是用 Redis 的缓存功能，不需要持久化。可以注释掉所有的

7、redis的持久化 由于redis是一个内存数据库，所有的数据都是保存在内存当中的，内存当中的数据极易丢失，所以redis的数据持久化就显得尤为重要，在redis当中，提供了两种数据持久化的方式，分别为RDB以及AOF，且redis默认开启的数据持久化方式为RDB方式，接下来我们就分别来看下两种方式的配置吧 1、RDB持久化方案介绍 RDB方案介绍 Redis会定期保存数据快照至一个rbd文件中，并在启动时自动加载rdb文件，恢复之前保存的数据。可以在配置文件中配置Redis进行快照保存的时机： save [seconds] [changes] 意为在[seconds]秒内如果发生了[changes]次数据修改，则进行一次RDB快照保存，例如 save 60 100 会让Redis每60秒检查一次数据变更情况，如果发生了100次或以上的数据变更，则进行RDB快照保存。可以配置多条save指令，让Redis执行多级的快照保存策略。Redis默认开启RDB快照。也可以通过SAVE或者BGSAVE命令手动触发RDB快照保存。 SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同： SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。 BGSAVE 则 fork