Redis4 渐进式遍历/自定义客户端/持久化

1.渐进式遍历

1.keys *一次性把所有的key都获取到.但是存在一个问题,一旦数据过多,redis就会被阻塞住,就无暇顾及其他的命令,这样的影响很大.

2.那么就出现了渐进式遍历,可以做到既能获取所有的key,又不会阻塞服务器.渐进式不是一个命令把所有的key获取到,而是没执行一次命令只获取其中的一部分,这样保证当前一次操作不会数据过多导致redis阻塞.

SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]

cursor:为上次遍历到哪里,输入0表示为最前面开始遍历,在客户端看来是无意义的

count:遍历的建议次数,默认为10

pattern:匹配模式

type:key类型

返回值有两个,一个是cursor光标位置,二个为多组key

渐进式遍历,在遍历过程中,不会在服务器这边的存储任何的状态信息,遍历可随时终止,不会对服务器产生任何作用.渐进式遍历中对数据进行操作,那么此时就会出现数据变化的问题,需要小心.

2.数据库管理

redis有16个数据库,每一个数据库都与其他的隔离,即数据不会相互影响.下标范围为[0,15]

SELECE n:切换数据库

DBSIZE:当前数据库中key的个数

FLUSHHALL:删全部库 --- 不可以乱用,谨慎仔细

FLUSHHDB:删当前库

3.自定义Redis客户端

Redis在应用协议层,需要自定义支持,传输层基于TCP,但是不与TCP强耦合.

需要知道Redis应用层协议,才能对服务端进行通信

Redis应用层协议 RESP

port:6379

通信模型:请求与响应的一问一答形式

优点:1.简单 2.进行快速解析 3.肉眼可读

客户端发送给服务器redis命令

4.持久化

1.持久化:就是将数据存储到硬盘上

2.redis是一个内存数据库, 是把数据存储在内存中.为了让redis持久化,我们将redis数据存储到硬盘上.

3.redis优势就是由于内存存储提供的效率,为了保证数据快,数据还得存储在内存上,为了持久化redis将数据存储在硬盘上.那redis的策略就是将内存与硬盘都存储数据,并且两份数据在理论上完全相同.当新数据来时,内存和硬盘可通过决策进行写入数据

4.查询某个数据从内存中拿取,而硬盘的数据只在redis重启时,硬盘的数据恢复内存的数据.代价就是空间消耗更大,因为存储了两份.不过硬盘的价格不贵,成本不会过高

持久化策略

1.RDB -- 定期拷贝,到达设定时间时,将redis内存的数据拷贝到硬盘上

2.AOF -- 定时拷贝,redis内存修改就立即对硬盘进行更新

RDB(Redis DataBase)

1.RDB定期将redis的内存所有数据,都写入到硬盘上,形成一个"快照".redis存储当前的文件放到磁盘.

2.如果磁盘上面没有原来的文件,那么直接将该"快照"命名为配置默认名字的rdb文件 ; 如果磁盘上面存储着原来的文件,那么此时先存储为临时文件,快照生成完毕后,删除之前rdb文件,将临时文件重命名为rdb文件

3.RDB有两种操作.一是自动触发,二是手动触发

手动触发:需要用户手动进行手动执行命令

1.save:执行save时,redis专注执行快照生成操作,此时就会阻塞redis的其他进程.此时就会出现redis卡死,MySQL抗压的操作,不建议使用

2.bgsave:不影响redis服务器处理其他客户端的请求和指令.redis通过多进程实现高并发,

bgsave过程介绍:判断当前是否存在其他子进程进行工作,存在其他进程在bgsave,那直接返回;没有其他子进程,则fork生成子进程,用于写文件操作生成"快照".父进程(redis服务器)继续正常服务,子进程结束会发送给父进程,父进程更新信息,子进程删除

自动触发:即在配置文件中设置何条件下触发rdb

1.在配置文件中先设置存储在哪个路径,并且其文件名为什么.

2.该rdb文件的内容为二进制存储.二进制存储的好处是可以压缩数据,节省一些空间.不过二进制的问题就是格式,如果格式错误,重启时就会读取不出来,那redis就会直接退出.redis提供rdb工具redis-check-rdb进行检测格式问题

