目录

#1.1关系数据库与非关系型数据库

  1.1.1关心型数据库

  1.1.2非关系型数据库

  1.1.3非关系型数据库产生背景

#2.1redis简介

  2.1.1redis安装部署

  2.1.2配置参数

#3.1redis命令工具

  3.1.1redis-cli命令行工具

  3.1.2redis-benchmark测试工具

#4.1redis数据库常用命令

  4.1.1key相关命令

  4.1.2多数据库常用的命令

#5.1redis持久化

  5.1.1RDB和AOF的区别

  5.1.2RDB和AOF的优缺点

  5.1.3redis持久化配置

  5.1.4AOF重写

  5.1.5性能管理


1.1关系数据库与非关系数据库

1.1.1关系型数据库

    关系型数据库是一个结构化的数据库,创建在关系模型基础上,一般面向于记录。它借助于集合代数等数学概念和方法来处理数据库中的数据。关系模型就是指二维表格模型,因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。现实世界中,各种实体与实体之间的各种联系都可以用关系模型来表示。SQL 语句(标准数据查询语言)就是一种基于关系型数据库的语言,用于执行对关系型数据库中数据的检索和操作。

    主流的关系型数据库包括 Oracle、MySQL、SQL Server、Microsoft Access、DB2 等。

1.1.2非关系型数据库

     NoSQL (NoSQL = Not Only SQL),意思是 “不仅仅是 SQL”,是非关系型数据库的总称。主流的 NoSQL 数据库有 Redis、MongBD、Hbase、CouhDB 等等。以上这些非关系型数据库,他们的存储方式、存储结构以及使用的场景都是完全不同的。所以我们认为它是一个非关系型数据库的集合,而不是像关系型数据库一样,是一个统称。换言之,除了主流的关系型数据库以外的数据库,都可以认为是非关系型的。NoSQL 数据库凭借着其非关系型、分布式、开源及横向扩展等优势,被认为是下一代数据库产品。

1.1.3非关系型数据库产生背景

    随着 Web2.0 网站的兴起,关系型数据库在应对 Web2.0 网站,特别是海量数据和高并发的 SNS(Social Networking Services,即社交网络服务)类型的 Web2.0 纯动态网站时,暴露出很多难以解决的问题,例如三高问题。

(1)High performance—— 对数据库高并发读写需求
Web2.0 网站会根据用户的个性化信息来实时生成动态页面和提供动态信息,因此无法使用动态页面静态化技术。所以数据库的并发负载非常高,一般会达到 10000 次 /s 以上的读写请求。关系型数据库对于上万次的查询请求还是可以勉强支撑的,但出现上万次的写数据请求,硬盘 IO 就已经无法承受了。对于普通的 BBS 网站,往往也会存在高并发的写数据请求。

(2)Huge Storage—— 对海量数据高效存储与访问需求
类似于 Facebook、Friendfeed 这样的 SNS 网站,每天会产生大量的用户动态信息。如 Friendfeed, 一个月就会产生不少于 2.5 亿条用户动态信息,对于关系型数据库来说,在一个包含 2.5 亿条记录的表中执行 SQL 查询,查询效率是非常低的。

(3)High Scalability && High Availability—— 对数据库高可扩展性与高可
用性需求在 Web 架构中,数据库是最难进行横向扩展的。当应用系统的用户量与访问量与日俱增时,数据库是没办法像 Web 服务一样,简单地通过添加硬件和服务器节点来扩展其性能和负载能力的。尤其对于一些需要 24 小时对外提供服务的网站来说,数据库的升级与扩展往往伴随着停机维护与数据迁移,其工作量是非常庞大的。

2.1redis简介

    redis(RemoteDictionaryServer,远程字典型)是一个开源的、使用 C 语言编写的 NoSQL 数据库。Redis 基于内存运行并支持持久化,采用 key-value(键值对)的存储形式,是目前分布式架构中不可或缺的一环。

    Redis 服务器程序是单进程模型,也就是在一台服务器上可以同时启动多个 Redis 进程,而 Redis 的实际处理速度则是完全依靠于主进程的执行效率。若在服务器上只运行一个 Redis 进程,当多个客户端同时访问时,服务器的处理能力是会有一定程度的下降;若在同一台服务器上开启多个 Redis 进程,Redis 在提高并发处理能力的同时会给服务器的 CPU 造成很大压力。即:在实际生产环境中,需要根据实际的需求来决定开启多少个 Redis 进程。若对高并发要求更高一些,可能会考虑在同一台服务器上开启多个进程。若 CPU 资源比较紧张,采用单进程即可。

