redis持久化和分布式实现

时间 2019-11-11

标签 redis 持久分布式实现栏目 Redis 繁體版

原文原文链接

Redis是一种面向“key-value”类型数据的分布式NoSQL数据库系统，具备高性能、持久存储、适应高并发应用场景等优点。redis

本文使用的redis是3.2.1版本。下载后，文件以下数据库

将文件解压到指定的目录，而后打开一个cmd，定位到这个目录，输入：redis-server.exe redis.windows.conf。这样就开启了redis服务。windows

一个简单的客户端，再打开一个cmd，一样的切换到刚才的目录，输入：redis-cli.exe -h 127.0.0.1 -p 6379 安全

上面这些东西网上都有，就是redis的安装，因此这里只是提一下。服务器

一、RDB快照 （snapshots）并发

缺省状况状况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你能够配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者你能够手工调用命令SAVE或BGSAVE。app

Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，而后在子进程中循环全部的数据，将数据写成为RDB文件。异步

RDB存在哪些优点：分布式

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是很是完美的。好比，你可能打算每一个小时归档一次最近24小时的数据，同时还要天天归档一次最近30天的数据。经过这样的备份策略，高并发

　　一旦系统出现灾难性故障，咱们能够很是容易的进行恢复。
    2). 对于灾难恢复而言，RDB是很是不错的选择。由于咱们能够很是轻松的将一个单独的文件压缩后再转移到其它存储介质上。
    3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它惟一须要作的只是fork出子进程，以后再由子进程完成这些持久化的工做，这样就能够极大的避免服务进程执行IO操做了。
    4). 相比于AOF机制，若是数据集很大，RDB的启动效率会更高。

RDB的不足：

　1). 若是你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。由于系统一旦在定时持久化以前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 因为RDB是经过fork子进程来协助完成数据持久化工做的，所以，若是当数据集较大时，可能会致使整个服务器中止服务几百毫秒，甚至是1秒钟。

rdb的持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。这个指定的时间间隔在redis.windows.conf文件中有设置。

这里为了试验须要，我将其修改成10秒内有一次修改就将数据写入磁盘。

打开简单的客户端窗口，先写入一条数据，而后等10秒后，将服务关掉，再次打开服务，在客户端获取刚才写入的数据

若是数据没有写入磁盘持久化，那么在关闭服务后，以前写入的数据就不存在。如今重启服务，在客户端获取数据看看

看到数据获取是成功的。

RDB快照是redis的默认持久化的方式，所须要修改的就是上面的写入磁盘的条件

二、Redis的第二个持久化策略：AOF日志

AOF日志的全称是Append Only File，从名字上咱们就能看出来，它是一个追加写入的日志文件。与通常数据库不一样的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。

AOF的优点：

1). 该机制能够带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不一样步。事实上，每秒同步也是异步完成的，其效率也是很是高的，所差的是一旦系统出现宕机现象，

　　　那么这一秒钟以内修改的数据将会丢失。而每修改同步，咱们能够将其视为同步持久化，即每次发生的数据变化都会被当即记录到磁盘中。能够预见，这种方式在效率上是最低的。至于无同步，无需多言，我想你们都能正确的理解它。
2). 因为该机制对日志文件的写入操做采用的是append模式，所以在写入过程当中即便出现宕机现象，也不会破坏日志文件中已经存在的内容。然而若是咱们本次操做只是写入了一半数据就出现了系统崩溃问题，不用担忧，

　　在Redis下一次启动以前，咱们能够经过redis-check-aof工具来帮助咱们解决数据一致性的问题。
3). 若是日志过大，Redis能够自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会建立一个新的文件用于记录此期间有哪些修改命令被执行。所以在进行rewrite切换时能够更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录全部的修改操做。事实上，咱们也能够经过该文件完成数据的重建。

要使用这种方式，须要修改redis.windows.conf文件

重启服务，在客户端执行如下操做

而后打开appendonly.aof，这个文件是在重启服务后建立的

能够看到文件记录了每次的操做。固然get操做不会记录

另外AOF日志也不是彻底按客户端的请求来生成日志的，好比命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，由于浮点数操做可能在不一样的系统上会不一样，因此为了不同一份日志在不一样的系统上生成不一样的数据集，因此这里只将操做后的结果经过SET来记录。

与rdb同样，aof也是经过配置文件来设置持久化的，

　　一、appendfsync no

　　当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，因此这一切就彻底依赖于操做系统的调试了。对大多数Linux操做系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。

　　二、appendfsync everysec （默认）

　　当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。可是当这一次的fsync调用时长超过1秒时。Redis会采起延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，

　　这一次的fsync就无论会执行多长时间都会进行。这时候因为在fsync时文件描述符会被阻塞，因此当前的写操做就会阻塞。

　　因此，结论就是：在绝大多数状况下，Redis会每隔一秒进行一次fsync。在最坏的状况下，两秒钟会进行一次fsync操做。

　　三、appednfsync always

　　当设置appendfsync为always时，每一次写操做都会调用一次fsync，这时数据是最安全的，固然，因为每次都会执行fsync，因此其性能也会受到影响。

AOF重写

每一条写命令都生成一条日志,AOF文件会很大

AOF重写是从新生成一份AOF文件，新的AOF文件中一条记录的操做只会有一次，而不像一份老文件那样，可能记录了对同一个值的屡次操做。其生成过程和RDB相似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程当中，全部的写操做日志仍是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操做完成后，会将全部缓冲区中的日志一次性写入到临时文件中。而后调用原子性的rename命令用新的 AOF文件取代老的AOF文件

为了试验，我屡次对key1进行了操做，在aof文件中，记录以下

如今来看看aof重写，这样的aof文件会是什么样子

再看下面的操做

从试验结果看，AOF重写，将同一条记录（好比key1）的屡次操做，在写入日志的时候都只记录一次。

数据恢复：

若是只配置AOF,重启时加载AOF文件恢复数据；
若是同时配置了RBD和AOF,启动是只加载AOF文件恢复数据;
若是只配置RBD,启动是讲加载dump文件恢复数据。

RDB和AOF同时工做会怎么样

（1）若是RDB在执行snapshotting操做，那么redis不会执行AOF rewrite；若是redis在执行AOF rewrite，那么就不会执行RDB snapshotting操做。

（2）若是RDB在执行snapshotting，此时用户主动执行BGREWRITEAOF命令，那么要等到RDB快照生成完以后，才会执行AOF rewrite。

（3）同时有RDB snapshotting文件和AOF日志，那么redis重启的时候，会优先使用AOF进行数据恢复，由于其中的日志更完整，这点已经屡次强调过了。

（
做者：一寂知千秋
连接：https://www.jianshu.com/p/bd074bdea9b9
來源：简书
简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。）

redis分布式的简单实现

这里主要是实现读写的分离，将redis下载下来后，分别解压到两个文件夹M(主)和S(从)。

主服务的配置别动，打开从服务的配置文件redis.windows.conf，须要修改两个地方

修改从服务绑定端口（修改时能够直接搜索port关键字）

　　　　这里原本是6379，主服务的端口就是6379,如今从服务改为6380

修改从服务对应的主服务地址（修改时能够直接搜索slaveof关键字）

　　　　这里原本是没有这行的，如今添加上。

而后分别启动主从服务

打开主服务的客户端，添加一个简单的数据

再打开从服务的客户端，来获取刚才写入的数据

能够看到，在从服务中是不能写入数据的。