java架构之路——Redis的高性能和持久化（Redis专题）
前言
在我们现有的redis中(5.0.*之前的版本)，Redis都是单线程的，那么单线程的Redis为什么还会有那么高的效率呢？因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换中性能损耗的问题，正因为Redis是单线程，所以我们要小心使用Redis指令，对于那些耗时的指令(比如keys)，我们一定要谨慎使用。
在并发环境中，我们Redis的单线程并不是线程1请求了，而我们的线程2就无法继续请求了，而他的内部是采用了IO多路复用，redis利用epoli来实现IO多路复用，将连接信息和事件放在队列中，依次放到事件分派器，事件分派器将事件分发给我们的事件处理器来执行指令操作。
redis默认支持最大连接数是10000，我们通过设置我们的redis.conf来指定我们的最大连接数，# maxclients 10000 => maxclients 100，大致在539行，或者我们输入/maxclients 可以快速查找到我们需要改的配置，进入我们的客户端，输入$ CONFIG GET maxclients，即可查看我们的客户端最大连接数。
127.0.0.1:6379> CONFIG GET maxclients 1) "maxclients" 2) "100"
高级命令
我们输入keys *，既可以返回我们的全部键的数据，一般不推荐使用，如果数据量过大，会相当消耗性能的。
scan，scan提供了三个参数，第一个是cursor整数值，第二个是key的正则模式。第三个是第一次遍历的key的数量，并不是符合条件的结果的数量，第一次遍历时，cursor值为0，然后我们将返回结果中第一个整数作为下一次遍历的cursor。一直遍历到cursor值为0时结束。
127.0.0.1:6379> scan 0 match key* count 5
1) "6"
2) 1) "key6"
2) "key4"
3) "key1"
127.0.0.1:6379> scan 6 match key* count 5
1) "0"
2) 1) "key5"
2) "key2"
3) "key3"
nfo：查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:
Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息
日志
redis.conf文件配置logfile来配置我们的log日志信息。大概在137行。
logfile "logForRedis.log"
Redis持久化
持久化主要分为三种，RDB，AOF和混合模式(4.0.*以后的模式)。
RDB快照模式
在默认情况下，Redis将内存数据库快照保存为*.rdb的二进制文件。我用的是5.0.5版本，默认是开启我们的RDB快照模式的，大致在253行，我们看到dbfilename dump.rdb，就是我们要以dump.rdb的文件来存储，存储位置在263行的dir ./ 也就是我们的当前路径（这里可以设置绝对路径）。
我们在大概218行可以看到三个save，也就是我们RDB的保存策略
save 900 1 //表示在900秒内，发生了一次变动，我们就生成一次快照，变动只是数据的变动，get并不算变动
save 300 10 //表示在300秒内，发生了十次变动，我们就生成一次快照
save 60 10000 //表示在60秒内，发生了一万次变动，我们就生成一次快照
三者条件满足其一就保存一次，他们之间是一个或者的关系，如果三个条件都未满足，这时宕机可能造成数据的丢失。
我们还可以通过进入redis-cli客户端以后，我们手动输入save或者bgsave来生成我们的dump.rdb文件。我们的redis服务端配置是采用bgsave的方式来保存的。我们来看一下save和bgsave的比较。
AOF命令模式
我们为什么成为AOF叫做命令模式呢？我们的AOF其实是保存了我们每一个操作的动作，也就是我们每一个Redis指令，我们只需要设置appendonly yes即可，大概在699行。下面的appendfilename是我们需要保存aof的文件名，rdb中提到的dir对应的也是aof文件的保存路径。这样的持久化，其实也不是每次都要向磁盘写入数据的，他有三个选项供我们来修改。
appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec：每秒 fsync 一次，足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。
大概在728-730行设置这三种策略，默认的每秒一次，也是推荐使用的，三种策略只能选择其中一种生效。一组set testkey testvalue命令大概这样的
我们假象一下输入了一百次incr article:xiaocai命令，我们现在要使用AOF来恢复我们的文件，那么指令incr article:xiaocai就要存储100次，恢复100次，貌似效率不高啊。这里就提到了我们的AOF文件重写。也就是把一些指令重新组合生成新的指令，但保证数据的准确性。我们来看一下，我们先经历三次set命令，key值是一样的，我很容易知道，这里set了三次，但前两次并没有什么卵用，最后一次将我们的值已经覆盖掉了。
127.0.0.1:6379> set xiaocai 123
OK
127.0.0.1:6379> set xiaocai 456
OK
127.0.0.1:6379> set xiaocai 666
OK
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6379>
这时应该生产三条AOF指令，我们来执行我们的AOF重写命令$ BGREWRITEAOF，重写之后，前面的set就不见了，相同键的set，只保留最后一次的set。可能造成乱码（我们5.0.5默认开启了混合模式，后面会说），但是确实压缩了，恢复也是可以成功的。我们来看一下我该掉默认配置后的AOF重写文件。
我们可以看到我们前两条指令被优化去掉了，这也就是我们的AOF重写。
auto-aof-rewrite-min-size 64mb //表示当我们的aof文件达到64M时，我们就重写一次，建议使用默认配置就可以，太多了，重写耗时长，太小了，经常重写，消耗性能。
auto-aof-rewrite-percentage 100 这个表示。//当我们的配置增加了100%我们就重写一次
说到这，两种持久化的方式就都说完了，我们来看一下谁才是王者，谁才是最优质的。
注意：当我们同时开启RDB和AOF时，当我们重启redis时，Redis会优先去加载AOF文件来恢复我们的数据，相对来说AOF的数据更完整
混合模式
重启redis时，我们很少使用RDB来恢复内存数据，因为会丢失大量的数据。通常我们使用AOF指令来恢复，但AOF的性能相比RDB要慢很多，看到这我们还是觉得并没有一种完美的解决方案，来持久化我们的数据，这时Redis4.0就引出了我们混合持久化。我们可以通过设置 # aof-use-rdb-preamble yes来开启我们的混合持久化，这时我们生成的持久化文件内部还是AOF的，但我们重写的时候，会将这些AOF的指令重写为二进制文件。这样我们就综合了RDB和AOF的优势，在恢复数据的时候大部分是执行二进制文件的，小部分来执行我们的AOF指令操作，使我们的恢复数据的效率更高，在备份的时候是以AOF来备份的，也保证了数据的安全性。
总结
这次我们主要说了我们的Redis的内存高性能，Redis在内存来计算的，再就是我们的高级设置keys *（少用或者别用）和我们的scan命令，再就是Redis的持久化，两种RDB和AOF，RDB持久化可能数据丢失，但是二进制文件恢复的快，AOF持久化几乎不会丢数据，但是是指令的模式，恢复数据效率低。由于都有缺点我们引入了混合模式，保存用AOF来存，恢复用RDB+AOF来恢复。再就是一个重点是save和bgsave的区别。记住bgsave是后台执行的，需要fork子进程，消耗内存，但是不阻塞Redis的其它线程。