Redis 具有以下几个优点:

     具有极高的数据读写速度,数据读取的速度最高可达到 110000 次 /s,数据写入速度最高可达到 81000 次 /s。

    支持丰富的数据类型,不仅仅支持简单的 key-value 类型的数据,还支持 Strings, Lists, Hashes, Sets 及 Ordered Sets 等数据类型操作。

    支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。

    原子性,Redis 所有操作都是原子性的。

    支持数据备份,即 master-salve 模式的数据备份。

  Redis 作为基于内存运行的数据库,缓存是其最常应用的场景之一。除此之外,Redis 常见应用场景还包括获取最新 N 个数据的操作、排行榜类应用、计数器应用、存储关系、实时分析系统、日志记录。

 2.1.1redis安装部署

    通常情况下,在 Linux 系统中进行源码编译安装,需要先执行./configure 进行环境检查与配置,从而生成 Makefile 文件,再执行 make && make install 命令进行编译安装。而 Redis 源码包中直接提供了 Makefile 文件,所以在解压完软件包后,可直接进入解压后的软件包目录,执行 make 与 make install 命令进行安装。

[root@localhost src]# dnf -y install tar gcc make zlib-devel
[root@localhost src]# tar xvzf redis-4.0.9.tar.gz
[root@localhost src]# cd redis-4.0.9/
[root@localhost redis-4.0.9]# make
[root@localhost redis-4.0.9]# make PREFIX=/usr/local/redis install
[root@localhost ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/

   make install 只是安装了二进制文件到系统中,并没有启动脚本和配置文件。软件包中默认提供了一个 install_server.sh 脚本文件,通过该脚本文件可以设置 Redis 服务所需要的相关配置文件。当脚本运行完毕,Redis 服务就已经启动,默认侦听端口为 6379。

[root@localhost redis-4.0.9]# cd utils/
[root@localhost utils]# ./install_server.sh
Welcome to the redis service installer
This script will help you easily set up a running redis server
Please select the redis port for this instance: [6379]
Selecting default: 6379
Please select the redis config file name [/etc/redis/6379.conf]
Selected default - /etc/redis/6379.conf
Please select the redis log file name [/var/log/redis_6379.log]
Selected default - /var/log/redis_6379.log
Please select the data directory for this instance [/var/lib/redis/6379]
Selected default - /var/lib/redis/6379
Please select the redis executable path [] /usr/local/redis/bin/redis -server
// 需要手动输入
Selected config:
Port : 6379
Config file : /etc/redis/6379.conf // 配置文件路径
Log file : /var/log/redis_6379.log // 日志文件路径
Data dir : /var/lib/redis/6379 // 数据文件路径
Executable : /usr/local/redis/bin/redis-server // 可执行文件路径
Cli Executable : /usr/local/redis/bin/redis-cli // 客户端命令行工具
Is this ok? Then press ENTER to go on or Ctrl-C to abort.
Copied /tmp/6379.conf => /etc/init.d/redis_6379
Installing service...
Successfully added to chkconfig!
Successfully added to runlevels 345!
Starting Redis server...
Installation successful!
[root@localhost utils]# netstat -lnupt | grep redis
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 5494/redis-server 1

2.1.2配置参数

    Redis 主配置文件为 /etc/redis/6379.conf,由注释行与设置行两部分组成。与大多数 Linux 配置文件一样,注释性的文字以 “#” 开始,包含了对相关配置内容进行的说明和解释。除了注释行与空行以外的内容即为设置行。可根据生产环境的需求调整相关参数,如下:

[root@localhost ~]# vi /etc/redis/6379.conf
bind 127.0.0.1 192.168.10.161 // 监听的主机地址
port 6379 // 端口
daemonize yes // 启用守护进程
pidfile /var/run/redis_6379.pid// 指定 PID 文件
loglevel notice // 日志级别
logfile /var/log/redis_6379.log// 指定日志文件
[root@localhost~]#/etc/init.d/redis_6379 restart
Stopping ...
Redis stopped
Starting Redis server...
参数作用
timeout 300当客户端闲置多长时间后关闭连接,如果指定为 0,表示关闭该功能
dbfilename dump.rdb指定本地数据库文件名,默认值为dump.rdb
dir /var/lib/redis/6379指定本地数据库存放目录
maxclients 10000设置同一时间最大客户端连接数,默认 10000。Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数,如果设置maxclients 0表示不限制。当客户端连接数达到限制时,Redis 会关闭新的连接并给客户端返回max number of clients reached错误信息
rdbcompression yes指定存储至本地数据库时是否压缩数据,默认为yes,Redis 采用 LZF 压缩。如果为了节省 CPU 时间,可以关闭该选项,但会导致数据库文件变的巨大
slaveof <masterip> <masterport>当本机为从服务器时,设置主服务器的 IP 地址及端口,在 Redis 启动后,从服务器会自动向主服务器进行数据同步
masterauth <master-password>当主服务器设置了连接密码,从服务器连主服务器的密码
requirepass foobared设置 Redis 连接密码,如果配置了连接密码,客户端在连接 Redis 时需要通过AUTH <password>命令提供密码,默认关闭
maxmemory <bytes>指定 Redis 最大内存限制,Redis 在启动时会把数据加载到内存中,达到最大内存后,Redis 会先尝试清除已到期或即将到期的 Key,当此方法处理后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis 新的 VM 机制,会把 Key 存放内存,Value 存放在 swap 分区
appendonly no指定是否在每次更新操作后进行日志记录,Redis 在默认情况下是异步地把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 Redis 本身同步数据文件是按上面 save 条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认值为no
appendfilename appendonly.aof指定更新日志文件名,默认为appendonly.aof
appendfsync everysec指定更新日志条件,共有 3 个可选值:
no:表示等操作系统进行数据缓存同步到磁盘(快)
always:表示每次更新操作后手动调用fsync将数据写到磁盘(慢,安全)
everysec:表示每秒同步一次(默认,推荐)
activerehashing yes指定是否激活重置哈希,默认为开启
include /path/to/local.conf指定包含其它的配置文件,可以在同一主机上多个 Redis 实例之间使用同一份配置文件,同时各个实例又拥有自己的特定配置文件

 3.1redis命令工具

    Redis 软件提供了多个命令工具。安装 Redis 服务时,所包含的软件工具会同时被安装到系统中,在系统中可以直接使用。这些命令工具的作用分别如下所示。

   redis-server:用于启动 Redis 的工具;

   redis-benchmark:用于检测 Redis 在本机的运行效率;

   redis-check-aof:修复 AOF 持久化文件;

   redis-check-rdb:修复 RDB 持久化文件;

   redis-cli:Redis 命令行工具。

3.1.1redis-cli命令行工具

      Redis 数据库系统也是一个典型的 C/S(客户端 / 服务器端)架构的应用,要访问 Redis 数据库需要使用专门的客户端软件。Redis 服务的客户端软件就是其自带的 redis-cli 命令行工具。使用 redis-cli 连接指定数据库,连接成功后会进入提示符为 “远程主机 IP 地址:端口号>” 的数据库操作环境,例如 “127.0.0.1:6379>”。用户可以输入各种操作语句对数据库进行管理。如执行 ping 命令可以检测 Redis 服务是否启动。

[root@localhost ~]# /usr/local/redis/bin/redis-cli //连接本机 Redis 数据库
127.0.0.1:6379>ping //检测 redis 服务是否启动
PONG
127.0.0.1:6379>

     在进行数据库连接操作时,可以通过选项来指定远程主机上的 Redis 数据库。命令语法为 redis-cli -h host -p port -a password,其中 -h 指定远程主机、-p 指定 Redis 服务的端口号、-a 指定密码。若不添加任何选项表示,连接本机上的 Redis 数据库;若未设置数据库密码可以省略 -a 选项。例如执行以下命令可连接到主机为 192.168.10.161,端口为 6379 的 Redis 数据库,并查看 Redis 服务的统计信息。若要退出数据库操作环境,执行 “exit” 或 “quit” 命令即可返还原来的 Shell 环境。

[root@localhost ~]#redis-cli -h 192.168.10.161 -p 6379
192.168.10.161:6379>info
# Server
redis_version:4.0.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:7f55f2c1a630cbe5
……
//省略部分内容
192.168.10.161:6379>exit
[root@localhost ~]#

    在数据库操作环境中,使用 help 命令可以获取命令类型的帮助。有三种获取命令帮助的方式。

   help @<group>:获取<group>中的命令列表;

   help <command>:获取某个命令的帮助;

   help <tab>:获取可能帮助的主题列表。

[root@localhost ~]#redis-cli
127.0.0.1:6379>help @list //查看所有与 List 数据类型的相关命令
BLPOP key [key ...] timeout
summary: Remove and get the first element in a list, or block until one
is available
since: 2.0.0
BRPOP key [key ...] timeout
summary: Remove and get the last element in a list, or block until one
is available
since: 2.0.0
BRPOPLPUSH source destination timeout
……
//省略部分内容
127.0.0.1:6379>help set //查看 set 命令的命令帮助
SET key value [EX seconds] [PX milliseconds] [NX|XX]
summary: Set the string value of a key
since: 1.0.0
group: string

3.1.2redis-benchmark测试工具

   redis-benchmark 是官方自带的 Redis 性能测试工具,可以有效的测试 Redis 服务的性能。基本的测试语法为 redis-benchmark [option] [option value]。常用选项如下所示。

-h:指定服务器主机名;

-p:指定服务器端口;

-s:指定服务器 socket;

-c:指定并发连接数;

-n:指定请求数;

-d:以字节的形式指定 SET/GET 值的数据大小;

-k:1=keep alive 0=reconnect;

-r:SET/GET/INCR 使用随机 key,SADD 使用随机值;

-P:通过管道传输<numreq>请求;

-q:强制退出 redis。仅显示 query/sec 值;

--csv:以 CSV 格式输出;

-l:生成循环,永久执行测试;

-t:仅运行以逗号分隔的测试命令列表;

-I:Idle 模式。仅打开 N 个 idle 连接并等待。

   结合上述选项,可以针对某台 Redis 服务器进行性能检测,如执行 redis-benchmark -h 192.168.10.161 -p 6379 -c 100 -n 100000 命令即可向 IP 地址为 192.168.10.161、端口为 6379 的 Redis 服务器发送 100 个并发连接与 100000 个请求测试性能。

[root@localhost ~]# redis-benchmark -h 192.168.10.161 -p 6379 -c 100 -n 100000
…… //省略部分内容
8225.04 requests per second
====== MSET (10 keys) ======
100000 requests completed in 1.57 seconds
100 parallel clients
3 bytes payload
keep alive: 1
24.75% <= 1 milliseconds
99.02% <= 2 milliseconds
99.57% <= 3 milliseconds
99.90% <= 4 milliseconds
99.98% <= 5 milliseconds
100.00% <= 5 milliseconds
63653.72 requests per second

   执行 redis-benchmark -h 192.168.10.161 -p 6379 -q -d 100 命令的作用是测试存取大小为 100 字节的数据包的性能。

[root@localhost ~]#redis-benchmark -h 192.168.10.161 -p 6379 -q -d 100
PING_INLINE: 88261.25 requests per second
PING_BULK: 90991.81 requests per second
SET: 83612.04 requests per second
GET: 84961.77 requests per second
INCR: 83682.01 requests per second
LPUSH: 76745.97 requests per second
RPUSH: 78247.26 requests per second
LPOP: 77519.38 requests per second
RPOP: 79681.27 requests per second
SADD: 83125.52 requests per second
SPOP: 85543.20 requests per second
LPUSH (needed to benchmark LRANGE): 78864.35 requests per second
LRANGE_100 (first 100 elements): 30931.02 requests per second
LRANGE_300 (first 300 elements): 9437.52 requests per second
LRANGE_500 (first 450 elements): 5541.39 requests per second
LRANGE_600 (first 600 elements): 3824.38 requests per second
MSET (10 keys): 64184.86 requests per second

   还可以测试某些操作的性能,例如执行 redis-benchmark -t set,lpush -n 100000 -q 命令的作用是测试本机上 Redis 服务在进行 set 与 lpush 操作时的性能。

[root@localhost ~]#redis-benchmark -t set,lpush -n 100000 -q
SET: 85763.29 requests per second
LPUSH: 86580.09 requests per second

4.1redis数据库常用命令

    前面提到 Redis 数据库采用 key-value(键值对)的数据存储形式。所使用的命令是 set 与 get 命令。

set:存放数据,基本的命令格式为 set key value。

get:获取数据,基本的命令格式为 get key。

   在 Redis 的命令行模式下执行”set teacher zhanglong”,表示在当前数据库下存放一个 key 为 teacher,value 为 zhanglong 的数据,而执行 “getteacher“命令即可查看刚才存放的数据。

4.1.1key相关命令

(1)keys

    使用 keys 命令可以取符合规则的键值列表,通常情况可以结合 *、? 等选项来使用。

127.0.0.1:6379>set k1 1
OK
127.0.0.1:6379>set k2 2
OK
127.0.0.1:6379>set k3 3
OK
127.0.0.1:6379>set v1 4
OK
127.0.0.1:6379>set v5 5
OK
127.0.0.1:6379>KEYS * //查看当前数据库中所有键
1) "teacher"
2) "k1"
3) "k2"
4) "k3"
5) "v1"
6) "v5"
127.0.0.1:6379>set v22 5
OK
127.0.0.1:6379>KEYS v* //查看当前数据库中以 v 开头的数据
1) "v1"
2) "v5"
3) "v22"
127.0.0.1:6379>KEYS v?
//查看当前数据库中以 v 开头后面包含任意一位的数据
1) "v1"
2) "v5"
127.0.0.1:6379>KEYS v??
//查看当前数据库中以 v 开头后面包含任意两位的数据
1) "v22"

