NoSQL之redis配置与优化

mysql优化

1线程池优化

2硬件优化

3索引优化

4慢查询优化

5内存优化

6连接数优化（超时时间）（用的最多）

7分库分表

8存储过程

存储过程在运行整个存储时在内

mysql超过连接数连接超时

主从复制，优化，mha高可用面试问的最多其次时sql语句（面试）

cdn 缓存 或 代理

squid

20万并发怎么解决

高可用

1.持久化
aof rdb工作流程（存储数据过程）
1.持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘保证数据不会因进程退出而丢失.
2.主从复制
主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制实现了数据的多机备份，以及对于读操作的负载均衡
3.哨兵
在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷:写操作无法负载均衡;存储能力受到单机的限制。Ccluster集群:通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
单机：只能保存在自己那
4.集群
通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

5.redis优化 雪崩 穿透

持久化功能

redis是内存数据库，数据都是存储在内存中，为了避免服务器断电等原因导致redis进程异常退出后数据的永久丢失，需要定期将redis中的数据以某种形式（数据或命令）从内存保存到硬盘；当下次redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。

Redis提供两种方式进行持久化

RDB持久化:原理是将redis在内存中数据记录定时保存到磁盘上

AOF持久化:原理是将Redis的操作日志以追加的方式写入文件，类似于MySQL的binlog

RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘（因此也称快照持久化），用二进制压缩存储，保存的文件后缀是rdb；当redis重新启动时，可以读取快照文件恢复数据。

1.触发条件

RDB持久化的触发分为手动触发和自动触发两种

手动触发

save命令和bgsave命令都可以生成RDB文件

save命令会阻塞redis服务器进程，知道rdb文件创建完毕为止，在redis服务器阻塞期间，服务器不能处理任何命令请求

而bgsave命令会创建一个子进程，由子进程来负责创建rdb文件，父进程（即redis主进程）则继续处理请求。

bgsave命令执行过程中，只有fork子进程会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。

自动触发

在自动触发RDB持久化时，redis也会选择bgsave而不是save来进行持久化

重点

执行流程

rdb
(1) Redis父进程首先判断:当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。
bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
(2）父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
(3)父进程fork后，bgsave命令返回"Background saving started"信息并不再阻塞父进程，并可以响应其他命令(4）子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
(5）子进程发送信号给父进程表示完成，父进程更新统计信息
3.启动时加载
RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Bedis会优先载入
AOF文件来恢复数据:只有当AoF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RB文件期间处于阻塞状态,直到载入完成为止。
Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

优缺点

缺点：

1.数据完整性不如aof

2.rdb类似于快照（完备）

占用大量磁盘空间

3.在进行备份时会阻塞进程

优势

1.持久化速度快（因为保存的数据结果），再写入到*.rdb持久化文件会进行压缩，来减小自身的体积

2.集群中，redis主从复制，从–》主服务器进行同步，默认先使用rdb文件进行恢复操作，同步性能较高

redis默认开启RDB，关闭AOF：要开启AOF，需要配置文件中配置


如果没有其他子进程，父进程就会fork子进程，fork过程中父进程阻塞子进程创建好会信息通知父进程继续响应其他的命令

redis会将写入命令存在缓冲区里面，根据fsnc策略同步到硬盘里面

appendfsync always:
命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘Io成为性能瓶颈，Redis只能支持大约几百TPs写入，严重降低了Redis的性能:即便是使用固态硬盘（S$D)，每秒大约也只能处理几万个命令，而且会大大降低ssD的寿命。
appendfsync no:
命令写入aof_buf后调用系统write操作，不对AoF文件做fsync同步:同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
appendfsync everysec:
命令写入aof_buf后调用系统write操作，write完成后线程返回; fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。
(3)文件重写(rewrite)
随着时间流逝，Redis服务器执行的写命令越来越多，AoF文件也会越来越大:过大的AoF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。

AOF根据redis操作日志的记录，持续将日志中的执行操作保存在磁盘中

AOF出发规则：

常用触发规则：

1.always 一直触发AOF的持久化

2.every second 每秒触发一次持久化

3.no 不进行持久化

出现在1s内执行20条语句

1.always:每执行一条语句就触发一次aof持久化

2.every:每秒触发执行一次aof持久化操作

3.no:从不进行持久化

redis流程（内部数据流向）

AOF流程

AOF缺陷和优点

缺陷

1.执行语句一直情况下，AOF备份内容更大

RDB备份内容较小

RDB备份的是结果

RDB备份的是语句

2.AOF消耗的性能更大，占用磁盘越来越大

（可以理解为mysql的增备）

优势

1.AOF的数据完整性比RDB高

2.重写功能 会对无效语句 进行删除（目的就是为了节省AOF文件占用磁盘的空间）