- Redis持久化方案
redis有rdb和aof两种持久化方案
- 1）rdb方式
- 当符合一定条件时会自动将内存中的所有数据执行快照操作并存储到硬盘上
- 默认存储在redis根目录的dump.rdb文件中，文件名在配置文件中可修改
- 文件保存方式是覆盖，在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。 这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份。 RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
- redis.conf中的默认配置
- save 900 1 ##15分钟有1条key变化save一次
- save 300 10 ##5分钟有10条key变化save一次
- save 60 10000 ##1分钟有10000条key变化save一次
- 手动执行save
- save：由主进程进行快照操作，会阻塞其它请求
- bgsave：由redis执行fork函数复制出一个子进程来进行快照操作，不阻塞
- 优点：
- 由于存储的有数据快照文件，恢复数据很方便
- 缺点：
-
保存点设置过大，就会导致宕机丢失的数据过多 -
保存点设置过小，又会造成IO瓶颈
-
- 2）aof方式
- aof方式的持久化是通过日志文件的方式。
- 默认情况下redis没有开启aof，可以通过参数appendonly参数开启
- 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
- aof持久配置：
- appendfsync always 每次都会执行
- appendfsync everysec 默认 每秒执行一次同步操作（推荐）
- appendfsync no不主动进行同步，由操作系统来做，30秒一次
- 优点：Redis会将每一个收到的写命令都通过Write函数追加到文件中，便于追踪
- 缺点：保存的文件比rdb要大很多
-
3）当redis启动时，如果rdb持久化和aof持久化都打开了，那么会优先使用aof方式 -
4）项目中到底该用哪个？下面是来自官方的建议：
-
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。 -
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。 -
很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。
-
- Redis主从复制
Redis的主机Master上的key发生变化后，会同步到从机Slave上，称为主从复制，只会从master同步到slave，不会从slave同步到master
- 1）原理：
- 在Slave启动并连接到Master之后，它将主动发送一条SYNC命令。此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的 命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存 盘并加载到内存中。此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
-
如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行（该功能需要在配置文件中配置实现：配置选项# slaveof <masterip> <masterport>，例如：slaveof 127.0.0.1 6379）。
-
2）实现：
-
配置slave redis的配置文件，配置slaveof 选项连接主机即可 -
可以使用一个Redis环境，复制多个配置文件，配置不同的端口，实现多个Redis启动环境
-
-
3）例子：
-
1）配置slave的连接主机 -
2）启动master服务器：redis-server.exe redis.conf -
3）启动slave服务器：redis-server.exe redis.conf -
4）启动master客户端：redis-cli.exe -h IP-p PORT -
5）启动slave客户端：redis-cli.exe -h IP-p PORT -
6）在master客户端中执行新增key操作：set key test -
7）在slave客户端中查看key：keys *（master新增的key会在slave中看到） -
8）在slave客户端中执行新增key操作：set key test2 -
9）在master客户端中查看key：keys *（slave新增的key会在master中没有）
-
- Redis读写分离
Redis的读写分离指一台Redis主机用来记录更新操作，其余多台主机执行查询操作，且数据可以从主机同步到从机，实现原理就是主从复制
- Redis主从切换
- 避免一个redis服务宕机，导致应用宕机的情况，我们启用sentinel(哨兵)服务，实现主从切换的功能
- 主从切换时在主从复制的基础上实现sentinel（sentinel是一个单独的应用，在redis2.6版本后随redis发布，并且redis2.8版本中发布的是sentinel 2，之前的版本存在bug，不建议使用）
- 实现：
- 1）配置sentinel.conf文件，例：
- port 26379 ##sentinel进程端口号
- sentinel monitor mymaster 127.0.0.1 6000 2 ##master主机信息，其中2代表有2台slave提示主机宕机后，在做主从切换，原因在于网络的不确定性。
- sentinel auth-pass mymaster 123456 ##master的用户名密码
- 2）启动sentinel服务
- redis-server sentinel.conf
- 3）查看服务器日志（6000为master，6001和6002未slave）：
- 1）配置sentinel.conf文件，例：
-
- 4）杀死master进程，发现主从切换现象
-
- 5）切换时，会将原6001的slave变成6000的master，原6000的master变成6001端口服务的slave，同时修改对应的sentinel.conf和redis.conf文件的配置修改
- sentinel服务本身也不是万能的，也会宕机，所以我们还得部署sentinel集群，方式：
- 多复制几个sentinel.conf文件
- 启动多个sentinel服务
- Redis持久化方案
redis有rdb和aof两种持久化方案
- 1）rdb方式
- 当符合一定条件时会自动将内存中的所有数据执行快照操作并存储到硬盘上
- 默认存储在redis根目录的dump.rdb文件中，文件名在配置文件中可修改
- 文件保存方式是覆盖，在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。 这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份。 RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
- redis.conf中的默认配置
- save 900 1 ##15分钟有1条key变化save一次
- save 300 10 ##5分钟有10条key变化save一次
- save 60 10000 ##1分钟有10000条key变化save一次
- 手动执行save
- save：由主进程进行快照操作，会阻塞其它请求
- bgsave：由redis执行fork函数复制出一个子进程来进行快照操作，不阻塞
- 优点：
- 由于存储的有数据快照文件，恢复数据很方便
- 缺点：
-
保存点设置过大，就会导致宕机丢失的数据过多 -
保存点设置过小，又会造成IO瓶颈
-
- 2）aof方式
- aof方式的持久化是通过日志文件的方式。
- 默认情况下redis没有开启aof，可以通过参数appendonly参数开启
- 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
- aof持久配置：
- appendfsync always 每次都会执行
- appendfsync everysec 默认 每秒执行一次同步操作（推荐）
- appendfsync no不主动进行同步，由操作系统来做，30秒一次
- 优点：Redis会将每一个收到的写命令都通过Write函数追加到文件中，便于追踪
- 缺点：保存的文件比rdb要大很多
-
3）当redis启动时，如果rdb持久化和aof持久化都打开了，那么会优先使用aof方式 -
4）项目中到底该用哪个？下面是来自官方的建议：
-
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。 -
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。 -
很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。
-
- Redis主从复制
Redis的主机Master上的key发生变化后，会同步到从机Slave上，称为主从复制，只会从master同步到slave，不会从slave同步到master
- 1）原理：
- 在Slave启动并连接到Master之后，它将主动发送一条SYNC命令。此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的 命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存 盘并加载到内存中。此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
-
如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行（该功能需要在配置文件中配置实现：配置选项# slaveof <masterip> <masterport>，例如：slaveof 127.0.0.1 6379）。
-
2）实现：
-
配置slave redis的配置文件，配置slaveof 选项连接主机即可 -
可以使用一个Redis环境，复制多个配置文件，配置不同的端口，实现多个Redis启动环境
-
-
3）例子：
-
1）配置slave的连接主机 -
2）启动master服务器：redis-server.exe redis.conf -
3）启动slave服务器：redis-server.exe redis.conf -
4）启动master客户端：redis-cli.exe -h IP-p PORT -
5）启动slave客户端：redis-cli.exe -h IP-p PORT -
6）在master客户端中执行新增key操作：set key test -
7）在slave客户端中查看key：keys *（master新增的key会在slave中看到） -
8）在slave客户端中执行新增key操作：set key test2 -
9）在master客户端中查看key：keys *（slave新增的key会在master中没有）
-
- Redis读写分离
Redis的读写分离指一台Redis主机用来记录更新操作，其余多台主机执行查询操作，且数据可以从主机同步到从机，实现原理就是主从复制
- Redis主从切换
- 避免一个redis服务宕机，导致应用宕机的情况，我们启用sentinel(哨兵)服务，实现主从切换的功能
- 主从切换时在主从复制的基础上实现sentinel（sentinel是一个单独的应用，在redis2.6版本后随redis发布，并且redis2.8版本中发布的是sentinel 2，之前的版本存在bug，不建议使用）
- 实现：
- 1）配置sentinel.conf文件，例：
- port 26379 ##sentinel进程端口号
- sentinel monitor mymaster 127.0.0.1 6000 2 ##master主机信息，其中2代表有2台slave提示主机宕机后，在做主从切换，原因在于网络的不确定性。
- sentinel auth-pass mymaster 123456 ##master的用户名密码
- 2）启动sentinel服务
- redis-server sentinel.conf
- 3）查看服务器日志（6000为master，6001和6002未slave）：
- 1）配置sentinel.conf文件，例：
-
- 4）杀死master进程，发现主从切换现象
-
- 5）切换时，会将原6001的slave变成6000的master，原6000的master变成6001端口服务的slave，同时修改对应的sentinel.conf和redis.conf文件的配置修改
- sentinel服务本身也不是万能的，也会宕机，所以我们还得部署sentinel集群，方式：
- 多复制几个sentinel.conf文件
- 启动多个sentinel服务