数据库缓存

港控/mmm° 2023-10-08 21:08 1阅读 0赞

许多web停用都将数据保存到RDBMS（关系型数据库）中，应用服务器中读取数据并在浏览器中显示。但随着数据量增大、访问的集中，就会出现RDBMS的负担加重，数据库响应恶化，网站显示延迟等重大影响。

Memcahe/redis是高性能的分布式内存缓存服务器，通过缓存数据库查询结果，减少数据库访问次数，以提高动态web等应用速度，提高可扩展性。

#### 简而言之：缓存数据库查询结果，加快访问速度，缓解数据库压力。 ####

##### Nosql #####

非关系型数据库（not only sql）

为弥补关系型数据库的不足

以键值方式存储数据

缓存数据库

产品有redis、memcached、mongoDB

##### Memcache #####

##### 特点 #####

内置内存存储方式（重启操作系统会导致全部数据消失）

简单的key/value存储

不互相通信的分布式

#### 缓存原理 ####

检查用户请求的数据时缓存中是否存在，若存在直接返回，无需查询数据库。

若请求数据在缓存中查询不到，去查询数据库，返回数据，同时把数据存储到缓存中一份。

保持缓存的“新鲜性”，每当数据发生变化的时候，要同步更新缓存的信息，确保用户不会在缓存取到旧的数据。

#### Redis ####

redis是一个开源的，使用C语言编写的，支持网络交互的，可基于内存也可持久化的key-Value数据库。

官网：redis.io

#### 特点 ####

丰富的数据结构

支持持久化

支持事物（事物：一个完整的动作，要么全部执行，要么什么都没做。）

支持主从

#### 安装 ####

从reids.io下载最新版redis-X.Y.Z.tar.gz后解压。然后进入redis-X.Y.Z文件夹make即可。

# wget http://download.redis.io/releases/redis-4.0.9.tar.gz# tar xzf redis-4.0.9.tar.gz -C /# cd redis-4.0.9# make

若因缺包报错，在安装完缺失的包之后需重新解压新包进行make安装，若没有编译工具需要先安装yum -y install gcc make

启动redis（默认非daemon形式启动）
    # ./src/redis-server
    指定配置文件启动
    # ./src/redis-server ../redis.conf

#### 设置开机启动 ####

1.# mkdir /etc/redis2.# cp   /redis-4.0.9/redis.conf  /etc/redis/6379.conf

**启动脚本**

# vim /etc/init.d/redis
    
    #!/bin/sh
    # chkconfig: 2345 10 90  
    # description: Start and Stop redis 
    REDISPORT=6379
    EXEC=/redis-4.0.9/src/redis-server
         #（可更改）
    CLIEXEC=/redis-4.0.9/src/redis-cli
            #(可更改)     
    PIDFILE=/var/run/redis_${REDISPORT}.pid
    CONF="/etc/redis/${REDISPORT}.conf"
    
    case "$1" in
        start)
            if [ -f $PIDFILE ]
            then
                    echo "$PIDFILE exists, process is already running or crashed"
            else
                    echo "Starting Redis server..."
                    $EXEC $CONF &   #（增加）
            fi
            ;;
        stop)
            if [ ! -f $PIDFILE ]
            then
                    echo "$PIDFILE does not exist, process is not running"
            else
                    PID=$(cat $PIDFILE)
                    echo "Stopping ..."
                    $CLIEXEC -p $REDISPORT shutdown
                    while [ -x /proc/${PID} ]
                    do
                        echo "Waiting for Redis to shutdown ..."
                        sleep 1
                    done
                    echo "Redis stopped"
            fi
            ;;
        restart)
            "$0" stop
            sleep 3
            "$0" start
            ;;
        *)
            echo "Please use start or stop as first argument"
            ;;syst
    esac

**授权**

# chmod 777 /etc/init.d/redis

**加入开机启动**

# chkconfig --add redis# chkconfig redis on# systemctl daemon-reload   //重新加载自启动系统

Copy

**启动方式**

# /etc/init.d/redis start   6# systemctl start redis

Copy

**端口**

默认服务端口为6379

**测试**

