rdb

Python实战社群 Java实战社群 长按识别下方二维码， 按需求添加 扫码关注添加客服 进Python社群▲ 扫码关注添加客服 进Java社群 ▲ 作者丨莱乌 来源丨IT界农民工（ID：kejishuqian） 作为内存数据库，Redis 在数据存储与读取上的速度是毫不逊色的，这点毋庸置疑。但是对于内存来说，断电或遇到故障后数据就会丢失，这却是一个无法回避的问题。令人欣慰的是，基于这样的缺点，Redis 也提供了不同的持久化方案。 各位看官请随小莱接着往下看： - 思维导图 - RDB持久化 对于 Redis 持久化来说，其实就是将存储在内存中的数据写入到磁盘里，只不过写入的方式是有一定策略的。 那么我们先来看下第一种持久化，首先出场的是 RDB。 1、什么是RDB持久化 英文名称是 Redis DataBase，它还有一个常用的名字： 快照持久化 。所谓快照，在这里指的是某一时刻的内存数据，而持久化则是将这一时刻的数据以二进制形式写入到磁盘里。 2、手动触发机制 （1）save 命令 你可能会问了，那我通过什么样的方式来实现持久化呢？不知道你有没有用过 save 这个命令，在 Redis 里担任的角色是用来手动触发持久化的。也就是说在 Redis 客户端操作 save 命令就可以将内存数据写入到磁盘里。 不过你可千万不要好奇，生产环境要是这么玩儿的话，数据量少还行

一、Redis介绍 C语言开发的高性能k-v缓存中间件，支持string、set、sorted set、list、hash数据结构。 二、Redis优势 大部分操作都是纯内存操作，速度非常快 数据结构简单，操作方便 单线程，避免了频繁的上下文切换和竞争 多路IO复用模型，非阻塞IO 三、应用场景 计数器、常用缓存、回话缓存、消息队列(lpush、rpop)、分布式锁 四、Redis持久化 两种模式都开启的情况下，重启会优先选择AOF恢复。 RDB(默认)：按照一定时间，将内存数据以快照形式保存到硬盘中 优点：只有一个文件，方便持久化；fork子线程来进行持久化，保证了高性能；大数据集时启动比AOF快。 缺点：安全性低、每隔一段时间进行持久化，若持久化过程中出现故障，会导致数据丢失，适合对数据严谨要求不高的场合。 AOF：Redis将每次写命令记录到单独的日志文件中，当重启Redis会从日志文件的命令执行一遍恢复数据 优点：安全性高，每一个写操作都会记录到aof文件中，即使备份过程中出现故障，也可通过redis-check-aof工具修复。aof文件过大时可以进行重写合并一些操作命令。 缺点：比RDB文件大，恢复效率低 五、key删除策略 定时删除+惰性删除 定时删除：定期扫描随机获取一些key，如果过期进行删除。 惰性删除：在访问的时候，发现key已经过期，再删除。 六

你知道的越多，你不知道的越多 GitHub地址 https://github.com/AobingJava/JavaFamily 已经开源，有面试点，欢迎【Star】和【完善】 前言 Redis在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（请允许我使用一下夸张的修辞手法）。 于是在一个寂寞难耐的夜晚，我痛定思痛，决定开始写《吊打面试官》系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 絮叨 上一期因为是在双十一一直在熬夜的大环境下完成的，所以我自己觉得质量明显没之前的好，我这不一睡好就加班加点准备补偿大家，来点干货。（熬夜太容易感冒了，这次点个赞别白嫖了！） 顺带提一嘴，我把我准备写啥画了一个思维导图，以后总不能每篇都放个贼大的图吧，就开源到了我的GitHub，大家有兴趣可以去完善和Star。 这篇我就先放出来大家看看，感觉还是差点意思，等大家完善了。 回望过去 上一期吊打系列我们提到了Redis相关的一些知识，还没看的小伙伴可以回顾一下 《吊打面试官》系列-Redis基础 《吊打面试官》系列

Redis高可用—数据持久化 一、为什么需要持久化？ 二、Redis数据持久化方式 1. RDB持久化 1.1 什么时候触发RDB持久化？ 1.1.1 手动触发 1.1.2 自动触发 1.2 redis.conf 中RDB相关配置 1.3 RDB持久化步骤 2. AOF持久化 2.1 redis.conf 中AOF相关配置 2.2 AOF持久化步骤 2.3 AOF重写 2.3.1 为什么AOF重写？ 2.3.2 AOF重写触发机制 2.3.3 AOF重写规则 2.3.4 AOF重写步骤 3. RDB和AOF对比 三、参考文献 Redis的高可用从以下几个方面来保证： 数据持久化 主从复制 自动故障恢复 集群 笔者将对以上几个方面进行逐一介绍，今天这篇文章先来介绍Redis的数据持久化。 一、为什么需要持久化？ Redis是内存数据库，数据全部保存在内存中，如果实例宕机，数据将会全部丢失，Redis提供了完善的数据持久化机制，可以把数据持久化到磁盘上，方便我们进行备份和快速恢复数据。 二、Redis数据持久化方式 Redis提供了2种数据持久化方式： RDB：将内存中的数据以快照的形式保存到硬盘里，生成dump.rdb文件，该文件是一个二进制文件。因为RDB文件保存在磁盘里，即使Redis服务器进程退出，RDB文件还在，Redis服务器在启动时检测到RDB文件存在

