redis持久化和分布式实现

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

本文使用的redis是3.2.1版本。下载后，文件如下

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

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

上面这些东西网上都有，就是redis的安装，所以这里只是提一下。

1、RDB快照 （snapshots）

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

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的默认持久化的方式，所需要修改的就是上面的写入磁盘的条件

2、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也是通过配置文件来设置持久化的，

　　1、appendfsync no

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

　　2、appendfsync everysec （默认）

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

　　这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。

　　所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。

　　3、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关键字）

 　　　　

　　　　这里本来是没有这行的，现在添加上。

然后分别启动主从服务

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

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

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