(2)exists

127.0.0.1:6379>exists teacher
//判断 teacher 键是否存在
(integer) 1
//表示 teacher 键是存在
127.0.0.1:6379>exists tea
(integer) 0
//表示 tea 键不存在

(3)del

127.0.0.1:6379>keys *
1) "teacher"
2) "v1"
3) "v22"
4) "k3"
5) "k1"
6) "k2"
7) "v5"
127.0.0.1:6379> del v5
(integer) 1
127.0.0.1:6379>get v5
(nil)

(4)type

    使用type命令可以获取key对应的value值类型。

127.0.0.1:6379>type k1
String

(5)rename
     rename 命令是对已有 key 进行重命名,其命令格式为:rename 源 key 目标 key。使用 rename 命令进行重命名时,无论目标 key 是否存在都进行重命名,且源 key 的值会覆盖目标 key 的值。在实际使用过程中,建议先用 exists 命令查看目标 key 是否存在,然后再决定是否执行 rename 命令,以避免覆盖重要数据。

127.0.0.1:6379>keys v*
1) "v1"
2) "v22"
127.0.0.1:6379>rename v22 v2
OK
127.0.0.1:6379>keys v*
1) "v1"
2) "v2"
127.0.0.1:6379>get v1
"4"
127.0.0.1:6379>get v2
"5"
127.0.0.1:6379>rename v1 v2
OK
127.0.0.1:6379>get v1
(nil)
127.0.0.1:6379>get v2
"4"

