Redis学习笔记

Redis

1 常见的五种数据结构以及使用场景

string
一般用作一些标识符 比如后管页面的开关 特殊的用法是同步锁setnx

hash key field value

比方说要存储某个指标 这个指标有分为日月年 ,日 月 年就是field

list
有序列表可以当做消息队列 可用用作排行榜

set
去重列表,一般用来存放目录 唯一性

zset
多了一个score属性,可以做很多事情,比如说过期时间,复杂的数据结构没法设置过期时间,可以将系统时间戳当做score,清除指定的score
zset有序,可以提取出指定范围内的数据记录,zrevrangeByScore 设置起始位置0,偏移量

2 Redis为什么会很快?
基于内存
单线程运行
IO多路复用

3 Redis 持久化

持久化方案有两种
	RDB
	
	将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)
	
	手动触发
	触发指令bgsave:创建一个子进程，由子进程来负责创建RDB文件
	
	使用场景:主从复制 全量同步 
	
	自动触发
	save m n 指定当m秒内发生n次变化时，会触发bgsave	
			
	AOF
	记录每个写操作，并追加到文件中
	
	使用场景:主从复制增量同步
	
	比较：

	1、aof文件比rdb更新频率高，优先使用aof还原数据。

	2、aof比rdb更安全也更大

	3、rdb性能比aof好

	4、如果两个都配了优先加载AOF
	
	一般都联合使用确保数据安全

4 Redis 主从复制读写分离 以及哨兵机制
主从复制读写分离 类似mysql

同步方式:
	
	全量
		
	Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下： 
	从服务器连接主服务器，发送SYNC命令； 
	主服务器接收到SYNC命令后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
	主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
	从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 
	主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
	从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
		
	增量
	Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 
	增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

哨兵模式:

	 Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，
	 保证系统的高可用
		
	 工作原理:
	 每秒钟哨兵会去ping 主从服务器以及哨兵,如果在一定时间内有返回那么说明存活,如果没有返回那么当前的机器可能发生
	 了宕机,这时候还不确定,暂时给他标记为下线,但是这是主观上的,要去核实是否真的下线,再找几个兄弟哨兵去探路,继续ping
	 如果好几个哨兵都ping不通,那就说明真的嗝屁了,真的下线了,这时候标记为客观下线。哨兵开始一次自动故障迁移操作.

5 Redis分布式锁 setNx
注意:redis分布式锁有许多的坑,建议使用redis提供的工具
如果是手写代码实现分布式锁,
注意点
1 setnx 的时候将失效时间同时设置,成为一个原子操作,不能先setnx塞值,然后再设置失效时间,如果这样很可能会出现死锁问题,比如你刚上完锁,但是突然程序故障还没来得及设置失效时间就结束了,那么后续的程序将无法获得锁对象
2 解锁的时候需要注意在解锁之前,设置的失效时间突然到期,导致其余的客户端线程获取了锁,这时候解锁,解的就是其余线程的锁,解决方案是判断是不是同一个客户端线程上的锁
3 A先上锁成功,但是这个时候主节点挂了,这时候进行主备恢复,但是从节点没有同步到主节点的数据,因此B节点的视角是没有上锁,AB同时进行处理

参考文献
https://gitchat.youkuaiyun.com/activity/5b3d91c56edf9d4ff8ee21c4?seriesId=5b95d48c780fdb5e97d3848d

使用redis自带的工具Redisson来实现分布式锁

ps:网上的资料也不一定是正确的,使用的时候需要去多思考

6 常见的缓存问题

主要是缓存的功能没有生效,压力全部都转移到数据库上了,引发连锁效应系统崩溃

缓存穿透

缓存雪崩

概念:大批数据同时失效导致查询的压力转义到数据库上
产生原因:大批失效可能有redis宕机,
解决方案:1 主从复制+集群
		 2 快速失败熔断
		 
大批数据失效时间一样 解决方案 失效时间随机性

缓存击穿
概念:缓存中没有但数据库中有的数据 
产生的原因:热点key失效了
解决方案:1互斥更新 
		 2随机退避 
		 3差异失效时间

缓存穿透
概念:缓存和数据库中都没有的数据，而用户不断发起请求
产生原因:恶意攻击
解决方案:1空对象缓存【将查询不到的数据缓存到redis中,value设置为null,缺点是会产生很多无效的空数据】 
		 2 bloomfilter过滤器 存在性检测 过滤器中不存在实际数据肯定不存在 过滤器中存在实际数据可能存在可能不存在
		 3 请求数据进行过滤,加上验证
缓存降级 eg:后管页面设置缓存开关 服务开关

缓存预热

缓存热点

缓存更新方式

缓存不一致

缓存穿透
缓存击穿
缓存雪崩 快速失败熔断 主从模式+集群 缓存服务的高可用,提高容错率

bloomfilter过滤器

互斥更新 随机退避 差异性失效 固定时间来进行操作

cluseter部署的原理

排行榜数据zset

redis在内存中的存储结构

数据失效方式以及剔除策略

持久化 主从同步

redis分布式设计

缓存使用中产生的问题

bitmap 来实现bloomsloter 


Redis的过期机制 有哪些淘汰策略

如何保证Redis的高并发与高可用

劲量避免单个耗时很长的任务

避免CPU密集

禁用swap交换 避免交换到磁盘上

高可用 哨兵模式

读写分离 多从库 多端口实例 集群部署

zset 延时队列 时间戳作为score 
setnx 
zrangbyscore
zrangebyscore

额外的知识点:
redis的事务
通过pipline 组合redis指令 exec批量执行,为了防止网络抖动导致部分redis指令成功,另外一部分失败

redis 同步的实现

redis本身也有类似于java的cas乐观锁 用watch来监听key -value 在事务提交exec检测是否发生改变,如果发生了改变,那么就取消事务,这时候需要重新调用函数重新执行

参考资料
https://www.cnblogs.com/jasonZh/p/9522772.html
https://www.cnblogs.com/liuchuanfeng/p/7190654.html
https://www.cnblogs.com/shamo89/p/8385390.html

三级缓存

参考文献
https://www.cnblogs.com/kevingrace/p/5685332.html
https://blog.youkuaiyun.com/qq_35433716/article/details/82191511