# ./src/redis-cli 
    
    127.0.0.1:6379> set name hello
    OK
    127.0.0.1:6379> get name
    "hello"
    127.0.0.1:6379> save   //保存数据到磁盘
    
    127.0.0.1:6379> shutdown  //通过客户端来关闭redis服务端  禁用

#### 数据结构 ####

redis 是一种高级的key:value存储系统，它的value支持五种数据类型：

字符串（strings）

字符串列表（lists）

字符串集合（sets）

有序字符串集合（sorted sets）

哈希（hashes）

注意：

key不可太长，尽量不要超过1024字节，这样不仅会小孩内存，而且会降低查找效率。

key也不要太短，太短的话，key的可读性会降低。

在项目中，建议key使用统一的命名格式。

#### redis持久化 ####

开启持久化功能后，重启redis，数据会自动通过持久化文件恢复。

#### RDB（默认开启） ####

在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上。RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束，才会用这个临时文件替换上次持久换文件。这种特性可让我们随时备份文件，因为快照文件总是完整可用的。

**特点**

周期性

不影响数据写入

RDB会启动子进程，备份所有数据。当前进程继续提供数据读写，当备份完成替换老的备份文件。

高效，一次性还原所有数据

完美性较差

故障点到上一次备份之间的数据无法恢复。

**查看RDB开启状态**

vim /redis-4.0.9/redis.conf 
    
    dbfilename dump.rdb
    #dbfilename：持久化数据存储在本地的文件
    
    dir ./
    #dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下
    
    save 900 1
    save 300 10
    save 60 10000
    ##snapshot触发的时机，save <seconds> <changes>  
    ##如下为900秒后，至少有一个变更操作，才会snapshot  
    ##对于此值的设置，需要谨慎，评估系统的变更操作密集程度  
    ##可以通过“save “””来关闭snapshot功能  
    #save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。
    
    stop-writes-on-bgsave-error yes 
    ##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
    
    rdbcompression yes  
    ##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间

**AOF**

AOF，英文是Append Only File ，即只允许追加不允许改写的文件。

AOF，将redis执行过得所有写指令（每秒钟），记录在日志里，再次redis重新启动时只要把这些写指令从前到后再重复执行一遍，就可实现数据恢复。

**特点**

实时性

完整性较好

体积大

记录/删除数据的指令，都会被记录。恢复速度慢于RDB。

**开启AOF**

vim /redis-4.0.9/redis.conf
    
    appendonly yes  
    ##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能  
    ##只有在“yes”下，aof重写/文件同步等特性才会生效  
    
    appendfilename appendonly.aof  
    ##指定aof文件名称 
    
    appendfsync everysec  
    ##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec  
    
    no-appendfsync-on-rewrite no  
    ##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”  
    
    auto-aof-rewrite-min-size 64mb 
    ##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”  
    
    auto-aof-rewrite-percentage 100  
    ##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。  
    ##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后  
    ##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。

**默认的AOF持久化策略**

每秒钟fsync（把缓存中的写指令记录到磁盘中）一次，在这种情况下，redis，仍可以保持良好的处理性能，即使redis故障也只会丢失最近一秒的数据。

**AOF日志修复**

若在追加日志时，恰好遇到磁盘空间满，inode满或断电等情况导致日志写入不完整，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。

可使用redis的提供的redis-check-aof工具，可以用来进行日志修复。

1.备份被写坏的AOF文件
    2.运行redis-check-aof –fix进行修复
    3.用diff -u来看下两个文件的差异，确认问题点
    4.重启redis，加载修复后的AOF文件

Copy

**AOF重写**

AOF使用追加模式，若不做任何处理，AOF文件会越来越大，因此，redis提供了重写机制（rewrite）机制。

文件重写机制（rewrite）：当AOF文件大小超过所设定的阈值时，redis会启动AOF的内容压缩，只保留可以恢复数据的最小指令集。

#### 原理： ####

重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。

**通过AOF恢复数据**

若意外执行了FLUSHALL，导致redis内存中数据被清空。只要redis配置了AOF持久化方式，且AOF文件还没被重写，可以执行以下操作恢复。

暂停redis

编辑AOF文件将最后一行的FLUSHALL删除

重启redis

**持久化选择RDB和AOF的选择方式**