(6)renamenx
    renamenx 命令的作用是对已有 key 进行重命名,并检测新名是否存在。其命令格式与 rename 的命令格式除命令关键字不同外基本相同:renamenx 源 key 目标 key。使用 renamenx 命令进行重命名时,如果目标 key 存在则不进行重命名。

127.0.0.1:6379>keys *
1) "teacher"
2) "k3"
3) "k1"
4) "k2"
5) "v2"
127.0.0.1:6379>get teacher
"zhanglong"
127.0.0.1:6379>get v2
"4"
127.0.0.1:6379>renamenx v2 teacher
(integer) 0
127.0.0.1:6379>keys *
1) "teacher"
2) "k3"
3) "k1"
4) "k2"
5) "v2"
127.0.0.1:6379>get teacher
"zhanglong"
127.0.0.1:6379>get v2
"4"

(7)dbsize

    dbsize 命令的作用是查看当前数据库中 key 的数目。

127.0.0.1:6379> dbsize
(integer) 5

4.1.2多数据库常用命令

(1)多数据库间切换
   Redis 支持多数据库,Redis 在没有任何改动的情况下默认包含 16 个数据库,数据库名称是用数字 0 - 15 来依次命名的。使用 select 命令可以进行 Redis 的多数据库之间的切换,命令格式为 selectindex,其中 index 表示数据库的序号。而使用 redis - cli 连接 Redis 数据库后,默认使用的是序号为 0 的数据库。

   使用 select 命令切换数据库后,会在前端的提示符中显示当前所在的数据库序号如 “127.0.0.1:6379 [10]>” 表示当前使用的是序号为 10 的数据库。若当前使用的数据库是序号为 0 的数据库,提示符中则不显示序号,如 “127.0.0.1:6379>” 表示当前使用的是序号为 0 的数据库。

