1.postgresql架构与原理。

PostgreSQL（通常简称为Postgres）是一种开源的关系型数据库管理系统（RDBMS），它具有强大的功能和可扩展性。以下是关于PostgreSQL架构和原理的一些基本信息：

1. 架构概述： PostgreSQL采用了客户端-服务器体系结构。它由多个组件组成，包括客户端应用程序、PostgreSQL服务器进程、后台进程和数据文件。客户端通过网络连接到服务器，发送SQL查询并接收结果。

2. 进程和后台任务： PostgreSQL包含多个进程，每个进程执行不同的任务。一些重要的后台进程包括：

Postmaster： 这是主服务器进程，负责处理客户端连接、权限认证、查询解析和查询执行的规划。
后台写进程（Background Writer）： 负责将脏数据（已经被修改但尚未写回磁盘的数据）写回磁盘，以减轻IO压力。
自动化清理进程（Autovacuum）： 定期检查并清理不再需要的行和表，以避免表“膨胀”和性能下降。
WAL Writer： 负责将事务日志（Write-Ahead Logging，WAL）从内存写入磁盘，以确保数据持久性和恢复能力。

3. 存储系统： PostgreSQL使用表来组织数据，表是由行和列组成的。数据存储在数据文件中，这些文件以固定大小的块（通常是8KB）存储在磁盘上。每个数据库都有一个或多个表空间（Tablespace），表空间定义了数据文件的存储位置。

4. 查询处理： 当客户端发送SQL查询到PostgreSQL服务器时，查询经过一系列步骤进行处理：

查询解析： 查询文本被解析成内部数据结构，这些结构表示了查询的语义。
查询优化： 查询优化器分析多种执行计划，选择最优的执行路径，以尽量减少查询所需的资源和时间。
执行计划生成： 优化器选择的执行计划被转换成可执行的指令序列。
查询执行： 查询执行引擎执行生成的指令序列，从存储中检索数据，进行必要的计算，并返回结果给客户端。

5. 事务处理和并发控制： PostgreSQL支持ACID事务（原子性、一致性、隔离性、持久性）和多版本并发控制（MVCC）。MVCC允许多个事务并发执行而不会相互干扰，每个事务都可以看到数据库的一致性快照。

以上只是PostgreSQL架构和原理的基本概述。实际上，PostgreSQL还涉及了更多的细节，包括索引、触发器、备份和恢复等方面的内容。如果你想深入了解，建议查阅官方文档或专业的数据库教材。

2.基于流复制完成postgresql的高可用。

Master 节点配置

#创建复制的用户并授权 
[postgres@master ~]$ psql 
postgres=#create role repluser with replication login password '123456'; 

#修改pg_hba.conf进行授权 
[postgres@master ~]$vi /pgsql/data/pg_hba.conf 
host replication repluser 0.0.0.0/0 md5 

#修改配置(可选): 
[postgres@master ~]$vi /pgsql/data/postgresql.conf 
synchronous_standby_names = '*'  #开启此项,表示同步方式,需要同时打开synchronous_commit = on,此为默认值,默认是异步方式
synchronous_commit = on #开启同步模式 
archive_mode = on   #建议打开归档模式,防止长时间无法同步,WAL被覆盖造成数据丢失 
archive_command = '[ ! -f /archive/%f ] && cp %p /archive/%f' 
wa1_level = replica #设置wal的级别
max_wal_senders = 5 #这个设置可以最多有几个流复制连接，一般有几个从节点就设置几个 
wal_keep_segments = 128 #设置流复制保留的最多的WAL文件数目 
wal_sender_timeout = 60s #设置流复制主机发送数据的超时时间 
max_connections = 200 # 一般查多于写的应用从库的最大连接数要比较大 
hot_standby = on #对主库无影响,用于将来可能会成为从库,这台机器不仅仅是用于数据归档，也用于数 据查询,在从库上配置此项后为只读 
max_standby_streaming_delay = 30s #数据流备份的最大延迟时间 
wal_receiver_status_interval = 10s #多久向主报告一次从的状态，当然从每次数据复制都会向主报 告状态，只是设置最长的间隔时间 
hot_standby_feedback = on #如果有错误的数据复制，是否向主进行反馈 
wal_log_hints = on     #对非关键更新进行整页写入 

[postgres@master ~]$pg_ctl restart -D /pgsql/data

Standby 节点配置

