内容纲要
一、postgresql架构与原理。
主要结构如下：
1、存储结构
PG数据存储结构分为：逻辑存储结构和物理存储存储。其中：逻辑存储结构是内部的组织和管理数据的方式；物理存储结构是操作系统中组织和管理数据的方式。
1.1 逻辑存储结构
数据库集簇是数据库对象的集合。
在关系数据库理论中，数据库对象是用于存储或引用数据的数据结构。
表就是一个例子，还有索引、序列、视图、函数等这些对象。
在PostgreSQL中，数据库本身也是数据库对象，并且在逻辑上彼此分离。
除数据库之外的其他数据库对象（例如表、索引等）都属于它们各自的数据库，虽然它们隶属于同一个数据库集簇，但也无法直接从集簇中的一个数据库访问集簇中的另一个数据库对象。
数据库本身也是数据库对象，一个数据库集簇可以包含多个Database、多个User、每个Database以及Database中的所有对象都有它们的所有者：User。
1）创建一个Database时，会为这个Database创建一个名为public的默认Schema，每个Database可以有多个Schema。
2）在这个数据库中创建其他数据库对象时，如果没有指定Schema，都会在public这个Schema中。
3）Schema可以理解为一个数据库中的命名空间，在数据库中创建的所有对象都在Schema中创建。
4）一个用户可以从同一个客户端连接中访问不同的Schema。
5）不同的Schema中可以有多个相同的名称的Table、Index、View、Sequence、Function等数据库对象。
1.2 物理存储结构
1）数据库的文件默认保存在initdb时创建的数据目录中。
2）在数据目录中有很多类型、功能不同的目录和文件。
3）除了数据文件之外，还有参数文件、控制文件、数据库运行日志及预写日志等。
1.2.1 数据目录
数据库初始化创建的目录下还会生成如下一些子目录
base #默认表空间的目录,每个数据库都对应一个base目录下的子目录,每个表和索引对应一个独立文件
global #这个目录对应pg_global表空间,存放实例中的共享对象
pg_clog #存储事务提交状态数据
pg_bba.conf #数据库访问控制文件
pg_log #数据库系统日志目录，在查询一些系统错误时就可查看此目录下日志文件。(根据配置定义,可能没
有这个目录)
pg_xact #提交日志commit log的目录,pg 9之前叫pg_clog
pg_multixact #共享行锁的事务状态数据
pg_notify #异步消息相关的状态数据pg_serial #串行隔离级别的事务状态数据
pg_snapshots #存储执行了事务snapshot导出的状态数据pg_stat_tmp #统计信息的临时文件
pg_subtrans #子事务状态数据
pg_stat #统计信息的存储目录。关闭服务时,将pg_stat_tmp目录中的内容移动至此目录实现保存
pg_stat_tmp #统计信息的临时存储目录。开启数据库时存放统计信息
pg_tblsp #存储了指向各个用户自建表空间实际目录的链接文件
pg_twophase#使用两阶段提交功能时分布式事务的存储目录
pg_wal #WAL日志的目录,早期版一本目录为pg_xlog
PG_VERSION #数据库版本
postmaster.opts #记录数据库启动时的命令行选项
postmaster.pid #数据库启动的主进程信息文件，包括PID，SPGDATA目录,数据库启动时间，监听端口，
socket文件路径，临听地址,共享内存的地址信息(ipsc可查看),主进程状态二、基于流复制完成postgresql的高可用。
主库：10.0.0.136 从库：10.0.0.138
主库上配置：
创建复制用户：create user repluser with replication password '123456';
在pg_hba.conf中添加：host replication all 0.0.0.0/0 md5 #允许任何用户从任何地址使用密码验证复制数据
#重启服务
systemctl restart pgsql.service
从节点配置：
systemctl stop postgresql.service #停止服务
rm -rf /pgsql/data/* #删除数据文件
rm -rf /archive/* #删除归档日志文件
#全量备份
pg_basebackup -D /pgsql/backup/ -Ft -Pv -Upostgres -h 10.0.0.136 -p 5432 -R
#恢复数据文件
tar xf /pgsql/backup/base.tar -C /pgsql/data/
tar xf /pgsql/backup/pg_wal.tar -C /archive/
#修改配置文件
vim /pgsql/data/postgres.conf
primary_conninfo = 'host=10.0.0.136 port=5432 user=repluser password=123456'
restore_command = 'cp /archive/%f %p'
#启动服务
systemctl start postgresql.service
结果：
主库状态：
pg_controldata
pg_control version number: 1300
Catalog version number: 202107181
Database system identifier: 7150164135374356869
Database cluster state: in production
pg_control last modified: Wed 19 Oct 2022 10:55:49 PM CST
Latest checkpoint location: 0/2D000228
Latest checkpoint's REDO location: 0/2D0001F0
Latest checkpoint's REDO WAL file: 00000002000000000000002D
从库状态：
pg_controldata
pg_control version number: 1300
Catalog version number: 202107181
Database system identifier: 7150164135374356869
Database cluster state: in archive recovery
pg_control last modified: Thu 20 Oct 2022 06:57:53 AM CST
Latest checkpoint location: 0/2D000228
Latest checkpoint's REDO location: 0/2D0001F0
Latest checkpoint's REDO WAL file: 00000002000000000000002D三、实现postgresql的时间点还原。
#######场景：每天定时全量备份，第二天误删数据库，然后恢复########
#主服务器PG库
#开启归档日志
vim /pgsql/data/postgres.conf
archive_mode = on
archive_command = '[ ! -f /archive/%f ] &&cp %p /archive/%f'
#重启服务
pg_ctl restart -D $PGDATA
#创建测试数据库
create database testdb;
\c testdb
create table tb1(id int);
insert into tb1 values(1);
#备份服务器上做全量备份
#提前在备份服务安装好postgresql数据库，创建/pgsql/backup和/archive目录，并设置所有者
#全量备份
pg_basebackup -D /pgsql/backup/ -Ft -Pv -Upostgres -h 10.0.0.136 -p 5432 -R
#主服务器PG库继续写入数据
\c testdb
insert into tb1 values(2);
insert into tb1 values(3);
#删除数据库
drop database testdb;
#发现故障停止用户访问，
#查看当前日志文件
select pg_walfile_name(pg_current_wal_lsn());
#查看事务ID
select txid_current();
#在PG服务器上切换归档日志
select pg_switch_wal();
#接下来在备份服务器操作
pg_ctl stop -D $PGDATA #停止服务
rm -rf /pgsql/data/* #删除数据文件
rm -rf /archive/* #删除归档日志文件
#恢复数据文件
tar xf /pgsql/backup/base.tar -C /pgsql/data/
#恢复归档日志
rsync -a 10.0.0.136:/archive/ /archive/
#查看故障事务点ID
pg_waldump /archive/000000020000000000000025 | grep -B 10 "DROP dir"
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/25000028, prev 0/24000138, desc: RUNNING_XACTS nextXid 783 latestCompletedXid 782 oldestRunningXid 783
rmgr: Heap len (rec/tot): 54/ 150, tx: 783, lsn: 0/25000060, prev 0/25000028, desc: INSERT off 2 flags 0x00, blkref #0: rel 1663/13025/24657 blk 0 FPW
rmgr: Transaction len (rec/tot): 34/ 34, tx: 783, lsn: 0/250000F8, prev 0/25000060, desc: COMMIT 2022-10-18 21:31:51.510019 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/25000120, prev 0/250000F8, desc: RUNNING_XACTS nextXid 784 latestCompletedXid 783 oldestRunningXid 784
rmgr: Heap len (rec/tot): 59/ 2583, tx: 784, lsn: 0/25000158, prev 0/25000120, desc: DELETE off 11 flags 0x00 KEYS_UPDATED , blkref #0: rel 1664/0/1262 blk 0 FPW
rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 0/25000B70, prev 0/25000158, desc: RUNNING_XACTS nextXid 785 latestCompletedXid 783 oldestRunningXid 784; 1 xacts: 784
rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 0/25000BA8, prev 0/25000B70, desc: RUNNING_XACTS nextXid 785 latestCompletedXid 783 oldestRunningXid 784; 1 xacts: 784
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 0/25000BE0, prev 0/25000BA8, desc: CHECKPOINT_ONLINE redo 0/25000BA8; tli 2; prev tli 2; fpw true; xid 0:785; oid 32848; multi 1; offset 0; oldest xid 726 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 784; online
rmgr: Database len (rec/tot): 38/ 38, tx: 784, lsn: 0/25000C58, prev 0/25000BE0, desc: DROP dir 1663/24656
#最下面一行发现故障点ID为784，则正常数据事件ID为783，而正常事务ID的COMMIT时间为2022-10-18 21:31:51（已用红字标注）
#修改配置文件
vi /pgsql/data/postgresql.conf
recovery_target_name = 'restore_point' #指定还原点名称
recovery_target_time = '2022-10-18 21:31:51' #指定还原至时间点
recovery_target_lsn = '0/250000F8' #指定还原到LSN号的位置
#启动服务
pg_ctl start -D $PGDATA
#查看数据是否恢复
###########恢复完成后发现数据库只能读取，无法写入。
insert into t1 values(4);
ERROR: cannot execute INSERT in a read-only transaction
#查看数据库状态，发现是归档恢复状态
pg_controldata
Database cluster state: in archive recovery
#
#恢复可读可写模式
select pg_wal_replay_resume();
#数据库状态变为
Database cluster state: in production
#还原完成
四、规划高可用的LAMP，要求wordpress网站放在NFS共享存储上，并且用户可以正常发布博客，上传图片。尝试更新wordpress版本，测试网站仍可用。
环境：LAMP服务器：10.0.0.136 NFS服务器：10.0.0.138
NFS服务器：
#安装nfs-units
yum -y install nfs-utils
#启动并设置开机自启
systemctl enable --now nfs-server
#创建用户指定UID
useradd -u 2000 www
#创建共享目录并设置所有者
mkdir /data/www
chown www.www /data/www
#创建配置文件
vim /etc/exports.d/www.exports
/data/www *(rw,all_squash,anonuid=2000,anongid=2000)
#让配置文件生效
exportfs -r
LAMP服务器：
#安装httpd和php
yum -y install httpd php php-mysqlnd php-json
#启动httpd并设置开机自启
systemctl enable --now httpd
#解压缩事先上传的wordpress
tar xf wordpress-5.9.5-zh_CN.tar.gz
#移动文件到httpd的默认目录下
mv wordpress/* /var/www/html/
#因为httpd默认的用户是apache，所以要指定所有者
chown apache.apache /var/www/html/ -R
#安装数据库
yum -y install mysql-server
#创建用户、创建数据库、授权访问
create user wordpress@'10.0.0.%' identified by '123456';
create database wordpress;
grant all on wordpress.* to wordpress@'10.0.0.%';
#####################初始化wordpress这里就不提了，浏览器输入10.0.0.136一路设置即可####################
#查看nfs-server是否存在，结果如下。
[root@rocky www]# showmount -e 10.0.0.138
Export list for 10.0.0.138:
/data/www *
#将所有文件拷贝到nfs-server上，防止一挂载文件丢失
scp -r /var/www/* 10.0.0.138:/data/www/
#将挂载信息写入开启自启中并及时生效
vim /etc/fstab
10.0.0.138:/data/www /var/www nfs _netdev 0 0
mount -a
#挂载结果如下
[root@rocky www]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 373M 0 373M 0% /dev
tmpfs 392M 0 392M 0% /dev/shm
tmpfs 392M 11M 381M 3% /run
tmpfs 392M 0 392M 0% /sys/fs/cgroup
/dev/mapper/rl_rocky-root 10G 2.4G 7.7G 24% /
/dev/mapper/rl_rocky-var 5.0G 709M 4.3G 14% /var
/dev/mapper/rl_rocky-opt 20G 243M 20G 2% /opt
/dev/mapper/rl_rocky-data 10G 104M 9.9G 2% /data
/dev/nvme0n1p1 1014M 216M 799M 22% /boot
tmpfs 79M 0 79M 0% /run/user/0
10.0.0.138:/data/www 20G 243M 20G 2% /var/www
#########################注意#########################
#因为这里是通过scp复制到nfs服务器的，所以必须在nfs服务器上执行一下文件归属者
chown -R www.www /data/www
#在nfs服务器上文件属性
[root@rocky www]# ll
total 4
drwxr-xr-x 2 www www 6 Oct 29 00:50 cgi-bin
drwxr-xr-x 5 www www 4096 Oct 29 00:51 html
#在LAMP上文件属性
[root@rocky www]# ll
total 4
drwxr-xr-x 2 2000 2000 6 Oct 29 00:50 cgi-bin
drwxr-xr-x 5 2000 2000 4096 Oct 29 00:51 html
#########因为nfs服务器上配置文件设置的uid和gid都是2000，但是在LAMP上没有uid是2000的账号，所有这里显示的是2000#########
#并在一篇文章中添加了一张图片，正常打开
五、redis数据类型
redis的数据类型分为：
1、字符串--string
2、列表---list
3、哈希---hash
4、有序集合---sorted set
5、集合---set
字符串：
字符串是一种最基本的Redis值类型。Redis字符串是二进制安全的，这意味着一个Redis字符串能包含任意类型的数据，例如： 一张JPEG格式的图片或者一个序列化的Ruby对象。一个字符串类型的值最多能存储512M字节的内容。Redis 中所有 key 都是字符串类型的。此数据类型最为常用
列表：
Redis列表就是简单的字符串数组，按照插入顺序排序. 支持双向读写,可以添加一个元素到列表的头部（左边）或者尾部（右边），一个列表最多可以包含2^32-1=4294967295个元素，每个列表元素有下标来标识,下标 0 表示列表的第一个元素，以 1 表示列表的第二个元素，以此类推。 也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，元素值可以重复，常用于存入日志等场景，此数据类型比较常用
哈希：
hash 即字典, 用于保存字符串字段field和字符串值value之间的映射，即key/value做为数据部分,hash特别适合用于存储对象场景.一个hash最多可以包含2^32-1 个key/value键值对
有序集合：
Redis有序集合和Redis集合类似，是不包含相同字符串的合集。它们的差别是，每个有序集合的成员都关联着一个双精度浮点型的评分，这个评分用于把有序集合中的成员按最低分到最高分排序。有序集合的成员不能重复,但评分可以重复,一个有序集合中最多的成员数为 2^32 - 1=4294967295个，经常用于排行榜的场景
集合：
Set 是一个无序的字符串合集，同一个集合中的每个元素是唯一无重复的，支持在两个不同的集合中对数据进行逻辑处理，常用于取交集,并集,统计等场景,例如: 实现共同的朋友六、redis RDB和AOF比较
默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
RDB相当于快照，而AOF是写日志。
RDB不能实时保存数据，可能会丢失上一次RDB备份到当前时间的数据。AOF可以设置保存数据时间最短为1秒，最多丢失一秒的数据。
RDB的优先级低于AOF。
AOF默认没有开启，默认使用的是RDB方式。
AOF会记录很多重复的操作，一般都要大于RDB文件。
AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢。
AOF出现bug的几率比RDB大。
AOF和RDB的选择：
一般可以忍受丢失数分钟的数据建议使用RDB即可，也是默认值。
如果不能忍受数据丢失，RDB和AOF同时开启。
一般不建议只开启AOF。七、redis配置文件详解。
bind 0.0.0.0 #指定监听地址，支持用空格隔开的多个监听IP
protected-mode yes #redis3.2之后加入的新特性，在没有设置bind IP和密码的时候,redis只允许访问127.0.0.1:6379，可以远程连接，但当访问将提示警告信息并拒绝远程访问
port 6379 #监听端口,默认6379/tcp
tcp-backlog 511 #三次握手的时候server端收到client ack确认号之后的队列值，即全连接队列长度
timeout 0 #客户端和Redis服务端的连接超时时间，默认是0，表示永不超时
tcp-keepalive 300 #tcp 会话保持时间300s
daemonize no #默认no,即直接运行redis-server程序时,不作为守护进程运行，而是以前台方式运行，如果想在后台运行需改成yes,当redis作为守护进程运行的时候，它会写一个 pid 到/var/run/redis.pid 文件
supervised no #和OS相关参数，可设置通过upstart和systemd管理Redis守护进程，centos7后都使用systemd
pidfile /var/run/redis_6379.pid #pid文件路径,可以修改为/apps/redis/run/redis_6379.pid
loglevel notice #日志级别
logfile "/path/redis.log" #日志路径,示例:logfile "/apps/redis/log/redis_6379.log"
databases 16 #设置数据库数量，默认：0-15，共16个库
always-show-logo yes #在启动redis 时是否显示或在日志中记录记录redis的logosave 900 1 #在900秒内有1个key内容发生更改,就执行快照机制
save 300 10 #在300秒内有10个key内容发生更改,就执行快照机制
save 60 10000 #60秒内如果有10000个key以上的变化，就自动快照备份
stop-writes-on-bgsave-error yes #默认为yes时,可能会因空间满等原因快照无法保存出错时，会禁止redis写入操作，生产建议为no#此项只针对配置文件中的自动save有效
rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之
rdbchecksum yes #是否对备份文件开启RC64校验，默认是开启
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路径，示例：dir "/apps/redis/data"
#主从复制相关
# replicaof <masterip> <masterport> #指定复制的master主机地址和端口，5.0版之前的指令为slaveof
# masterauth <master-password> #指定复制的master主机的密码
replica-serve-stale-data yes #当从库同主库失去连接或者复制正在进行，从机库有两种运行方式：
1、设置为yes(默认设置)，从库会继续响应客户端的读请求，此为建议值
2、设置为no，除去特定命令外的任何请求都会返回一个错误"SYNC with master in progress"。
replica-read-only yes #是否设置从库只读，建议值为yes,否则主库同步从库时可能会覆盖数据，造成数据丢失
repl-diskless-sync no #是否使用socket方式复制数据(无盘同步)，新slave第一次连接master时需要做数据的全量同步，redis server就要从内存dump出新的RDB文件，然后从master传到slave，有两种
方式把RDB文件传输给客户端：
1、基于硬盘（disk-backed）：为no时，master创建一个新进程dump生成RDB磁盘文件，RDB完成之后由父进程（即主进程）将RDB文件发送给slaves，此为默认值
2、基于socket（diskless）：master创建一个新进程直接dump RDB至slave的网络socket，不经过主进程和硬盘
#推荐使用基于硬盘（为no），是因为RDB文件创建后，可以同时传输给更多的slave，但是基于socket(为yes)， 新slave连接到master之后得逐个同步数据。只有当磁盘I/O较慢且网络较快时，可用diskless(yes),否则一般建议使用磁盘(no)
repl-diskless-sync-delay 5 #diskless时复制的服务器等待的延迟时间，设置0为关闭，在延迟时间内到达的客户端，会一起通过diskless方式同步数据，但是一旦复制开始，master节点不会再接收新slave的复制请求，直到下一次同步开始才再接收新请求。即无法为延迟时间后到达的新副本提供服务，新副本将排队等待下一次RDB传输，因此服务器会等待一段时间才能让更多副本到达。推荐值：30-60
repl-ping-replica-period 10 #slave根据master指定的时间进行周期性的PING master,用于监测master状态,默认10s
repl-timeout 60 #复制连接的超时时间，需要大于repl-ping-slave-period，否则会经常报超时
repl-disable-tcp-nodelay no #是否在slave套接字发送SYNC之后禁用 TCP_NODELAY，如果选择"yes"，Redis将合并多个报文为一个大的报文，从而使用更少数量的包向slaves发送数据，但是将使数据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒，如果 "no" ，数据传输到slave的延迟将会减少，但要使用更多的带宽
repl-backlog-size 512mb #复制缓冲区内存大小，当slave断开连接一段时间后，该缓冲区会累积复制副本数据，因此当slave 重新连接时，通常不需要完全重新同步，只需传递在副本中的断开连接后没有同步的部分数据即可。只有在至少有一个slave连接之后才分配此内存空间,建议建立主从时此值要调大一些或在低峰期配置,否则会导致同步到slave失败repl-backlog-ttl 3600 #多长时间内master没有slave连接，就清空backlog缓冲区
replica-priority 100 #当master不可用，哨兵Sentinel会根据slave的优先级选举一个master，此值最低的slave会优先当选master，而配置成0，永远不会被选举，一般多个slave都设为一样的值，让其自动选择
#min-replicas-to-write 3 #至少有3个可连接的slave，mater才接受写操作
#min-replicas-max-lag 10 #和上面至少3个slave的ping延迟不能超过10秒，否则master也将停止
写操作
requirepass foobared #设置redis连接密码，之后需要AUTH pass,如果有特殊符号，用" "引起来,生产建议设置
rename-command #重命名一些高危命令，示例：rename-command FLUSHALL "" 禁用命令
#示例: rename-command del magedu
maxclients 10000 #Redis最大连接客户端
maxmemory <bytes> #redis使用的最大内存，单位为bytes字节，0为不限制，建议设为物理内存一半，8G内存的计算方式8(G)*1024(MB)1024(KB)*1024(Kbyte)，需要注意的是缓冲区是不计算在maxmemory内,生产中如果不设置此项,可能会导致OOM
#maxmemory-policy noeviction 此为默认值
# MAXMEMORY POLICY：当达到最大内存时，Redis 将如何选择要删除的内容。您可以从以下行为中选择一种：
#
# volatile-lru -> Evict 使用近似 LRU，只有设置了过期时间的键。
# allkeys-lru -> 使用近似 LRU 驱逐任何键。
# volatile-lfu -> 使用近似 LFU 驱逐，只有设置了过期时间的键。
# allkeys-lfu -> 使用近似 LFU 驱逐任何键。
# volatile-random -> 删除设置了过期时间的随机密钥。
# allkeys-random -> 删除一个随机密钥，任何密钥。
# volatile-ttl -> 删除过期时间最近的key（次TTL）
# noeviction -> 不要驱逐任何东西，只是在写操作时返回一个错误。
#
# LRU 表示最近最少使用
# LFU 表示最不常用
#
# LRU、LFU 和 volatile-ttl 都是使用近似随机算法实现的。
#
# 注意：使用上述任何一种策略，当没有合适的键用于驱逐时，Redis 将在需要更多内存的写操作时返回错误。这些通常是创建新密钥、添加数据或修改现有密钥的命令。一些示例是：SET、INCR、HSET、LPUSH、SUNIONSTORE、SORT（由于 STORE 参数）和 EXEC（如果事务包括任何需要内存的命令）。
#MAXMEMORY POLICY：当达到最大内存时，Redis 将如何选择要删除的内容。可以从下面行为中进行选择：
# volatile-lru -> 在具有过期集的键中使用近似 LRU 驱逐。
# allkeys-lru -> 使用近似 LRU 驱逐任何键。
# volatile-lfu -> 在具有过期集的键中使用近似 LFU 驱逐。
# allkeys-lfu -> 使用近似 LFU 驱逐任何键。
# volatile-random -> 从具有过期设置的密钥中删除一个随机密钥。
# allkeys-random -> 删除一个随机密钥，任何密钥。
# volatile-ttl -> 删除过期时间最近的key（次TTL）
# noeviction -> 不要驱逐任何东西，只是在写操作时返回一个错误。
#
# LRU 表示最近最少使用# LFU 表示最不常用
#
# LRU、LFU 和 volatile-ttl 均使用近似实现随机算法。
#
# 注意：使用上述任何一种策略，Redis 都会在写入时返回错误操作，当没有合适的键用于驱逐时。appendonly no #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，
Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能
appendfilename "appendonly.aof" #文本文件AOF的文件名，存放在dir指令指定的目录中
appendfsync everysec #aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
#同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制
no-appendfsync-on-rewrite no #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间
auto-aof-rewrite-percentage 100 #当Aof log增长超过指定百分比例时，重写AOF文件，设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据
auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小
aof-load-truncated yes #是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等)，建议yes
aof-use-rdb-preamble no #redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内容则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）,默认为no,即不启用此功能
lua-time-limit 5000 #lua脚本的最大执行时间，单位为毫秒
cluster-enabled yes #是否开启集群模式，默认不开启,即单机模式
cluster-config-file nodes-6379.conf #由node节点自动生成的集群配置文件名称
cluster-node-timeout 15000 #集群中node节点连接超时时间，单位ms,超过此时间，会踢出集群
cluster-replica-validity-factor 10 #单位为次,在执行故障转移的时候可能有些节点和master断开一段时间导致数据比较旧，这些节点就不适用于选举为master，超过这个时间的就不会被进行故障转移,不能当选master，计算公式：(node-timeout * replica-validity-factor) + repl-pingreplica-period2.2 config 命令实现动态修改配置config 命令用于查看当前redis配置、以及不重启redis服务实现动态更改redis配置等
注意：不是所有配置都可以动态修改,且此方式无法持久保存
2.2.1 设置客户端连接密码
cluster-migration-barrier 1 #集群迁移屏障，一个主节点至少拥有1个正常工作的从节点，即如果主节点的slave节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。
cluster-require-full-coverage yes #集群请求槽位全部覆盖，如果一个主库宕机且没有备库就会出现集群槽位不全，那么yes时redis集群槽位验证不全,就不再对外提供服务(对key赋值时,会出现CLUSTERDOWN The cluster is down的提示,cluster_state:fail,但ping 仍PONG)，而no则可以继续使用,但是会出现查询数据查不到的情况(因为有数据丢失)。生产建议为no
cluster-replica-no-failover no #如果为yes,此选项阻止在主服务器发生故障时尝试对其主服务器进行故障转移。 但是，主服务器仍然可以执行手动强制故障转移，一般为no
#Slow log 是 Redis 用来记录超过指定执行时间的日志系统，执行时间不包括与客户端交谈，发送回复等I/O操作，而是实际执行命令所需的时间（在该阶段线程被阻塞并且不能同时为其它请求提供服务）,由于slow log 保存在内存里面，读写速度非常快，因此可放心地使用，不必担心因为开启 slow log 而影响Redis 的速度
slowlog-log-slower-than 10000 #以微秒为单位的慢日志记录，为负数会禁用慢日志，为0会记录每个命令操作。默认值为10ms,一般一条命令执行都在微秒级,生产建议设为1ms-10ms之间
slowlog-max-len 128 #最多记录多少条慢日志的保存队列长度，达到此长度后，记录新命令会将最旧的命令从命令队列中删除，以此滚动删除,即,先进先出,队列固定长度,默认128,值偏小,生产建议设为1000以上