127.0.0.1:6379>select 10 // 切换至序号为 10 的数据库
OK
127.0.0.1:6379 [10]>select 15 // 切换至序号为 15 的数据库
OK
127.0.0.1:6379 [15]>select 0 // 切换至序号为 0 的数据库
OK
127.0.0.1:6379>

(2)多数据库间移动数据


127.0.0.1:6379>set k1 100
OK
127.0.0.1:6379>get k1
"100"
127.0.0.1:6379>select 1
OK
127.0.0.1:6379[1]>get k1
(nil)

(3)清除数据库内数据

    Redis 数据库的整库数据删除主要分为两个部分:清空当前数据库数据,使用 FLUSHDB 命令实现;清空所有数据库的数据,使用 FLUSHALL 命令实现。但是,数据清空操作比较危险,生产环境下一般不建议使用。

5.1redis持久化

   Redis 是一种高级 key-value 数据库。它跟 Memcached 类似,不过数据可以持久化,而且支持的数据类型很丰富,有字符串、列表、集合和有序集合。支持在服务器端计算集合 (difference) 等,还支持多种排序功能。所以 Redis 也可以被看成是一个数据结构服务器。

5.1.1RDB和AOF的区别

    RDB 持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是 fork 一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储,如图 3.1 所示。

 

    AOF 持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。如图 3.2所示。 

5.1.2RDB和AOF的优缺点

 (1)RDB 优点

  • 一旦采用该方式,那么整个 Redis 数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,计划每个小时归档一次最近 24 小时的数据,同时还要每天归档一次最近 30 天的数据。通过这样的备份策略,一旦系统出现灾难性故障,可以非常容易地进行恢复。

  • 对于灾难恢复而言,RDB 是非常不错的选择。可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

  • 性能最大化,对于 Redis 的服务进程而言,在开始持久化时,它唯一需要做的只是 fork 出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行 I0 操作了。

  • 相比于 AOF 机制,如果数据集很大,RDB 的启动效率会更高。

(2)RDB 缺点

  • 如果想保证数据的高可用性,即最大限度的避免数据丢失,那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。

  • 由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的,因此当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是 1 秒钟。