#清空数据和归档 
[postgres@standby ~]$ pg_ctl stop -D $PGDATA 
[postgres@standby ~]$ rm -rf /pgsql/data/* 
[postgres@standby ~]$ rm -rf /archive/* 
[postgres@standby ~]$ rm -rf /pgsql/backup/* 

#备份主库数据到备库 
[postgres@standby ~]$ pg_basebackup -D /pgsql/backup/ -Ft -Pv -Urepluser -h 10.0.0.101 -p 5432 -R 

#还原备份的数据,实现初始的主从数据同步 
[postgres@standby ~]$ tar xf /pgsql/backup/base.tar -C /pgsql/data 
[postgres@standby ~]$ tar xf /pgsql/backup/pg_wal.tar -C /archive/ 

#方法1 #修改postgresql.conf文件 
[postgres@standby ~]$ vi /pgsql/data/postgresql.conf 

#添加下面两行 
primary_conninfo = 'host=10.0.0.101 port=5432 user=repluser password=123456' 
restore_command = 'cp /archive/%f %p' #此项可不配置

#修改配置(可选): 
hot_standby = on   #开启此项,此是默认项 
recovery_target_timeline = latest # 默认 
max_connections = 120 # 大于等于主节点，正式环境应当重新考虑此值的大小 
max_standby_streaming_delay = 30s 
wal_receiver_status_interval = 10 
shot_standby_feedback = on 
max_wal_senders = 15 
logging_co1lector = on 
log_directory = 'pg_log' 
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' 

#方法
2 #修改postgresql.auto.conf 
[postgres@standby ~]$ vi /pgsql/data/postgresql.auto.conf
primary_conninfo = 'host=10.0.0.101 port=54321 user=repluser password=123456 
sslmode=disable sslcompression=0 gssencmode=disable 
krbsrvname=post_session_attrs=any' #此行自动生成,只修改用户名即可 
restore_command = 'cp /archive/%f %p' 

[postgres@standby ~]$ pg_ctl -D /pgsql/data start

监控同步状态

在主库查看状态

[root@master ~]#pg_controldata
[root@master ~]#psql
postgres=#select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

#下面只在主节点查看同步模式,注意:如果无从节点连接,将无任何显示信息 
postgres=# SELECT pg_current_wal_insert_lsn(),* from pg_stat_replication;

#服务器查看数据库是否为备库，f表主库 t表示为备库 
postgres=# select * from pg_is_in_recovery();

postgres=# select application_name,client_addr,sync_state from pg_stat_replication;
[root@master ~]#ps aux |grep walsender

在从库查看状态

#从节点可以读 
hellodb=# select * from teachers;

#从节点不支持写 
hellodb=# delete from teachers where tid=4;
ERROR: cannot execute DELETE in a read-only transaction

[postgres@slave ~]$pg_controldata

postgres=# select * from pg_is_in_recovery();

3. 实现postgresql的时间点还原。

PostgreSQL的“时间点恢复”（PITR）也称为增量数据库备份，在线备份或可能是存档备份。 PostgreSQL服务器记录所有用户的数据修改事务，例如插入，更新或删除，

并将其写入文件调用预写（WAL）日志文件中。该机制使用存储在WAL文件中的历史记录来进行自上次数据库完全备份以来所做的前滚更改。

备份

#在PG服务器开启归档 
[postgres@pgserver ~]$ vim /pgsql/data/postgresql.conf 
archive_mode = on 
archive_command = 'test ! -f /archive/%f &&cp %p /archive/%f' 
[postgres@gpserver ~]$pg_ctl restart  -D $PGDATA

#在PG服务器上创建测试数据 
postgres=#create database testdb;
postgres=#\c testdb 
testdb=# create table t1(id int); 
testdb=# insert into t1 values(1);

#在备份服务器对PG数据库进行远程完全备份 
[postgres@backup ~]$pg_basebackup -D /pgsql/backup/ -Ft -Pv -Upostgres -h 10.0.0.200 -p 5432 -R

#在PG服务器上继续生成测试数据 
testdb=# insert into t1 values(2);

#模拟数据库删除 
postgres=# drop database testdb;

#发现故障，停止用户访问 
#查看当前日志文件
postgres=# select pg_walfile_name(pg_current_wal_lsn());

#查看当前事务ID 
postgres=# select txid_current();

故障还原

#在PG服务器上切换归档日志 
postgres=#select pg_switch_wal();

#在要还原的服务器停止服务,准备还原
[postgres@pgserver ~]$pg_ctl stop  -D $PGDATA 
[postgres@pgserver ~]$rm -rf /pgsql/data/*

#在测试的还原服务器进行还原 
[postgres@backup ~]$tar xf /pgsql/backup/base.tar -C /pgsql/data/ #此步可以不执行
[postgres@backup ~]$tar xf /pgsql/backup/pg_wal.tar -C /archive/

#复制PG服务器的归档日志到还原的测试服务器 
[postgres@pgserver ~]$rsync -a 10.0.0.200:/archive/ /archive/

#查看故障点事务ID 
[postgres@backup ~]$pg_waldump /archive/000000020000000000000020 |grep -B 10 "DROP dir"

#修改配置文件postgresql.conf,或者postgresql.auto.conf文件也可以 
[postgres@backup ~]$vi /pgsql/data/postgresql.conf 
#加下面两行 
restore_command = 'cp /archive/%f %p' 
#指定还原至上面查到的事务ID 
recovery_target_xid = '520'

#启动服务 
[postgres@backup ~]$pg_ctl start -D $PGDATA

#验证数据 
[postgres@backup ~]$psql
postgres=# \c testdb
testdb=# select * from t1; 
#当前无法写入 
testdb=# insert into t1 values(4);
ERROR: cannot execute INSERT in a read-only transaction
#恢复正常模式 
postgres=# select pg_wal_replay_resume();

4.规划高可用的LAMP，要求wordpress网站放在NFS共享存储上，并且用户可以正常发布博客，上传图片。尝试更新wordpress版本，测试网站仍可用。

1.实验需求
________________________________________
（1）nfs server导出/data/application/web,在目录中提供wordpress;
（2）nfs client挂载nfs server导出的文件系统，至/var/www/html;
（3）客户端1(lamp)部署wordpress，并让其正常访问，要确保正常发文章，上传图片。
（4）客户端2(lamp),挂载nfs server导出的文件系统至/var/www/html，验证其wordpress是
否可被访问，要确保能正常发文章，上传图片。
（5）nfs server 导出/mydata/目录；
（6）nfs client挂载/mydata/至本地的/mydata目录，mysqld或mariadb服务的数据目录设置为/mydata, 要求服务能正常启动，且可正常存储数据。
2.服务器规划
________________________________________
服务器版本    角色    主机名    IP地址
centos7.2x86_64    web服务器01（apache+php）
nfs客户端    web01    172.16.52.51
centos7.2x86_64    web服务器02（apache+php）
nfs客户端    web02    172.16.52.52
centos7.2x86_64    mysqld数据库服务
nfs客户端    db    172.16.52.53
centos7.2x86_64    nfs服务端    nfs    172.16.52.54
部署NFS服务端及nfs客户端
________________________________________
3.1 配置nfs服务端
(1)安装nfs软件
[root@nfs ~]# yum -y install nfs-utils
[root@nfs ~]# rpm -qa nfs-utils
nfs-utils-1.3.0-0.21.el7.x86_64
 
(2)启动nfs服务
 开机自启动nfs服务：
[root@nfs ~]# systemctl enable rpcbind.service
[root@nfs ~]# systemctl enable nfs-server.service
 
 启动rpcbind和nfs服务：
 注意要先启动rpcbind
[root@nfs ~]# systemctl start rpcbind.service
[root@nfs ~]# systemctl start nfs.service
 
 查看nfs状态：
[root@nfs ~]# rpcinfo -p
 
 (3)配置nfs服务
[root@nfs ~]# cat /etc/exports
/data/application/web 172.16.0.0/16(rw,sync,anonuid=888,anongid=888)
/mydata   172.16.0.0/16(rw,sync,anonuid=3306,anongid=3306)
 
  重新导出：
[root@nfs ~]# exportfs -arv
exporting 172.16.0.0/16:/data
exporting 172.16.0.0/16:/data/application/web
 
 为nfs共享文件创建授权用户（uid）：
 这里我们不使用默认的nfsnobody用户
[root@nfs ~]# groupadd -g 888 apache
[root@nfs ~]# useradd -u 888 -g apache -s/sbin/nologin -M apache
[root@nfs ~]# id apache
uid=888(apache) gid=888(apache) groups=888(apache)
[root@nfs ~]# chown apache.apache/data/application/web
[root@nfs ~]# ls -ld /data/application/web/
drwxr-xr-x 2 apache apache 6 Jul 20 04:27/data/application/web/
[root@nfs ~]# groupadd -g 3306 mysql
[root@nfs ~]# useradd -u 3306 -g mysql -s/sbin/nologin -M mysql
[root@nfs ~]# id mysql
uid=3306(mysql) gid=3306(mysql) groups=3306(mysql)
[root@nfs ~]# chown mysql.mysql /data
[root@nfs ~]# ls -ld /data
drwxr-xr-x 4 mysql mysql 35 Jul 20 04:27 /data


3.2 配置nfs客户端
 注：3个nfs客户端配置都一样
 安装软件包：
[root@db ~]# yum -y install nfs-utils
 
 启动rpcbind：
 客户端只用启动rpcbind即可。
[root@db ~]# systemctl start rpcbind

4.部署lamp环境
________________________________________
说明：本次lamp环境采用rpm包安装，数据库分离
web01 和web02 配置一样。
为了方便测试：web01域名blog.magedu.com；web02域名blog02.magedu.com
4.1 安装软件
[root@web01 ~]# yum -y install httpd php php-mysql
 
4.2 配置虚拟主机
[root@web01 conf.d]# cat blog.conf
<VirtualHost *:80>
         ServerNameblog.magedu.com
         DocumentRoot"/var/www/html"
         CustomLog"/var/log/httpd/blog/access_log" combined
         ErrorLog  "/var/log/httpd/blog/error_log"  
         <Directory"/var/www/html">
                   OptionsNone
                   AllowOverrideNone
                   Requireall granted
         </Directory>
</VirtualHost>
5. 部署mariadb数据库服务
________________________________________
 mariadb采用通用二进制安装
[root@db soft]# ln -sv mariadb-5.5.46-linux-x86_64 mariadb
[root@db soft]#ls
mariadb  mariadb-5.5.46-linux-x86_64
5.1 创建mysql用户
[root@db soft]# groupadd -g 3306 mysql
[root@db soft]# useradd -u 3306 -g mysql mysql
[root@db soft]# id mysql
uid=3306(mysql) gid=3306(mysql) groups=3306(mysql)
5.2 创建数据目录并授权
[root@db soft]# mkdir /mydata
[root@db soft]# chown -R mysql.mysql /mydata
[root@db soft]# ls -ld /mydata
drwxr-xr-x 2 mysql mysql 6 Jul 20 07:27 /mydata
 
5.3 初始化数据库
[root@db mariadb]# chown -R root.mysql /data/soft/mariadb/
[root@db mariadb]# cd /data/soft/mariadb
[root@db mariadb]# scripts/mysql_install_db--user=mysql --datadir=/mydata --basedir=/data/soft/mariadb
 
5.4 配置/etc/my.cnf
# cp support-files/my-large.cnf /etc/my.cnf
vim /etc/my.cnf
[mysqld]
port = 3306
basedir = /data/soft/mariadb
datadir = /data/mydata
innodb_file_per_table = 1 #让innodb表每个表一个表空间文件。
5.5 配置mysqld启动脚本
 复制mysql启动脚本到/etc/init.d/mysqld
[root@db ~]# cp /data/soft/mariadb/support-files/mysql.server/etc/init.d/mysqld
[root@db ~]# chmod 755 /etc/init.d/mysqld
[root@db ~]# sed -i‘s#/usr/local/mysql#/data/soft/mariadb#g‘ /etc/init.d/mysqld
[root@db ~]# chkconfig --add mysqld
 
 修改PATH环境变量：
[root@db mariadb]# cat /etc/profile.d/mysql.sh
export PATH=/data/soft/mariadb/bin:$PATH
 
 配置库文件搜索路径：
[root@db mariadb]# echo"/data/soft/mariadb/lib" > /etc/ld.so.conf.d/mysqld.conf
[root@db mariadb]# ldconfig
5.6 启动mysqld服务
[root@db /]# service mysqld start
Starting MySQL.. SUCCESS!
[root@db /]# lsof -i:3306
COMMAND PID  USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
mysqld  7668mysql   15u  IPv4 23521      0t0  TCP *:mysql (LISTEN)
 
5.7 测试php与数据库的连接
 注：事先创建好相关的库和用户
 在web服务器站点下创建mysql.php 文件
[root@web01 html]# cat mysql.php
<?php
         $conn= mysql_connect(‘172.16.52.53‘,‘wordpress‘,‘123456‘);
         if($conn)
                   echo‘connect 172.16.52.53 is OK‘;
         else
                   echo‘failure‘;
?>
5.8 把nfs服务端的/mydata/目录挂载至本地的/mydata
 
[root@db ~]# showmount -e 172.16.52.54
Export list for 172.16.52.54:
/mydata               172.16.0.0/16
/data/application/web 172.16.0.0/16
 
[root@db ~]# ls -ld /mydata/
drwxr-xr-x 6 mysql mysql 4096 Jul 21 06:05 /mydata/
 
[root@nfs /]# ls -ld /mydata
drwxr-xr-x 6 mysql mysql 4096 Jul 21 06:05 /mydata
 
 把本地mysql数据目录/mydata里面的文件复制到nfs服务端的/mydata目录里
[root@db ~]# scp -r /mydata/*root@172.16.52.54:/mydata
 
 重新对nfs服务端/mydata/下面的文件授权：
chown -R mysql.mysql /mydata
 
 挂载：
mount -t nfs 172.16.52.54:/mydata /mydata
 重启mysqld测试：
[root@db ~]# service mysqld restart
Shutting down MySQL. SUCCESS!
Starting MySQL.. SUCCESS!
ok,没有问题。
6.部署web服务器站点目录
________________________________________
6.1 LAMP 01部署wordpress站点
 站点目录严格授权:
[root@web01 html]# chown -R root.root/var/www/html/
[root@web01 html]# find /var/www/html/ -type f|xargs chmod 644
[root@web01 html]# find /var/www/html/ -type d|xargs chmod 755
[root@web01 html]# chown -R apache.apache/var/www/html/wordpress/wp-content
6.2 把nfs服务端的/data/application/web 挂载至web01本地的/var/www/html
（1）把/var/www/html下面的文件复制到/data/application/web目录下面
 [root@web01 ~]# scp -rp /var/www/html/*root@172.16.52.54:/data/application/web/
 
（2）授权
 [root@nfs~]# chown -R apache.apache /data/application/web/wordpress/wp-content/
        
（3）挂载
[root@web01 ~]# showmount -e 172.16.52.54
Export list for 172.16.52.54:
/mydata               172.16.0.0/16
/data/application/web 172.16.0.0/16
 [root@web01 wordpress]# mount -t nfs 172.16.52.54:/data/application/web/var/www/html
6.3 把nfs服务端的/data/application/web 挂载至web02本地的/var/www/html
（1）挂载
[root@web02 ~]# mount -t nfs172.16.52.54:/data/application/web /var/www/html
（2）访问blog02.magedu.com/wordpress/index.php
7. 总结
________________________________________
本次实验实现了web站点数据的共享，一定程度上实现session共享和负载均衡的功能。

5.redis数据类型有哪些？

Redis是一个开源的高性能键值存储系统，支持多种数据类型。以下是Redis支持的主要数据类型：

字符串（String）： 最基本的数据类型，可以存储文本、二进制数据等。
哈希表（Hash）： 类似于关联数组，可以存储字段和值的映射关系，用于存储对象的属性。
列表（List）： 有序的字符串列表，可以在列表的两端进行插入和删除操作，用于实现队列、栈等数据结构。
集合（Set）： 无序的字符串集合，支持集合间的交、并、差等操作，还能对集合中的元素进行添加、删除等操作。
有序集合（Sorted Set）： 类似于集合，但每个元素都关联一个分数，用于排序和排名操作。

6.redis RDB和AOF比较？

Redis支持两种不同的持久化方式：RDB（Redis Database）和AOF（Append-Only File）。它们各自具有不同的特点和适用场景，下面对它们进行比较：

RDB（Redis Database）持久化：

快照持久化： RDB持久化通过周期性地将内存中的数据快照保存到磁盘上的二进制文件中，这种方式适合用于备份和灾难恢复。
优点：
- 性能较高：生成快照时，Redis会fork出一个子进程来执行持久化操作，父进程继续处理客户端请求，因此不会阻塞服务。
- 文件紧凑：RDB文件是二进制的，相对于AOF文件较小，适用于在磁盘上保存历史数据。
缺点：
- 数据丢失风险：如果Redis崩溃，最后一次快照之后的数据将丢失。
- 不适合实时恢复：如果要实时恢复数据，需要结合AOF进行补充。

AOF（Append-Only File）持久化：

追加日志持久化： AOF持久化记录每个写操作（包括增删改）作为一条日志，这些操作会被追加到一个文件中，用于在重启时恢复数据。
优点：
- 更高的数据安全性：由于记录了每个写操作，AOF可以提供更高的数据安全性，减小数据丢失的风险。
- 可读性：AOF文件是文本格式的，易于人类阅读和理解，适合于调试和分析。
缺点：
- 性能相对较低：与RDB相比，AOF持久化可能会对性能产生更大的影响，因为每次写操作都要追加到文件中。
- 文件较大：由于记录了每个写操作，AOF文件通常比RDB文件大。

选择适用的持久化方式：

如果你对数据的安全性要求很高，可以选择AOF持久化，尤其是在不允许有数据丢失的情况下。
如果你追求更好的性能，并且可以接受在某些情况下可能丢失一部分数据，可以选择RDB持久化。
也可以同时启用RDB和AOF持久化，以便在发生故障时更好地保护数据。

需要根据具体的应用场景和需求来选择适合的持久化方式，或者结合两种方式以获得更好的数据保护和性能。

7.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的logo

save 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-ping-replica-period

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以上

第7周作业