3.触发条件,在文件中格式为:save <second> <changes>,其含义为之后当second和changes条件同时满足才触发自动的rdb,second时间后,changes改变keys的次数.一般该设置为长时间改变几次次数或者短时间大量改变key的次数,因为该rdb策略生成快照成本高,不可以太频繁改变

4.通过shutdown来关闭(正常关闭)redis服务器,也会触发save生成新rdb文件

5.redis进行主重复制时,主节点也会自动生成rdb文件,然后将rdb文件传输给从节点

6.如果kill命令关闭(异常关闭)redis服务器,那么就不会生成新rdb文件,未保存的数据自然就丢失了

总结:

1.RDB是压缩的二进制文件,适用于拷贝和全量复制的场景

2.由于其二进制方式的存储,使得其可以直接读取到内存中,只需要按照字节格式就能放到对象中,比起AOF是使用文本方式存储数据的,需要对字符串进行切割.所以redis的RDB回复比AOF快

3.RDB的save阻塞redis,而bgsave要fork创造子进程,属于重量级操作,频繁操作则成本很高

4.RDB有不同版本二进制文件,会使得不同环境出现兼容性问题.如果真出现这个问题,需要将数据取出插入新redis服务器中

5.最大问题其实是两次快照之间可能会出现异常退出,那么当前新数据会在重启后丢失

AOF(Append Only File)

以独立日志的⽅式记录每次写命令，重启时再重新执⾏ AOF ⽂件中的命令达到恢复数据的⽬的。AOF 的主要作⽤是解决了数据持久化的实时性，⽬前已经是Redis 持久化的主流⽅式理解掌握好 AOF 持久化机制对我们兼顾数据安全性和性能⾮常有帮助。

注意:需要在配置文件确认使用AOF机制优先级:AOF>RDB

1.缓冲区

其实当前还有一个问题,AOF写内存,也写硬盘啊.会不会使得效率变低呢?其实不会

1.AOF机制并非直接让工作线程写到磁盘上去,而是写到内存中的缓冲区,积累一波后再存到硬盘中

2.硬盘上的读写数据,顺序读写速度比较快,AOF就是顺序读写策略

2.缓冲区刷新策略

alway:只要变更就刷新缓冲区,性能最低,数据可靠性最高

everysec:每秒刷新缓冲区,性能一般,数据可靠度一般.默认策略

no:不提供刷新策略,让操作系统来刷新,数据可靠度最低,性能高

3.AOF重写机制

问题:

1.AOF在不断更新新数据,体积不断变大.空间的问题只需要硬盘大就能解决

2.但redis的启动时间会由于体积变大而变久

3.AOF的内容有很多是冗余的.我们要的其实不是中间过程,而是最终结果

重写机制 -- 手动触发和自动触发

1.手动触发: 调用 bgrewriteaof 命令

2.自动触发: 根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定⾃动触发时机.auto-aof-rewrite-min-size:表示触发重写时AOF的最小⽂件大小，默认为 64MB;auto-aof-rewrite-percentage：代表当前 AOF占用⼤⼩相⽐较上次重写时增加的⽐例.

bgrewriteao的步骤:

1.父进程继续进行其他操作,子进程重写.之前的重写还在进行,那当前的子进程就会退出;如果正在执行rdb,那么就会等待rdb结束再进行aof重写

2.重写只关心内存最终状态,子进程只要把内存的数据取出来,以AOF文件存储

3.子进程创建AOF文件同时,父进程增加新数据,那么就是对旧AOF文件进行写入[3.1这条路].该功能是防止极端情况,redis在子进程重写时异常退出,新数据在重启时需要从 旧AOF文件中读取

4.子进程的AOF是fork之前的数据,而父进程后续修改的,其实子进程不知道.父进程的aof_rewrite_buf缓冲区,专门放fork后的数据[3.2]

5.子进程的AOF文件写好发送信号通知父进程,随后父进程的 aof_rewrite_buf缓冲区内容也写入新AOF文件[5.1,4,5.2]

混合持久化

RDB的数据可靠度不太高,AOF的文本文件后续加载成本高

redis引入混合持久化,即按照aof的方式,每一个请求更新一次,一旦aof触发重写,就会将rdb的二进制格式写入到aof文件中,后续的更新操作,追加到aof文件后面