(1)AOF 的优点

  • AOF 机制可以带来更高的数据安全性,即数据持久性。Redis 中提供了 3 种同步策略,即每秒同步、每次修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,弊端是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每次修改同步,可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中,这种方式在效率上是最低的。

  • 由于该机制对日志文件的写入操作采用的是 append 模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题,那么在 Redis 下一次启动之前,可以通过 redis - check - aof 工具来解决数据一致性的问题。

  • 如果日志过大,Redis 可以自动启用 rewrite 机制。即 Redis 以 append 模式不断地将修改数据写入到老的磁盘文件中,同时 Redis 还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行 rewrite 切换时可以更好的保证数据安全性。

  • AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,也可以通过该文件完成数据的重建。

(2)AOF 的缺点

  • 对于相同数量的数据集而言,AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

  • 根据同步策略的不同,AOF 在运行效率上往往会慢于 RDB。每秒同步策略的效率是比较高的,同步禁用策略的效率和 RDB 一样高效。

      二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(AOF),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行 save 的时候,再做备份(RDB)。

5.1.3redis持久化配置

     Redis 会将数据集的快照 dump 到 dump.rdb 文件中。此外,也可以通过配置文件来修改 Redis 服务器 dump 快照的频率。在打开 6379.conf 文件之后,搜索 save,可以看到如下所示配置信息。

  • save 900 1:在 900 秒 (15 分钟) 内,如果至少有 1 个 key 发生变化,则 dump 内存快照。

  • save 300 10:在 300 秒 (5 分钟) 内,如果至少有 10 个 key 发生变化,则 dump 内存快照。

  • save 60 10000:在 60 秒 (1 分钟) 内,如果至少有 10000 个 key 发生变化,则 dump 内存快照。

5.1.4AOF重写

    Redis 会不断地将被执行的命令记录到 AOF 文件里面,所以随着 Redis 不断运行,AOF 文件的体积也会不断增长。在极端情况下,体积不断增大的 AOF 文件甚至可能会用完硬盘的所有可用空间。Redis 在重启之后需要通过重新执行 AOF 文件记录的所有写命令来还原数据集,所以如果 AOF 文件的体积非常大,那么还原操作执行的时间就可能会非常长。

   为了解决 AOF 文件体积不断增大的问题,用户可以向 Redis 发送 BGREWRITEAOF 命令。BGREWRITEAOF 命令会通过移除 AOF 文件中的冗余命令来重写(rewrite)AOF 文件,使 AOF 文件的体积尽可能地变小。

   BGREWRITEAOF 的工作原理和 BGSAVE 创建快照的工作原理非常相似:Redis 会创建一个子进程,然后由子进程负责对 AOF 文件进行重写。因为 AOF 文件重写也需要用到子进程,所以快照持久化因为创建子进程而导致的性能问题和内存占用问题,在 AOF 持久化中也同样存在。

   与快照持久化通过设置 save 选项来自动执行 BGSAVE 一样,AOF 持久化也可以通过设置 auto - aof - rewrite - percentage 选项和 auto - aof - rewrite - min - size 选项来自动执行 BGREWRITEAOF。

   举个例子,假设用户对 Redis 设置了配置选项 auto - aof - rewrite - percentage 100 和 auto - aof - rewrite - min - size 64mb,并且启动了 AOF 持久化,那么当 AOF 文件的体积大于 64MB,并且 AOF 文件的体积比上一次重写之后的体积大了至少一倍(100%)的时候,Redis 将执行 BGREWRITEAOF 命令。如果 AOF 重写执行的过于频繁的话,用户可以考虑将 auto - aof - rewrite - percentage 选项的值设置为 100 以上,这种做法可以让 Redis 在 AOF 文件的体积变得更大之后才执行重写操作,不过也会让 Redis 在启动时还原数据集所需的时间变得更长。

5.1.5性能管理

    Redis 性能管理需要关注的数据指标有内存使用率、内存碎片率、回收 key 等。这其中有些数据可以通过进入 info 命令进行查看。需要查看某一项的值就后面跟具体参数,执行以下命令查看 Redis 使用内存值。

