Redis 4.x 安装及 发布/订阅实践和数据持久化设置

1、或者源码安装包

#wget http://download.redis.io/releases/redis-4.0.6.tar.gz

 

2、解压源码包

#tar -zxf redis-4.0.6.tar.gz

 

3、编译

#cd redis-4.0.6

#make

#make test

 

4、运行

# cd scr     说明：命令都在src内

#./redis-server --port 7878    说明：自定义7878端口启动，默认6379

成功界面：

 

 

5、发布与订阅

 

发布消息：

publish channel:频道名  消息内容

如无订阅者返回 interger0

 

订阅消息：

subscribe channer:频道名  

订阅状态下，会实时读取到发布者发送到该频道的消息，如下图左右对比：

 

从而实现了消息发布者和订阅者的隔离，通过redis进行消息互转。

 

配置文件说明:

位置：编译根目录下redis-4.0.6/redis.conf

 

 

数据持久化:

 

方式一：snapshots

 

根据配置设置一段时间内数据发送变化达到一定此次就进行持久化保存，也是redis默认开启的方式

 

配置文件说明：Save db on disk配置段

 

 

交互命令下sava和bgsave的区别

一，save保存数据到磁盘的方式：

Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

语法
redis Save 命令基本语法如下：

redis 127.0.0.1:6379> SAVE

返回值

保存成功时返回 OK 。

 

二，BGSAVE保存数据到磁盘的方式：

BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

客户端可以通过 LASTSAVE 命令查看相关信息，判断 BGSAVE 命令是否执行成功。

 

时间复杂度：

O(N)， N 为要保存到数据库中的 key 的数量。


案例：

redis> BGSAVE
Background saving started

 

 

 

方式二：APPEND ONLY MODE（AOF）

 

快照模式并不十分健壮，当系统停止，或者无意中Redis被kill掉，最后写入Redis的数据就会丢失。这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，Redis就不是一个合适的选择。
Append-only文件模式是另一种选择。
你可以在配置文件中打开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操作。

这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。

　　3、appednfsync always

当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响

 　　建议采用 appendfsync everysec（缺省方式）

　　快照模式可以和AOF模式同时开启，互补影响

 

3、AOF重写

AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令,
AOF日志也不是完全按客户端的请求来生成日志的，比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，因为浮点数操作可能在不同的系统上会不同，所以为了避免同一份日志在不同的系统上生成不同的数据集，所以这里只将操作后的结果通过SET来记录。

 

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

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

 

 命令：BGREWRITEAOF， 我们应该经常调用这个命令来来重写

 

数据恢复：

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

 

 

 总结，一种是快照，一种是日志文件，可以根据数据是否重要区分使用。