八、Redis.conf

容量单位不区分大小写，G和GB有区别

可以使用 include 组合多个配置问题

网络配置

日志

# 日志

# Specify the server verbosity level.

# This can be one of:

# debug (a lot of information, useful for development/testing)

# verbose (many rarely useful info, but not a mess like the debug level)

# notice (moderately verbose, what you want in production probably) 生产环境

# warning (only very important / critical messages are logged)

loglevel notice

logfile "" # 日志的文件位置名

databases 16 # 数据库的数量，默认是 16 个数据库

always-show-logo yes # 是否总是显示LOGO

日志输出级别

debug

verbose

notice

waring

持久化规则

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

redis 是内存数据库，如果没有持久化，那么数据断电及失！

由于Redis是基于内存的数据库，需要将数据由内存持久化到文件中

持久化方式：

RDB

AOF

# 如果900s内，如果至少有一个1 key进行了修改，我们及进行持久化操作

save 900 1

# 如果300s内，如果至少10 key进行了修改，我们及进行持久化操作

save 300 10

# 如果60s内，如果至少10000 key进行了修改，我们及进行持久化操作

save 60 10000

# 我们之后学习持久化，会自己定义这个测试！

stop-writes-on-bgsave-error yes # 持久化如果出错，是否还需要继续工作！

rdbcompression yes # 是否压缩 rdb 文件，需要消耗一些cpu资源！

rdbchecksum yes # 保存rdb文件的时候，进行错误的检查校验！

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

SECURITY 安全

可以在这里设置redis的密码，默认是没有密码！

127.0.0.1:6379> ping

PONG

127.0.0.1:6379> config get requirepass # 获取redis的密码

1) "requirepass"

2) ""

127.0.0.1:6379> config set requirepass "123456" # 设置redis的密码

OK

127.0.0.1:6379> config get requirepass # 发现所有的命令都没有权限了

(error) NOAUTH Authentication required.

127.0.0.1:6379> ping

(error) NOAUTH Authentication required.

127.0.0.1:6379> auth 123456 # 使用密码进行登录！

OK

127.0.0.1:6379> config get requirepass

1) "requirepass"

2) "123456"

限制 CLIENTS(客户端连接相关)

maxclients 10000 # 设置能连接上redis的最大客户端的数量

maxmemory # redis 配置最大的内存容量

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

1、volatile-lru：只对设置了过期时间的key进行LRU(默认值)

2、allkeys-lru ： 删除lru算法的key

3、volatile-random：随机删除即将过期key

4、allkeys-random：随机删除

5、volatile-ttl ： 删除即将过期的

6、noeviction ： 永不过期，返回错误

APPEND ONLY 模式 aof配置

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

rdb完全够用！

appendfilename "appendonly.aof" # 持久化的文件的名字

# appendfsync always # 每次修改都会 sync。消耗性能

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

# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！

九、Redis持久化——RDB

面试和工作，持久化都是重点！

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能！

什么是RDB(Redis DataBase)

在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ；

默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义。

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

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。

这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！

有时候在生产环境我们会将这个文件进行备份！

rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的！

工作原理

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来完成该操作；

Redis 调用forks。同时拥有父进程和子进程。

子进程将数据集写入到一个临时 RDB 文件中。

当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制(copy-on-write)机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

触发机制

save的规则满足的情况下，会自动触发rdb原则

执行flushall命令，也会触发我们的rdb原则

退出redis，也会自动产生rdb文件

save

使用 save 命令，会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了；

由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

示意图

flushall命令

flushall 命令也会触发持久化 ；

触发持久化规则

满足配置条件中的触发条件 ；

可以通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作。

bgsave

bgsave 是异步进行，进行持久化的时候，redis 还可以将继续响应客户端请求 ；

bgsave和save对比

命令

save

bgsave

IO类型

同步

异步

阻塞？

是

是(阻塞发生在fock()，通常非常快)

复杂度

O(n)

O(n)

优点

不会消耗额外的内存

不阻塞客户端命令

缺点

阻塞客户端命令

需要fock子进程，消耗内存

如果恢复rdb文件！

1、只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！

2、查看需要存在的位置

127.0.0.1:6379> config get dir

1) "dir"

2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb 文件，启动就会自动恢复其中的数据

优缺点

优点：

适合大规模的数据恢复

对数据的完整性要求不高

缺点：

需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了。

fork进程的时候，会占用一定的内容空间。

十、Redis持久化——AOF

Append Only File

将我们所有的命令都记录下来，history，恢复的时候就把这个文件全部再执行一遍

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

什么是AOF

​ 快照功能(RDB)并不是非常耐久(durable)： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、以及未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

appendonly no yes则表示启用AOF

默认是不开启的，我们需要手动配置，然后重启redis，就可以生效了！

如果这个aof文件有错位，这时候redis是启动不起来的，我需要修改这个aof文件

redis给我们提供了一个工具redis-check-aof --fix

appendonly yes # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用

appendfilename "appendonly.aof"

appendfsync always # 每次修改都会sync 消耗性能

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

appendfsync no # 不执行 sync ,这时候操作系统自己同步数据，速度最快

优缺点

优点

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

没秒同步一次，可能会丢失一秒的数据

从不同步，效率最高

缺点

相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢！

Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

扩展：

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。

如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。

如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。

如何选择使用哪种持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

十一、Redis发布订阅

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

微博、关注系统！

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

订阅/发布消息图：

第一个：消息发送者， 第二个：频道 第三个：消息订阅者！

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

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

命令

PSUBSCRIBE pattern [pattern..]订阅一个或多个符合给定模式的频道。

PUNSUBSCRIBE pattern [pattern..]退订一个或多个符合给定模式的频道。

PUBSUB subcommand [argument[argument]]查看订阅与发布系统状态。

PUBLISH channel message向指定频道发布消息

SUBSCRIBE channel [channel..]订阅给定的一个或多个频道。

UNSUBSCRIBE channel [channel..]退订一个或多个频道

代码示例

------------订阅端----------------------

127.0.0.1:6379> SUBSCRIBE sakura # 订阅sakura频道

Reading messages... (press Ctrl-C to quit) # 等待接收消息

1) "subscribe" # 订阅成功的消息

2) "sakura"

3) (integer) 1

1) "message" # 接收到来自sakura频道的消息 "hello world"

2) "sakura"

3) "hello world"

1) "message" # 接收到来自sakura频道的消息 "hello i am sakura"

2) "sakura"

3) "hello i am sakura"

--------------消息发布端-------------------

127.0.0.1:6379> PUBLISH sakura "hello world" # 发布消息到sakura频道

(integer) 1

127.0.0.1:6379> PUBLISH sakura "hello i am sakura" # 发布消息

(integer) 1

-----------------查看活跃的频道------------

127.0.0.1:6379> PUBSUB channels"sakura"

原理

Redis是使用C实现的，通过分析 Redis 源码里的 pubsub.c 文件，了解发布和订阅机制的底层实现，籍此加深对 Redis 的理解。

Redis 通过 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能。

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

客户端订阅，就被链接到对应频道的链表的尾部，退订则就是将客户端节点从链表中移除。

缺点

如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使redis输出缓冲区的体积变得越来越大，这可能使得redis本身的速度变慢，甚至直接崩溃。

这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。

应用

消息订阅：公众号订阅，微博关注等等(起始更多是使用消息队列来进行实现)

多人在线聊天室。

稍微复杂的场景，我们就会使用消息中间件MQ处理。