192.168.9.236:7001> info memory
Memory
used_memory:1789108864
used_memory_human:1.67G
used_memory_rss:1834365054
used_memory_rss_human:1.71G
used_memory_peak:1657473880
used_memory_peak_human:1.54G
used_memory_peak_perc:58.41%
used_memory_overhead:62038390
used_memory_startup:191424
used_memory_dataset:1727070474
used_memory_dataset_perc:96.53%
allocator_allocated:1789471792
allocator_active:1801850880
allocator_resident:1835344200
total_system_memory:10095328256
total_system_memory_human:9.40G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:17179869184
maxmemory_human:16.00G
maxmemory_policy:allkeys-lru
allocator_frag_ratio:1.01
allocator_frag_bytes:12379088
allocator_rss_ratio:1.03
allocator_rss_bytes:49356800
rss_overhead_ratio:0.99
rss_overhead_bytes:-19152896
mem_fragmentation_ratio:1.03
mem_fragmentation_bytes:45321664
mem_not_counted_for_evict:0
mem_replication_backlog:536870912
mem_clients_slaves:10922
mem_clients_normal:218914
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

    info stats 信息中的 evicted_keys 字段显示的是因为 maxmemory 限制导致 key 被回收删除的数量。当 Redis 由于内存压力需要回收一个 key 时,Redis 首先考虑的不是回收最旧的数据,而是在最近最少使用的 key 或即将过期的 key 中随机选择一个 key,从数据集中删除。

192.168.9.236:7001> info stats
Stats
total_connections_received:473156108
total_commands_processed:4180290178
instantaneous_ops_per_sec:375
total_net_input_bytes:14676967575477
total_net_output_bytes:102221322391862
instantaneous_input_kbps:1465.97
instantaneous_output_kbps:7011.15
rejected_connections:0
sync_full:1
sync_partial_ok:0
sync_partial_err:1
expired_keys:34158591
expired_stale_perc:0.40
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:3089647498
keyspace_misses:94699798
pubsub_channels:3
pubsub_patterns:2
latest_fork_usec:51400
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.pswp.cn/pingmian/86480.shtml
繁体地址,请注明出处:http://hk.pswp.cn/pingmian/86480.shtml
英文地址,请注明出处:http://en.pswp.cn/pingmian/86480.shtml

如若内容造成侵权/违法违规/事实不符,请联系英文站点网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

走近科学IT版:FreeBSD系统下ThinkPad键盘突然按不出b、n、/和空格键了!

走近科学IT版&#xff1a;FreeBSD系统下ThinkPad键盘突然按不出b和n键了&#xff01; 很慌&#xff0c;以为键盘坏了&#xff0c;在控制台无法按出b和n&#xff0c;但是在浏览器里&#xff0c;可以按出来。 重启机器&#xff0c;结果在浏览器里也按不出来了.... 按Ctrl空格&a…

聚铭网络入选嘶吼《中国网络安全细分领域产品名录》“云平台安全管理”与“态势感知”双领域TOP10

近日&#xff0c;在嘶吼安全产业研究院发布的《中国网络安全细分领域产品名录》中&#xff0c;聚铭网络凭借其核心产品——聚铭云端安全管家与聚铭安全态势感知与管控系统&#xff0c;分别入选“云平台安全管理”与“态势感知”两大关键细分领域TOP10榜单&#xff0c;充分展现了…

DEYOLO 全面复现,将双增强跨模态目标检测网络 DEYOLO 融合到 YOLOFuse 框架

模型架构模态精度 P召回率 RmAP50mAP50-95模型大小(MB)计算量(GFLOPs)yolov8n (baseline)RGB0.8880.8290.8910.5006.28.1yolo-fuse-中期特征融合RGBIR0.9510.8810.9470.6012.613.2yolo-fuse-早期特征融合RGBIR0.9500.8960.9550.6235.26.7yolo-fuse-决策级融合RGBIR0.9560.9050.…

python基于Django+mysql实现的图书管理系统【完整源码+数据库】

摘要 随着信息技术与教育现代化的深度融合&#xff0c;图书管理系统的智能化与自动化成为提升资源利用效率的关键需求。本文基于Python语言&#xff0c;采用Django框架与MySQL数据库设计并实现了一套功能完备的图书管理系统&#xff0c;旨在通过信息化手段优化图书借阅流程、强…

论软件设计方法及其应用

20250427-作 题目 软件设计&#xff08;Software Design&#xff0c;SD)根据软件需求规格说明书设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及程序流程等&#xff0c;形成软件的具体设计方案。软件设计把许多事物和问题按不同的层次和角度进行抽象&…

QT 自定义ComboBox,实现下拉框文本颜色设置

最近在做项目中遇到需求&#xff0c;在下拉框中&#xff0c;文本需要设置不同的颜色&#xff0c;遂网上了解了一番后&#xff0c;得出以下代码&#xff0c;可以完美实现效果&#xff0c;现分享出来&#xff01; 1.实现效果 2.自定义类 colorcombobox.h #ifndef COLORCOMBOBOX…

【时间戳】

在编程竞赛和高效数据处理场景中&#xff0c;时间戳技巧是一种极其高效的标记方法&#xff0c;常用于避免频繁清空数组或 map&#xff0c;提高算法运行效率。本文将从定义、应用场景、模板代码、技巧细节等方面系统整理时间戳的使用方式。 一、时间戳技巧是什么&#xff1f; 时…

json.decoder.JSONDecodeError: Unexpected UTF-8 BOM (decode using utf-8-sig)

