数据持久化

一、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 的缓存功能，不需要持久化。可以注释掉所有的

1为什么要对redis进行持久化 redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。 2redis持久化机制 方法 ：在控制台启用redis服务器，路径为redis服务器所在文件夹（通过shift+右键---运行） 在命令行窗口输入 redis服务器所在当前窗口命令行调用redis-server.exe redis.windoes.conf 出现 ： 但此处还为表示redis服务器已经实现持久化 因为其实现持久化的条件由redis.windoes.conf中配置决定 redis持久化实现 打开redis.windoes.conf文件，查看持久层配置信息 “save 10 1”表示的是redis客户端数据10s内如果更新1次，则数据信息会自动保存到磁盘 实现持久层，当实现持久，客户端信息反馈如下; 表示持久化完成 之后双击打开redis服务器 并在cli客户端可以查询到保存在磁盘的信息，并且双击打开服务器端会出现以.dat结尾的文件： 来源： CSDN 作者： YO131 链接： https://blog.csdn.net/qq_33551891/article/details/89261876

1. 使用Redis有哪些好处？ (1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1) (2) 支持丰富数据类型，支持string，list，set，sorted set，hash (3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 (4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除 2. redis相比memcached有哪些优势？ (1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型 (2) redis的速度比memcached快很多 (3) redis可以持久化其数据 3. redis常见性能问题和解决方案： (1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件 (2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3… 这样的结构方便解决单点故障问题，实现Slave对Master的替换

本文来自Redis的作者，他在论坛看到大家对Redis持久化误解较大，所以写此文章论述持久化 写操作的流程 首先我们来看一下数据库在进行写操作时到底做了哪些事，主要有下面五个过程。 客户端向服务端发送写操作（数据在客户端的内存中） 数据库服务端接收到写请求的数据（数据在服务端的内存中） 服务端调用write(2) 这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中） 操作系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中） 磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上） 写操作大致有上面5个流程，下面我们结合上面的5个流程看一下各种级别的故障。 当数据库系统故障时，这时候系统内核还是OK的，那么此时只要我们执行完了第3步，那么数据就是安全的，因为后续操作系统会来完成后面几步，保证数据最终会落到磁盘上。 当系统断电，这时候上面5项中提到的所有缓存都会失效，并且数据库和操作系统都会停止工作。所以只有当数据在完成第5步后，机器断电才能保证数据不丢失，在上述四步中的数据都会丢失。 通过上面5步的了解，可能我们会希望搞清下面一些问题： 数据库多长时间调用一次write(2)，将数据写到内核缓冲区 内核多长时间会将系统缓冲区中的数据写到磁盘控制器 磁盘控制器又在什么时候把缓存中的数据写到物理介质上 对于第一个问题，通常数据库层面会进行全面控制。而对第二个问题

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

转： https://www.cnblogs.com/bigberg/p/8195622.html 队列持久化需要在声明队列时添加参数 durable=True，这样在rabbitmq崩溃时也能保存队列 仅仅使用durable=True ，只能持久化队列，不能持久化消息 消息持久化需要在消息生成时，添加参数 properties=pika.BasicProperties(delivery_mode=2) RabbitMQ消息持久化 转： https://www.cnblogs.com/liehen2046/p/11052666.html 索引失效的7种 ： 1.有or必全有索引; 2.复合索引未用左列字段; 3.like以%开头; 4.需要类型转换; 5.where中索引列有运算; 6.where中索引列使用了函数; 7.如果mysql觉得全表扫描更快时（数据少）; JVM调优： https://www.cnblogs.com/jay36/p/7680008.html 来源： https://www.cnblogs.com/fengli9998/p/11455964.html

## # Redis持久化介绍 所有的数据都存在内存中，从内存当中同步到硬盘上，这个过程叫做持久化过程。持久化操作，两种方式：rdb方式、aof方式，可以单独使用或者结合使用。 rdb持久化方法：在指定的时间间隔写入硬盘 aof方式：将以日志，记录每一个操作，服务器启动后就构建数据库。 RDB方式 Redis是默认支持的 优势：只有一个文件，时间间隔的数据，可以归档为一个文件，方便压缩转移（就一个文件） ## # Redis的持久化之RDB方式 劣势：如果宕机，数据损失比较大，因为它是每一个时间段进行持久化操作的。也就是积攒的数据比较多，一旦懵逼，就彻底懵逼了 [root@hdp-01 redis]# vi redis.conf 往下拉： 这里save 900 1 表示 每900秒内至少有1个kery发生变化 就持久化 save 300 10表示 每300秒内至少有10个key发生变化 就持久化 save 60 10000表示 每60秒内至少有10000个key发生变化 就持久化 再往下拉 这里有个dbfilename配置 是保存的持久化的文件名 默认是dump.rdb dir ./ 表示文件存储路径是当前路径 退出 [root@hdp-01 redis]# ll 总用量 64 drwxr-xr-x. 2 root root 134 9月 1 16:30 bin -rw-r--r-

Redis数据库持久化 一、数据库概述； 二、持久化的作用以及实现方式； 三、RDB持久化方式配置； 四、AOF持久化方式配置； 一、数据库概述： Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。 二、持久化的作用以及实现方式： 作用： Redis的所有数据都是保存在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。那么不定期的通过异步方式保存到磁盘上（半持久化模式）；也可以把每一次数据变化都写入到一个append only file里面（全持久化模式）。 如若在服务器中开启了两种持久化的方式，默认执行AOF持久化方式； 实现方式： RDB持久化：将Reids在内存中的数据库记录定时dump到磁盘上，类似于快照功能。 AOF持久化：append only file--原理是将Reids的操作日志以追加的方式写入文件，近似实时性。 二者的区别： RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程

Redis提供的持久化机制 　 　　Redis是一种面向“key-value”类型数据的分布式NoSQL数据库系统，具有高性能、持久存储、适应高并发应用场景等优势。它虽然起步较晚，但发展却十分迅速。 近日，Redis的作者在博客中写到， 他看到的所有针对Redis的讨论中，对Redis持久化的误解是最大的 ，于是他写了一篇长文来对Redis的持久化进行了系统性的论述。 文章主要包含三个方面： Redis持久化是如何工作的、这一性能是否可靠以及和其它类型的数据库比较 。以下为文章内容： 一、Redis持久化是如何工作的？ 　　什么是持久化？简单来讲就是将数据放到断电后数据不会丢失的设备中，也就是我们通常理解的硬盘上。 首先我们来看一下数据库在进行写操作时到底做了哪些事，主要有下面五个过程 ： 客户端向服务端发送写操作（数据在客户端的内存中）。 数据库服务端接收到写请求的数据（数据在服务端的内存中）。 服务端调用write这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）。 操作系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中）。 磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上）。 故障分析 写操作大致有上面5个流程， 下面我们结合上面的5个流程看一下各种级别的故障 ： 当数据库系统故障时，这时候系统内核还是完好的。那么此时只要我们执行完了第3步

一、是什么 　　 以日志的形式记录每个写操作， 将redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。 二、配置文件 　　 默认的生成的文件是appendonly.aof文件进行数据备份，默认是关的。appendonly no。只需要把no改成yes就行了。 　　追加策略分为三种：appendfsync：always、everysec和no。 　　always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但是数据完整性比较好 　　everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失。 　　now-appendfsync-on-rewrite：重写时是否可以运用appendfsync，默认no就像，保证数据安全性。 　　auto-aof-rewrite-min-size：设置重写基准值(出厂默认是64M)。 　　auto-aof-rewrite-percentage：设置重写的基准值（出长默认是100%）。 三、AOF启动/修复/恢复 　　正常恢复：将appendonly no改为 appendonly yes，重启redis就会加载appendonly.aof