配置文件

redis启动时通过配置文件启动

原生配置文件全文在网上随便搜索一下就能找到了。

单位 

配置文件 unit单位 对大小写不敏感

 包含

类比import，将其他的配置文件引入

 网络

bind 127.0.0.1            // 绑定ip

protected-mode yes   //是否受保护

port 6379                   //服务端口

通用

daemonize  yes       //以守护进程的方式运行。默认是no，需要自己开启为yes

pidfile   /var/run/redis_6379.pid   //如果以后台方式运行，需要指定一个pid文件

loglevel notice     //日志配置，notice生产环境用

logfile  " "     // 日志的文件位置名。默认输出

databases  16   //数据库的数量，默认16个

always-show-logo yes   //是否总是显示logo

快照  rdb配置

持久化，在规定时间内，执行了多少次操作，则会持久化到文件  .rdb  .aof文件

redis为内存数据库，如果没有，会断电即失

save 900 1    //900s内至少1个key修改了,就进行持久化，下面相同

save 300 10

save 60 10000

stop -writes-on-bgsave-error  yes   //持久化出错后是否继续工作。

rdbcompression  yes    //是否压缩rdb文件，需要小号一些cpu资源

rdbchecksum  yes  //保存rdb文件时进行错误的检查校验

dir ./        //rdb文件保存的目录

REPLICATION  复制

关于主从复制的，

安全

requirepass  123456  //密码设置，默认为空

CLIENTS客户端限制

maxclients  10000  //设置能连接上redis的主义大客户端的数量

memory  management  内存设置

maxmemory  <bytes>  //redis配置最大的内存容量，默认字节

maxmemory-policy noeviction      //内存到达上限之后的处理策略

• volatile-lru：只对设置了过期时间的key进行LRU（默认值）
• allkeys-lru ： 是从所有key里 删除 不经常使用的key
• volatile-random：随机删除即将过期key
• allkeys-random：随机删除
• volatile-ttl ： 删除即将过期的
• noeviction :    永不过期，返回错误

APPEND ONLY 模式  aof配置

appendonly  no     //默认不开启aof模式，默认是使用rdb方式持久化，在大部分情况下，rdb够用

appendfilename  "appednonly.aof"  //持久化的文件的名字

# appendfsync always     //每次修改都写入

appendfsync everysec    //每秒执行一次 sync   可能会丢失这1s的数据

# appendfsync no           //不同步，不执行sync

RDB持久化

redis是内存数据库，不保存到硬盘中会端点即失

RDB(Redis DataBase)

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建( fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。默认就是RDB,一般情况下不需要修改这个配置!

rdb保存的文件是dump.rdb         

都是在我们的配置文件快照中进行配置的。 又是生产环境需要进行定时备份。

使用如下命令查找得到dump.rdb的位置在/var/lib/redis/dump.db

find / -name dump.rdb

同样的查询redis.conf文件在/etc/redis/redis.conf中

修改文件中rdb的配置信息如下

 将dump.rdb文件删除之后，在控制台输入save就会重新出现了dump.rdb了

然后在控制台插入5个新数据

 

 然后关闭redis再重新进去redis看见数据还在 

触发机制

1.save的规则满足时，会触发rdb规则

2.执行flushall命令，也会出发rdb规则

3.退出redis,也会产生rdb

4.执行shutdown,也会执行save

根据rdb文件恢复数据

只需要将rdb文件放到对应的目录即可，redis启动时会自动检查dump.rdb并进行恢复

下面是查看dump.rdb位置的方法

 优点和缺点

优点:

1.适合大规模的数据恢复

2.对数据的完整性要求不高

缺点:

1.需要一定的时间间隔，好比save 60 5,在59s时宕机了，则5条数据就没了

2.fork进程时会占用一定的内存空间。

AOF持久化

aof(Append Only File) 

追加文件。

将所有的命令都记录下来，history,恢复的时候就将该文件直接执行一遍。

 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

Aof保存的是 appendonly.aof 文件

默认不开启，手动进行配置。只需要将no改为yes即可。

 重启redis即可找到appendonly.aof

和dump.rdb在同一个目录下。

 

 进行两次set然后打开aof文件可以看见两条语句都保存了

 将aof文件破坏之后，是无法重启redis的，redis启动的时候会将appendonly.aof文件和redis-check-rdb文件进行比对，对不上就不允许启动。

 

 如果aof文件有错误，需要修复aof文件。

redis提供了一个工具，使用如下命令

redis-check-aof   --fix appendonly.aof

我这里因为两个文件不再同一个文件夹下所以要加上路径

重新看aof文件发现真就删除了不对劲的数据？？？/、/、、？？ 

如果文件正常，重启即可直接恢复，不正常就会被删除。

 

 优点和缺点

优点

1.每一次修改都同步，文件的完整性会更好。

2.默认美妙同步一次，可能丢失一秒的数据

3.从不同步，效率最高

缺点

1.相对于数据文件来说，aof远远大于rdb,修复速度也比rdb慢。

2.aof运行效率也比rdb慢，所以redis默认持久化就是rdb.

重写规则

如果aof文件大于64mb，会fork一个新的进程将文件进行重写。

aof默认就是无限追加，所以迟早会重写。

 Redis订阅发布

基本没人用的东西，了解即可，实际都是用的消息队列。

Redis 发布订阅(pub/sub)是一种消息通信模式: 发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

订阅/发布消息图 :

下图展示了频道 channel1 ，以及订阅这个频道的三个客户端-- client2、dlient5 和 client1 之间的关系 

 

当有新消息通过 PUBLISH 命令发送给频道channel1 时，这个消息就会被发送给订阅它的三个客户端 

 

 命令

 测试

创建一个订阅频道名为beiling

 在一个新的连接里面在频道中发布消息，在原本的频道就能看见

 订阅端

subscribe beiling

发送端

publish beiling  "hello redis"

原理