有一次爬虫遇到了json的字符串响应对象 然后转为json对象 报这个错误 raise JSONDecodeError("Unexpected UTF-8 BOM (decode using utf-8-sig)", json.decoder.JSONDecodeError: Unexpected UTF-8 BOM (decode using utf-8-sig): line 1 column 1 (char 0) 意思是叫…

python训练day43 复习日

import torch import torch.nn as nn import torch.optim as optim from torchvision import datasets, transforms from torch.utils.data import DataLoader, random_split import matplotlib.pyplot as plt import numpy as np# 设置中文字体支持&#xff0c;避免绘图时中文…

C++11 lambda

前言 在Cpp11以前&#xff0c;为了把函数当作对象调用&#xff0c;可以使用C中的函数指针类型&#xff0c;也可以使用Cpp98的仿函数。 但二者都不是很好用&#xff0c;函数指针 return_type (*name)(parameters)的长相就令人望而却步&#xff0c;仿函数将一个函数重载为一个类…

【国产化-K8s】混合架构的 K8s + KubeSphere 部署指南

本文由 KubeSphere 社区贡献者 天行1st 编写。本文为作者实践总结。本文记录了在信创环境中基于混合架构&#xff08;x86 与 ARM64&#xff09;部署 Kubernetes 和 KubeSphere 的实践过程&#xff0c;覆盖多种国产 CPU 和操作系统&#xff0c;具有一定的参考价值。 环境涉及软…

利用python实现NBA数据可视化

大家好&#xff0c;今天我们利用python爬取NBA球星每年的比赛数据并进行可视化展示。主要用到三个模块&#xff1a;xpath、matplotlib。其中xpth负责爬取网站上的信息。Matplotlib是Python开发人员常用的Python绘图库&#xff0c;可以用来绘制各种2D图形&#xff0c;具有绘图质…

基于 SpringBoot+JSP 的医疗预约与诊断系统设计与实现

摘要 本研究针对传统医疗预约与诊断流程中存在的效率低下、信息不透明、患者等待时间长等问题&#xff0c;设计并实现了一个基于 SpringBootJSP 的医疗预约与诊断系统。系统采用 B/S 架构&#xff0c;整合了用户管理、科室管理、医生排班、预约挂号、在线问诊、检查检验、诊断…

2025.6.27总结

最近工作又开始内耗了&#xff0c;一位同事的转岗直接让我破防了&#xff0c;明明他工作干得很不错&#xff0c;会得又多&#xff0c;性格又好&#xff0c;我还经常请教他业务上的问题。我和他的关系并不算太好&#xff0c;但他加入其他部门&#xff0c;竟然让我有些不舍&#…

详解HashMap底层原理

核心数据结构&#xff1a;数组 链表 / 红黑树 HashMap 的底层核心是一个 Node<K,V>[] table 数组&#xff08;通常称为 桶数组 或 哈希桶数组&#xff09;。这个数组的每个元素称为一个 桶。 Node<K,V> (链表节点)&#xff1a; 这是存储键值对的基本单位&#xf…

历史项目依赖库Bugfix技巧-类覆盖

在项目维护过程中&#xff0c;我们可能会遇到历史项目依赖的第三方库出现BUG而需要修复的情况&#xff0c;而这些第三方库可能来源于公司自主开发或开源项目&#xff0c;但由于各种原因&#xff0c;这些库可能已无人维护。 此时&#xff0c;解决这个问题有三个办法 1、基于源…

多模态大型语言模型最新综述

多模态大型语言模型&#xff08;Multimodal Large Language Models&#xff0c;MLLMs&#xff09;已迅速发展&#xff0c;超越了文本生成的范畴&#xff0c;如今能够覆盖图像、音乐、视频、人类动作以及三维物体等多种输出模态。它们通过在统一架构下将语言与其他感知模态整合&…

使用ASIO的协程实现高并发服务器

使用ASIO的协程实现高并发服务器 在 C 网络编程领域&#xff0c;Asio 库提供了两种主要的异步编程范式&#xff1a;传统的回调模式和基于协程的现代模式&#xff0c;传统的回调模式大家都很清楚&#xff0c;这里不多做介绍&#xff0c;本文主要介绍基于协程的模式&#xff0c;…

OpenCV——轮廓检测

轮廓检测 一、轮廓检测二、轮廓的层级三、轮廓的特征3.1、轮廓面积3.2、轮廓周长3.3、边界矩形3.4、最小外接圆3.5、近似轮廓3.6、凸包 一、轮廓检测 轮廓可以简单的描述为具有相同颜色或灰度的连续点连在一起的一条曲线&#xff0c;轮廓通畅会显示出图像中物体的形状。关于轮…

高等概率论题解-心得笔记【15】

文章目录 拓扑参考文献 拓扑 参考文献 《测度论基础与高等概率论》