redis知识

2020-08-17 本文已影响0人任笙_8b8c

redsi不仅仅是单线程的,在6.0之后启动是多线程的,

为什么是多线程的呢?
因为redis的瓶颈不是在cpu上,而是在内存和网咯IO中
如果使用cpu多核,可以搭建多个redis实例来解决.
内存不够可以加内存或者优化数据结构,但是网咯性能优化才是大头,网咯的IO读取在redis的整个执行过程中占大部分的cpu执行时间
如果吧网咯io做成多线程的,reids性能会大大提升.性能测试对比多线程&单线程多线程io速度是单线程的俩倍.

String(字符串)
格式: set key value
redis中的string 是二进制安全的,它可以包含任何数据,比如jpg图片或者序列化的对象。
Hash(哈希)
格式:: hmset name key1 value1 key2 value2
redis的hash是一个键值(key=>value)对集合
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
大Key field(小key) value
list(列表)
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）

格式: lpush name value        在 key 对应 list 的头部添加字符串元素

格式: rpush name value      在 key 对应 list 的尾部添加字符串元素

格式: lrem name indexkey      对应 list 中删除 count 个和 value 相同的元素

格式: llen name      返回 key 对应 list 的长度
set(无序集合)
格式: sadd name value
Redis的Set是string类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
zset(sortset有序集合,分数排序)
格式: zadd name score value
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。

reids是存储在内存中的,redis将数据持久化到磁盘文件中

redis中默认开启的是RDB持久化机制

redsi.png
原理:会单独创建(fork) 一个已当前进行一模一样的子进程来进行持久化,子进程的所有数据都和原进程一一模一样,会将数据先写入到一个临时文件中,待持久化结束了,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程不进行任何的io操作,确保了极高的性能
什么时候frok子进程,什么时候触发rdb持久化
1.sgutdown(正常关机)时如果没有开启aof,会触发
2.配置文件中的快照配置
save 900 1 900秒有一个增删改就触发
save 300 10 900秒有一个增删改就触发
save 60 10000 900秒有一个增删改就触发
关闭rdb持久化
关闭rdb持久化: save "" 或者将save参数删除,如果是主从复制的情况下,rdb持久化关闭不了.
RDB持久化的弊端: 最后一次快照时会造成数据丢失,所有才会有AOF持久化机制

持久化文件appendonly.aof 内容是redis通讯协议(RESP )格式的命令文本存储。一秒一次
RESP 是redis客户端和服务端之前使用的一种通讯协议；
RESP 的特点：实现简单、快速解析、可读性好
"+" 回复
"-" 错误
":" 整数
"$" 字符串
"*" 数组
它的优势: 它丢失数据不会超过俩秒
触发机制:
默认值everysec 一秒一次
no:等操作系统进行数据缓存同步到磁盘(快,持久化没保证)
always:同步持久化,每次发生数据变动,立刻记录到磁盘(性能慢,安全)
aof重写机制
当aof文件增长到一定大小的时候redis能调用bgrewriteaof对日志进行重写(这里指超过原大小的100%)
当aof文件大小的增长率大于该配置时自动开启重写
auto-aof-rewrite-percentage 100
当sof文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb(64兆太小了,一定要改)
redis4.0开启了混合持久化
优点: 混合持久化结合rdb持久化和aof持久化的优点,绝大部分是RDB模式,加载速度快,AOF,增量的数据以AOF方式保存,数据丢失的更少
缺点: 兼容性差,一旦开启了混合模式持久化,在4.0之前版本都不识别该aof文件,由于前部分是rdb性能较差

1.redis提供了rdb持久化为什么还要提供aof持久化?
因为rdb会丢失最后一次快照的数据,aof最多只会丢失不会超过俩秒的数据.
2.如果aof和rdb同时存在听谁的?
aof
3.rdb和aof的优势劣势?
rdb: 适合大规模数据恢复,对数据完整性你和一致性不高,一定时间间隔做一次备份,如果是rdb的话会丢失最后一次快照的数据
aof:根据配置而定
官方建议俩种持久化机制都开启,优先是aof.

RDB&AOF比较：
1、aof文件比rdb更新频率高，优先使用aof还原数据。
2、aof比rdb更安全也更大
3、rdb性能比aof好
4、如果两个都配了优先加载AOF

哨兵和主从 :中小公司
cluster: 大公司
redis主从复制:
是什么?
单机有什么问题? 单机故障,容量瓶颈,qps瓶颈
主机数据更新后根据配置和策略,自动同步到备机的master/slave机制master以写为主,slave(从)读

能干嘛?

哨兵机制:
监控主节点,如果主节点挂了,从节点无法自动切换主机,哨兵解决了,如果主机挂了哨兵会选一个从节点作为主节点.哨兵也搭集群. 依赖主从,先搭建主从环境才能搭建哨兵

set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！

缓存穿透
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

如何避免
1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。
2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。

缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃

如何避免
1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期
3：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。