官方建议两个同时使用这样可以提供更可靠的持久化方案。

这种情况下redis重启的话，会优先采用AOF方式来进行数据恢复（AOF恢复数据完整度更高。）

AOF写入数据快，RDB写入速度慢

如果没有数据持久化需求，可以关闭RDB和AOF方式，这样的话redis将变成一个纯内存数据库，就像memcache一样。

#### redis主从、哨兵\` ####

##### **主从同步** #####

redis同mysql一样支持主从同步（同时也支持一主多从以及多级从结构）

redis的主从同步是异步进行的，这种模式的优点是主从同步不会影响主逻辑，也不会降低redis的处理性能。

##### 使用主从结构的原因 #####

纯碎的冗余备份

提升读性能，比如很小号性能的SORT就可以有从服务器来承担。

##### 优化 #####

可以考虑关闭主服务器的数据持久化功能，只让从服务器持久化，这样可以提高主服务器的处理性能。

将从服务器设置为只读模式，这样可以避免从服务器数据被误修改，但从服务器仍然可以接受CONRG指令，因此不应将从服务器直接暴露到不安全的网络环境中。（如必须如此，那可以考虑给重要指令进行重命名。）

##### 原理 #####

1.如果设置了一个Slave，无论是第一次连接还是重连到Master，它都会发出一个SYNC命令；

2.当Master收到SYNC命令之后，会做两件事：

a) Master执行BGSAVE，即在后台保存数据到磁盘（rdb快照文件）；
    
    b) Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）；

Copy

3.当Master在后台把数据保存到快照文件完成之后，Master会把这个快照文件传送给Slave，而Slave则把内存清空后，加载该文件到内存中；

4.而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步；

5.Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致；

6.需要注意的是Master和Slave之间一旦发生重连都会引发全量同步操作。但在2.8之后版本，也可能是部分同步操作。

#### 部分复制 ####

2.8开始，当Master和Slave之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。

Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Masterrun id）。当网络断开，Slave尝试重连时：

a. 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了；

b. 否则，依然需要全量复制操作；

sentinel

##### sentinel(哨兵) #####

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中

##### setinel作用 #####

1.Master状态检测

2.如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave

3.Master-Slave切换后，master\_redis.conf、slave\_redis.conf和sentinel.conf的内容都会发生改变，即master\_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

##### sentinel工作方式 #####

1.每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令

2.如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

3.如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 an>

4.当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线

5.在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

6.当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

7.若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

##### 主观下线和客观下线 #####

主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.

#### 举个栗子 ####

##### 环境 #####

三台服务器保持通讯畅通，并部署redis。
    master  slave1 slave2

Copy

##### 配置主从 #####

master

# vim /etc/redis/6379.conf 
    
    master:
    bind 0.0.0.0            //监控本地所有网卡IP
    protected-mode no

slave1/2

# vim /etc/redis/6379.conf 
    
    bind 0.0.0.0
    slaveof master_ip master_port   //修改master_ip和port
    protected-mode no

##### 测试 #####

# /redis-4.0.9/src/redis-cli 
    127.0.0.1:6379> info replication

master结果
    127.0.0.1:6379> info replication
    # Replication
    role:master
    connected_slaves:2
    slave0:ip=192.168.0.113,port=6379,state=online,offset=2212,lag=1
    slave1:ip=192.168.0.112,port=6379,state=online,offset=2212,lag=0
    
    slave结果
    127.0.0.1:6379> info replication
    # Replication
    role:slave
    master_host:192.168.0.109
    master_port:6379
    master_link_status:up

##### 配置sentienl #####

1.每台机器上修改redis主配置文件设置：bind 0.0.0.0

2.每台机器上修改sentinel配置文件：添加如下配置

# vim /redis-4.0.9/sentinel.conf
    
    sentinel monitor mymaster MASTERIP 6379 2
    //当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了。
    sentinel down-after-milliseconds mymaster 3000  //单位毫秒
    sentinel failover-timeout mymaster 10000
    protected-mode no

3.每台机器启动服务

# ./src/redis-sentinel sentinel.conf

4.关闭主服务器，观察从服务器状态

# /redis-4.0.9/src/redis-cli #info replication