Redis耐久化
Redis 供应了多种差别级别的耐久化体式格局：
RDB 耐久化能够在指定的时刻距离内生成数据集的时刻点快照（point-in-time snapshot）
AOF 耐久化纪录效劳器实行的一切写操纵敕令，并在效劳器启动时，经由历程从新实行这些敕令来复原数据集。 AOF 文件中的敕令悉数以 Redis 协定的花样来保存，新敕令会被追加到文件的末端。 Redis 还能够在背景对 AOF 文件举行重写（rewrite），使得 AOF 文件的体积不会超越保存数据集状况所需的现实大小。
Redis 还能够同时应用 AOF 耐久化和 RDB 耐久化。 在这类状况下， 当 Redis 重启时， 它会优先应用 AOF 文件来复原数据集， 因为 AOF 文件保存的数据集平常比 RDB 文件所保存的数据集更完全。
你以至能够封闭耐久化功用，让数据只在效劳器运转时存在。
RDB(Redis DataBase)
Rdb:在指定的时刻距离内将内存中的数据集快照写入磁盘，也就是行话讲的 snapshot 快照，它恢复时就是将快照文件直接读到内存里。
Redis 会零丁的建立(fork) 一个子历程来举行耐久化，会先将数据写入到一个临时文件中，待耐久化历程终了了，再用这个临时文件替代上次耐久化还的文件。全部历程总，主历程是不举行任何 IO 操纵，这就确保了极高的机能，假如须要举行大规模的数据恢复，且关于数据恢复的完全性不是异常敏感，那 RDB 要领要比 AOF 体式格局越发的高效。RDB 的瑕玷是末了一次耐久化后的数据能够丧失。
Fork 的作用是复制一个与当前历程一样的历程，新历程的一切数据(变量、环境变量、顺序计数器等)数值都和原历程一致，然则是一个全新的历程，并作为原历程的子历程
隐患：若当前的历程的数据量庞大，那末 fork 以后数据量*2,此时就会形成效劳器压力大，运转机能下降。
Rdb 保存的是 dump.rdb 文件
在测试：实行 flushAll 敕令, 应用 shutDown 直接封闭历程时，第二次翻开时 redis 会自动读取 dump.rdb 文件，然则恢复时，全为空。(此时的缘由：在封闭时刻，redis 体系会保存空的 dump.rdb 替代本来的缓存文件。所以第二次翻开的 redis体系时刻，自动读取的是空值文件)
RDB save 操纵
Rdb 是全部内存的紧缩的 snapshot，RDB 的数据构造，能够设置相符快照触发前提，默许的是 1 分钟内修正 1 万次，或许 5 分钟修正 10 次，或许是 15 分钟修正一次；
Save 禁用：假如想禁用 RDB 耐久化的战略，只需不设置任何 save 指令，或许是给 save 传入一个空字符串参数也能够。
-----> save 指令：马上保存操纵对象
怎样触发 RDB 快照
Save：save 时尽管保存，其他不论，悉数壅塞。
Bgsave：redis 会在背景举行快照操纵，快照操纵的同时还能够响应客户端的要求，能够经由历程 lastsave 敕令猎取末了一次胜利实行快照的时刻。
实行 fluhall 敕令，也会发作 dump.rdb 文件，但内里是空的。
怎样恢复:
将备份文件(dump.rdb)移动到 redis 装置目次并启动效劳即可
Config get dir 敕令可猎取目次
怎样住手
动态住手 RDB 保存划定规矩的要领：redis -cli config set save “”
AOF(Append Only File)
以日记的情势俩纪录每一个写操纵，将 redis 实行过的一切写指令纪录下来(读操纵不纪录)。只许追加文件但不能够改写文件，redis 启动之初会读取该文件从新构建数据，换言之，redis重启的话就依据日记文件的内容将写指令夙昔到后实行一次一完成数据恢复工作。
======APPEND ONLY MODE=====
开启 aof ：appendonly yes (默许是 no)
注重：
在现实工作生产的时刻往往会涌现：aof 文件损坏(收集传输或许其他题目致使 aof 文件损坏)
效劳器启动报错(然则 dump.rdb 文件是完全的) 申明启动先加载 aof 文件
解决方案：实行敕令 redis-check-aof --fix aof 文件 [自动搜检删除不和 aof 语法的字段]
Aof战略
Appendfsync 参数：
Always 同步耐久化 每次发作数据变动会被马上纪录到磁盘，机能较差但数据完全性较好。
Everysec： 出厂默许引荐，异步操纵，每秒纪录，日过一秒宕机，有数据丧失
No：从不 fsync ：将数据交给操纵体系来处置惩罚。更快，也更不平安的挑选。
Rewrite
观点：AOF 采纳文件追加体式格局，文件会越来越来大为防止涌现此种状况，新增了重写机制，aof 文件的大小凌驾所设定的阈值时，redis 就会自动 aof 文件的内容紧缩，值保存能够恢复数据的最小指令集，能够应用敕令 bgrewirteaof。
重写道理：aof 文件持续增长而大时，会 fork 出一条新历程来将文件重写(也就
是先写临时文件末了再 rename)，遍历新历程的内存中的数据，每条纪录有一条 set 语句，重写 aof 文件的操纵，并没有读取旧的的 aof 文件，而是将全部内存的数据库内容用敕令的体式格局重写了一个新的 aof 文件，这点和快照有点相似。
触发机制：redis 会纪录上次重写的 aof 的大小，默许的设置当 aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 触发(3G)
no-appendfsync-on-rewrite no : 重写时是不是能够应用 Appendfsync 用默许 no 即可，保证数据平安
auto-aof-rewrite-percentage 倍数 设置基准值
auto-aof-rewrite-min-size 设置基准值大小
AOF长处
应用 AOF 耐久化会让 Redis 变得异常耐久：你能够设置差别的 fsync 战略，比方无 fsync ，每秒钟一次 fsync ，或许每次实行写入敕令时 fsync 。 AOF 的默许战略为每秒钟 fsync 一次，在这类设置下，Redis 依旧能够坚持优越的机能，而且就算发作毛病停机，也最多只会丧失一秒钟的数据（ fsync 会在背景线程实行，所以主线程能够继承努力地处置惩罚敕令要求）。
AOF 文件是一个只举行追加操纵的日记文件（append only log）， 因此对 AOF 文件的写入不须要举行 seek ， 纵然日记因为某些缘由而包含了未写入完全的敕令（比方写入时磁盘已满，写入半途停机，等等）， redis-check-aof 东西也能够轻易地修复这类题目。
Redis 能够在 AOF 文件体积变得过大时，自动地在背景对 AOF 举行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小敕令鸠合。 全部重写操纵是相对平安的，因为 Redis 在建立新 AOF 文件的历程当中，会继承将敕令追加到现有的 AOF 文件内里，纵然重写历程当中发作停机，现有的 AOF 文件也不会丧失。 而一旦新 AOF 文件建立终了，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并最先对新 AOF 文件举行追加操纵。
AOF 文件有序地保存了对数据库实行的一切写入操纵， 这些写入操纵以 Redis 协定的花样保存， 因此 AOF 文件的内容异常轻易被人读懂， 对文件举行剖析（parse）也很轻松。 导出（export） AOF 文件也异常简朴： 举个例子， 假如你不小心实行了 FLUSHALL 敕令， 但只需 AOF 文件未被重写， 那末只需住手效劳器， 移除 AOF 文件末端的 FLUSHALL 敕令， 并重启 Redis ， 就能够将数据集恢复到 FLUSHALL 实行之前的状况。
AOF瑕玷
关于雷同的数据集来讲，AOF 文件的体积平常要大于 RDB 文件的体积。
依据所应用的 fsync 战略，AOF 的速率能够会慢于 RDB 。 在平常状况下， 每秒 fsync 的机能依旧异常高， 而封闭 fsync 能够让 AOF 的速率和 RDB 一样快， 纵然在高负荷之下也是云云。 不过在处置惩罚庞大的写入载入时，RDB 能够供应更有保证的最大耽误时刻（latency）。
AOF 在过去曾发作过如许的 bug ： 因为个别敕令的缘由，致使 AOF 文件在从新载入时，没法将数据集恢复成保存时的原样。 （举个例子，壅塞敕令 BRPOPLPUSH 就曾引发过如许的 bug 。）
测试套件里为这类状况添加了测试： 它们会自动生成随机的、庞杂的数据集，并经由历程从新载入这些数据来确保一切正常。虽然这类 bug 在 AOF 文件中并不罕见， 然则对照来讲， RDB 几乎是不能够涌现这类 bug 的。
备份Redis 数据
肯定要备份你的数据库！
磁盘毛病， 节点失效， 诸云云类的题目都能够让你的数据消逝不见， 不举行备份是异常风险的。
Redis 关于数据备份是异常友爱的， 因为你能够在效劳器运转的时刻对 RDB 文件举行复制： RDB 文件一旦被建立， 就不会举行任何修正。 当效劳器要建立一个新的 RDB 文件时， 它先将文件的内容保存在一个临时文件内里， 当临时文件写入终了时， 顺序才应用 rename(2) 原子地用临时文件替代本来的 RDB 文件。
这也就是说， 不管什么时候， 复制 RDB 文件都是相对平安的。
发起：
建立一个按期使命（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 而且天天将一个 RDB 文件备份到另一个文件夹。
确保快照的备份都带有响应的日期和时刻信息， 每次实行按期使命剧本时， 应用 find 敕令来删除逾期的快照： 比方说， 你能够保存近来 48 小时内的每小时快照， 还能够保存近来一两个月的逐日快照。
最少天天一次， 将 RDB 备份到你的数据中心以外， 或许最少是备份到你运转 Redis 效劳器的物理机械以外。
容灾备份
Redis 的容灾备份基本上就是对数据举行备份， 并将这些备份传送到多个差别的外部数据中心。
容灾备份能够在 Redis 运转并发作快照的主数据中心发作严峻的题目时， 依旧让数据处于平安状况。
有的Redis 用户是创业者， 他们没有大把大把的钱能够糟蹋， 所以下面引见的都是一些有用又廉价的容灾备份要领：
Amazon S3 ，以及其他相似 S3 的效劳，是一个构建灾害备份体系的好处所。 最简朴的要领就是将你的每小时或许逐日 RDB 备份加密并传送到 S3 。 对数据的加密能够经由历程 gpg -c 敕令来完成（对称加密形式）。 记得把你的暗码放到几个差别的、平安的处所去（比方你能够把暗码复制给你构造里最主要的人物）。 同时应用多个贮存效劳来保存数据文件，能够提拔数据的平安性。
传送快照能够应用 SCP 来完成（SSH 的组件）。 以下是简朴而且平安的传送要领： 买一个离你的数据中心异常远的 VPS(假造专用效劳器) ， 装上 SSH ， 建立一个无口令的 SSH 客户端 key ， 并将这个 key 添加到 VPS 的 authorized_keys 文件中， 如许就能够向这个 VPS 传送快照备份文件了。 为了到达最好的数据平安性，最少要从两个差别的供应商那边各购置一个 VPS 来举行数据容灾备份。
须要注重的是， 这类容灾体系假如没有小心肠举行处置惩罚的话， 是很轻易失效的。
最低限制下， 你应当在文件传送终了以后， 搜检所传送备份文件的体积和原始快照文件的体积是不是雷同。 假如你应用的是 VPS ， 那末还能够经由历程比对文件的 SHA1 校验和来确认文件是不是传送完全。
别的， 你还须要一个自力的警报体系， 让它在担任传送备份文件的传送器（transfer）失灵时关照你。
Redis主从复制
Redis 支撑简朴且易用的主从复制（master-slave replication）功用， 该功用能够让从效劳器(slave server)成为主效劳器(master server)的准确复制品。
以下是关于 Redis 复制功用的几个主要方面：
Redis 应用异步复制。 从 Redis 2.8 最先， 从效劳器会以每秒一次的频次向主效劳器报告复制流（replication stream）的处置惩罚进度。
一个主效劳器能够有多个从效劳器。
不仅主效劳器能够有从效劳器， 从效劳器也能够有本身的从效劳器， 多个从效劳器之间能够组成一个图状构造。
复制功用不会壅塞主效劳器： 纵然有一个或多个从效劳器正在举行首次同步， 主效劳器也能够继承处置惩罚敕令要求。
复制功用也不会壅塞从效劳器： 只需在 redis.conf 文件中举行了响应的设置， 纵然从效劳器正在举行首次同步， 效劳器也能够应用旧版本的数据集来处置惩罚敕令查询。
不过， 在从效劳器删除旧版本数据集并载入新版本数据集的那段时刻内， 衔接要求会被壅塞。
你还能够设置从效劳器， 让它在与主效劳器之间的衔接断开时， 向客户端发送一个毛病。
复制功用能够纯真地用于数据冗余（data redundancy）， 也能够经由历程让多个从效劳器处置惩罚只读敕令要求来提拔扩展性（scalability）： 比方说， 沉重的 SORT 敕令能够交给隶属节点去运转。
能够经由历程复制功用来让主效劳器免于实行耐久化操纵： 只需封闭主效劳器的耐久化功用， 然后由从效劳器去实行耐久化操纵即可。
封闭主效劳器耐久化时，复制功用的数据平安。
当设置Redis复制功用时，强烈发起翻开主效劳器的耐久化功用。 不然的话，因为耽误等题目，布置的效劳应当要防止自动拉起。
案例：
假定节点A为主效劳器，而且封闭了耐久化。 而且节点B和节点C从节点A复制数据
节点A崩溃，然后由自动拉起效劳重启了节点A. 因为节点A的耐久化被封闭了，所以重启以后没有任何数据
节点B和节点C将从节点A复制数据，然则A的数据是空的， 因而就把本身保存的数据副本删除。
在封闭主效劳器上的耐久化，并同时开启自动拉起历程的状况下，即使应用Sentinel来完成Redis的高可用性，也是异常风险的。 因为主效劳器能够拉起得异常快，以至于Sentinel在设置的心跳时刻距离内没有检测到主效劳器已被重启，然后照样会实行上面的数据丧失的流程。
不管什么时候，数据平安都是极其主要的，所以应当制止主效劳器封闭耐久化的同时自动拉起。
从效劳器设置
设置一个从效劳器异常简朴， 只需在设置文件中增添以下的这一行就能够了：
slaveof 192.168.1.1 6379
别的一种要领是挪用 SLAVEOF 敕令，输入主效劳器的 IP 和端口，然后同步就会最先
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK
只读从效劳器
从 Redis 2.6 最先， 从效劳器支撑只读形式， 而且该形式为从效劳器的默许形式。
只读形式由 redis.conf 文件中的 slave-read-only 选项掌握， 也能够经由历程 CONFIG SET 敕令来开启或封闭这个形式。
只读从效劳器会拒绝实行任何写敕令， 所以不会涌现因为操纵失误而将数据不小心写入到了从效劳器的状况。
别的，对一个隶属效劳器实行敕令 SLAVEOF NO ONE 将使得这个隶属效劳器封闭复制功用，并从隶属效劳器转变回主效劳器，本来同步所得的数据集不会被抛弃。
应用『 SLAVEOF NO ONE 不会抛弃同步所得数据集』这个特征，能够在主效劳器失利的时刻，将隶属效劳器用作新的主效劳器，从而完成无间断运转。
从效劳器相干设置：
假如主效劳器经由历程 requirepass 选项设置了暗码， 那末为了让从效劳器的同步操纵能够顺利举行， 我们也必需为从效劳器举行响应的身份验证设置。
关于一个正在运转的效劳器， 能够应用客户端输入以下敕令：
config set masterauth <password>
要永远地设置这个暗码， 那末能够将它加入到设置文件中：
masterauth <password>
主效劳器只在有最少 N 个从效劳器的状况下，才实行写操纵
从 Redis 2.8 最先， 为了保证数据的平安性，能够经由历程设置， 让主效劳器只在有最少 N 个当前已衔接从效劳器的状况下， 才实行写敕令。
不过， 因为 Redis 应用异步复制， 所以主效劳器发送的写数据并不肯定会被从效劳器接收到， 因此， 数据丧失的能够性依旧是存在的。
以下是这个特征的运作道理：
从效劳器以每秒一次的频次 PING 主效劳器一次， 并报告复制流的处置惩罚状况。
主效劳器会纪录各个从效劳器末了一次向它发送 PING 的时刻。
用户能够经由历程设置， 指定收集耽误的最大值 min-slaves-max-lag ， 以及实行写操纵所需的最少从效劳器数目 min-slaves-to-write 。
假如最少有 min-slaves-to-write 个从效劳器， 而且这些效劳器的耽误值都少于 min-slaves-max-lag 秒， 那末主效劳器就会实行客户端要求的写操纵。
另一方面， 假如前提达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的前提， 那末写操纵就不会被实行， 主效劳器会向要求实行写操纵的客户端返回一个毛病。
以下是这个特征的两个选项和它们所需的参数：
min-slaves-to-write <number of slaves> min-slaves-max-lag <number of seconds>
以上就是本篇文章的悉数内容，愿望能对人人的进修有所协助。更多精彩内容人人能够关注ki4网相干教程栏目！！！
以上就是Redis的耐久化和主从复制机制引见的细致内容，更多请关注ki4网别的相干文章！
