redis个人笔记

一:NoSQL

Not-Only SQL(泛指非关系型的数据库),作为关系型数据库的补充
作用:应对海量数据的处理问题
特征:可扩容,可伸缩,大数据量下高性能(内存性能比磁盘io性能快),数据模型灵活(自己有数据存储格式以保证效率),高可用(支持集群),这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
常见的Nosql数据库:Redis,memcache,HBase,MongoDB

二:Redis概念与特征与应用场景

Redis:是用C语言开发的一个开源高性能键值对数据库
特征:
1)数据间没有必然的关联关系
2)内部单线程
3)高性能
4)支持多数据类型(5种)
字符串 ,string
列表,list,
哈希,hash
集合类型set
有序集合类型zset/sorted_set
地理 geo
统计 HyperLogLog
位图 Bitmap
5)支持持久化
应用场景:
1)热点数据
2)及时信息查询(在线人数)
3)时效性信息控制(验证码,投票)
4)分布式数据共享(分布式集群架构中的session
分离消息队列)

三:线程

Redis 5 之前 是有多线程机制 : 处理用户指令一个线程,备份等另外的线程在处理
Redis 6 处理用户指令引入多线程机制

四:数据类型

set key value 与set key1 value1 key2 value2(单指令与多指令):差别是发送次数的多少.
当影响的数据比较少的时候.可以用单指令也可以用多指令,
当数据量大就选择多指令

五:持久化

什么是持久化:利用永久性存储介质将数据进行保存,在特定时间将保存的数据进行恢复的工作为持久化
持久化过程保存什么?
1)将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据
2)将数据的操作过程保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程
4.1ROB把内存中的最终数据放入硬盘

save

1.设置本地数据库文件名,默认值为dump.rdb，通常设置为dump-端口号.rdb

dbfilename filename

设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

dir path

设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大

rdbcompression yes|no

设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险

rdbchecksum yes|no

注意:save是单线程的工作模式,会非常耗时

bgsave:

后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

stop-writes-on-bgsave-error yes|no

其 他

dbfilename filename  
dir path  
rdbcompression yes|no  
rdbchecksum yes|no

这是主流方案,bgsave分2个过程,1是服务端拿到指令直接告诉客户端开始执行了,2是子进程完成后端的保存操作,操作玩后回个消息

配置自动放行:

设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

save second changes

参数

second：监控时间范围

changes：监控key的变化量

范例：

save 900 1
save 300 10
save 60 10000

其他相关配置：

dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no

save配置工作原理

RDB优点:
1)存储效率高,二进制文件
2)内部是数据的快照,非常适合用于数据备份,全量复制
3)恢复数据速度比AOF快
4)服务器每X小时执行bgsave备份,将RDB文件拷贝到远程机器中
RDB缺点
1)无论是执行命令还是利用配置,无法做到实时持久化
2)bgsave要执行fork操作创建子进程,牺牲性能
3)版本太多不易兼容

4.2AOF把执行的指令存储
以日志方式记录每次写命令,重启时再查询执行AOF文件中的命令达到恢复数据的目的
由记录数据改为记录数据产生的变化
主流方式

启动AOF相关配置

开启AOF持久化功能，默认no，即不开启状态

appendonly yes|no

AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

appendfilename filename

AOF持久化文件保存路径，与RDB持久化文件保持一致即可

dir

AOF写数据策略，默认为everysec

appendfsync always|everysec|no

AOF执行策略
always(每次):写入操作都同步到AOF文件中性能低
everysec(每秒):每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高，性能较高，建议使用，也是默认配置
no(系统控制):由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF重写
:将Redis进程中数据转化为写命令同步到AOF文件的过程
就是对同一个数据的若干命令执行结果转化为最终结果数据对应的指令进行记录

AOF重写作用
1)降低磁盘占用率
2)提高持久化效率,提高io
3)降低数据恢复用时,提高恢复效率

AOF重写规则
1)进程内具有时效性的数据,并且数据已超时不写如文件
2)非写入类的无效指令将被忽略,只保留最终数据的写入命令
3)合并对同一数据的多条命令

AOF重写方式
手动重写

bgrewriteaof

手动重写原理分析：

自动重写

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

自动重写触发条件设置

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent

自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）

aof_current_size  
aof_base_size

自动重写触发条件公式：

AOF工作流程及重写流程

RDB与AOF区别

RDB与AOF应用场景
对数据非常敏感，建议使用默认的AOF持久化方案:

AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。

注意：由于AOF文件存储体积较大，且恢复速度较慢

数据呈现阶段有效性，建议使用RDB持久化方案:

数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案

注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：

如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF

如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB

灾难恢复选用RDB

双保险策略，同时开启 RDB和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

未完待续1111111111111111111111