redis管理篇笔记

た入场券 2022-01-27 01:55 116阅读 0赞

### redis管理篇笔记 ###

*  持久化
 *   *  RDB方式
     *  AOF方式
 *  复制

# 持久化 #

## RDB方式 ##

*  简介  
    RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。RDB是Redis默认采用的持久化方式。
 *  配置  
    在配置文件中的配置为：

# 含义：在时间内有至少几个键被更改则进行快照
    # 第一个参数是时间(单位：秒)，第二个：被更改键的个数
    save 900 1
    save 300 10
    save 60 10000

save参数指定了快照条件，可以存在多个条件，条件之间是“或”的关系。如果想要禁用自动快照，只需要将所有的save参数删除即可。  
redis默认把快照储存在当前目录的dump.rdb文件中，可以配置dir和dbfilename两个参数分别指定快照文件的储存路径和文件名。

*  save和bgsave  
    这两个手动发送的命令也可以进行让redis执行快照。  
    区别：save是由主进程进行快照操作，会阻塞住其它请求；  
    bgsave通过fork子进程进行快照操作；
 *  原理  
    快照的过程：  
    （1）Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；  
    （2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中  
    的临时文件；  
    （3）当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完  
    成。  
    在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。
 *  问题  
    通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。

## AOF方式 ##

默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数  
开启：  
appendonly yes  
开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬  
盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认  
的文件名是appendonly.aof，可以通过appendfilename参数修改：  
appendfilename appendonly.aof  
下面讲解AOF持久化的具体实现，假设在开启AOF持久化的情况下执行了如下4个命令：

SET foo 1
    SET foo 2
    SET foo 3
    GET foo

Redis会将前3条命令写入AOF文件中；  
可见AOF文件是纯文本文件，其内容正是Redis客户端向Redis发送的原始通信协议的内容（Redis的通信协议会在7.4节中介绍，为了便于阅读，这里将实际的命令部分以粗体显示），从中可见Redis确实只记录了前3条命令。然而这时有一个问题是前2条命令其实都是冗余的，因为这两条的执行结果会被第三条命令覆盖。随着执行的命令越来越多，AOF文件的大小也会越来越大，即使内存中实际的数据可能并没有多少。很自然地，我们希望Redis可以自动优化AOF文件，就上例而言，就是将前两条无用的记录删除，只保留第三条。实际上Redis也正是这样做的，每当达到一定条件时Redis就会自动重写AOF文件，这个条件可以在配置文件中设置：  
auto-aof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb  
auto-aof-rewrite-percentage参数的意义是当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据。auto-aof-rewrite-min-size参数限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多冗余的命令我们也并不太关心。除了让Redis自动执行重写外，我们还可以主动使用BGREWRITEAOF命令手动执行AOF重写。  
在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些。  
需要注意的是虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地  
写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持久化的应用都无法容忍这样的损失，这就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在Redis中我们可以通过appendfsync参数设置同步的时机：

# appendfsync always
    appendfsync everysec
    # appendfsync no

默认情况下Redis采用everysec 规则，即每秒执行一次同步操作。always表示每次执行写入都会执行同步，这是最安全也是最慢的方式。no表示不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），这是最快但最不安全的方式。一般情况下使用默认值everysec就足够了，既兼顾了性能又保证了安全。

# 复制 #

*  简介  
    通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失（或少量损失）数据。但是由于数据是存储在一台服务器上的，如果这台服务器的硬盘出现故障，也会导致数据丢失。为了避免单点故障，我们希望将数据库复制多个副本以部署在不同的服务器上，即使有一台服务器出现故障其他服务器依然可以继续提供服务。这就要求当一台服务器上的数据库更新后，可以自动将更新的数据同步到其他服务器上，Redis提供了复制（replication）功能可以自动实现同步的过程。  
    关于实现： [参考这里][Link 1]
 *  配置  
    同步后的数据库分为两类，一类是主数据库（master），一类是从数据库（slave）。主数据库可以进行读写操作，当发生写操作时自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库，  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5nMTgyMzgwMzI4OTE_size_16_color_FFFFFF_t_70]
 *  命令

# 为主数据库A加入从数据库B，只需要在从数据库中配置如下命令：主数据库无须任何任何配置
    slaveof 主数据库IP 主数据库端口
    例：在启动从数据库服务时配置主数据库：
    redis-service --port 6380 --slaveof 127.0.0.1 6379

在默认情况下从数据库是只读的，如果直接修改从数据库的数据会出现错误：

redis B＞SET foo hi
    (error) READONLY You can't write against a read only slave.

从数据库的配置文件中的slave-read-only为no以使从数据库可写，但是对从数据库的任何更改都不会同步给任何其他数据库，并且一旦主数据库中更新了对应的数据就会覆盖从数据库中的改动。

# 修改从数据库复制的著数据库配置命令：
    slaveof 主数据IP 主数据库端口

如果该数据库已经是其他主数据库的从数据库了，SLAVEOF命令会停止和原来数据库的同步转而和新数据库同步。还可以使用SLAVEOF NO ONE来使当前数据库停止接收其他数据库的同步转成主数据库。

[Link 1]: https://www.cnblogs.com/qianqianchen/p/6024918.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5nMTgyMzgwMzI4OTE_size_16_color_FFFFFF_t_70]: /images/20220127/6c82c9646ec34c6aaec59fc33587e2a4.png