正文 众所周知，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把数据存储在内存中，当进程退出后数据就会丢失。Redis持久化机制可以将内存中的数据存储到磁盘上，当重新启动时可以从磁盘文件中读取数据加载到内存中。 Redis支持两种持久化机制：全量镜像RDB和增量式持久化AOF。 RDB RDB是Redis的快照，存储了Redis中所有未过期的键值对。 在 redis.conf 中配置RDB: # 配置rdb文件的路径 # 若使用相对路径，工作目录由 dir 配置指定 dbfilename dump.rdb dir /var/lib/redis # save 项配置保存策略， 格式为`save <seconds> <changes>` # save 条件可以配置多个， 若其中任一个条件被满足则会更新快照 save 900 1 # 900 秒内至少有 1 个 key 被改变 save 300 10 # 300 秒内至少有 300 个 key 被改变 save 60 10000 # 60 秒内至少有 10000 个 key 被改变 save "" # 注释所有 save 配置，或在最后添加一个空的save配置可以禁用自动保存 stop-writes-on-bgsave-error yes # 当保存快照文件失败后，redis不再执行任何写请求，以避免无法持久化造成错误 rdbcompression yes # 在保存快照时对文件进行压缩

redis 主从复制 名词 建立复制 取消复制 切主 slaveof <masterip> <masterport> slaveof no one info replication config rewrite dump.rdb 复制 bin 和 redis.conf [root@localhost redis-3.2.8]# mkdir -p /usr/local/src/redis/redis-master-slave/redis-6379 [root@localhost redis-3.2.8]# cp -r bin/ /usr/local/src/redis/redis-master-slave/redis-6379/ [root@localhost redis-3.2.8]# cp redis.conf /usr/local/src/redis/redis-master-slave/redis-6379/ [root@localhost redis-master-slave]# cp -r redis-6379/ redis-6380 [root@localhost redis-master-slave]# cp -r redis-6379/ redis-6381 [root@localhost redis-master-slave]# ll total 0 drwxr

Redis持久化RDB和AOF 为什么Redis需要持久化？ 因为Redis属于内存型数据库，数据是储存在内存当中的，当遇到不可抗力因素，比如断电，那么储存在内存中的数据就会丢失。所以为了保证数据的完整性，我们需要做持久化操作，来保证数据的完整性。 Redis中都有哪些持久化机制？ Redis早就考虑到了这一点，所以在Redis中，为我们准备了两种持久化的机制，RDB和AOF。 既然Redis为我们提供了两种持久化的机制，那我们到底该选用哪个呢？其实啊，在Redis配置文件中RDB这种机制是默认开启的，而AOF机制是默认关闭的，也就是说如果你不进行配置，那么Redis就默认你使用了RDB这种持久化的机制。而当你开启AOF机制，那么Redis就会优先使用AOF持久化机制来进行数据的持久化操作。 下面我们来了解一下什么是RDB，什么又是AOF。 RDB（Redis Database）： RDB是Redis用来持久化的一种机制，是把当前内存中的数据集快照写进磁盘中。 在 上篇博客 中提到过，在redis.conf配置文件中有一个叫做SNAPSHOTTING的配置模块，在里面我们可以看到有save 900 1 ，save 300 10 ， save 60 10000。这里的save配置的是触发持久化操作的条件，save 900 1就是指在900秒内至少有一个key发生了改变

Redis 数据结构使用场景 一、redis 数据结构使用场景 原来看过 redisbook 这本书，对 redis 的基本功能都已经熟悉了，从上周开始看 redis 的源码。目前目标是吃透 redis 的数据结构。我们都知道，在 redis 中一共有5种数据结构，那每种数据结构的使用场景都是什么呢？ String——字符串 Hash——字典 List——列表 Set——集合 Sorted Set——有序集合 下面我们就来简单说明一下它们各自的使用场景： 1. String——字符串 String 数据结构是简单的 key-value 类型，value 不仅可以是 String，也可以是数字（当数字类型用 Long 可以表示的时候encoding 就是整型，其他都存储在 sdshdr 当做字符串）。使用 Strings 类型，可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受 Redis 的定时持久化（可以选择 RDB 模式或者 AOF 模式），操作日志及 Replication 等功能。除了提供与 Memcached 一样的 get、set、incr、decr 等操作外，Redis 还提供了下面一些操作： LEN niushuai ：O(1)获取字符串长度 APPEND niushuai redis ：往字符串 append 内容，而且采用智能分配内存

redis是一个key-value 存储系统 。包括string(字符串)、list( 链表 )、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。 高可用分布式集群 一，高可用 高可用（High Availability），是当一台服务器停止服务后，对于业务及用户毫无影响。 停止服务的原因可能由于网卡、路由器、机房、CPU负载过高、内存溢出、自然灾害等不可预期的原因导致，在很多时候也称单点问题。 （1）解决单点问题主要有2种方式： 主备方式 这种通常是一台主机、一台或多台备机，在正常情况下主机对外提供服务，并把数据同步到备机，当主机宕机后，备机立刻开始服务。 主从方式 这种采取一主多从的办法，主从之间进行数据同步。 当Master宕机后，通过选举算法(Paxos、Raft)从slave中选举出新Master继续对外提供服务，主机恢复后以slave的身份重新加入。 主从另一个目的是进行读写分离，这是当单机读写压力过高的一种通用型解决方案。 其主机的角色只提供写操作或少量的读，把多余读请求通过负载均衡算法分流到单个或多个slave服务器上。 二，分布式 分布式(distributed), 是当业务量、数据量增加时，可以通过任意增加减少服务器数量来解决问题。 集群时代 至少部署两台Redis服务器构成一个小的集群，主要有2个目的： 高可用性