redis的一点认知总结

Redis淘汰策略有哪些

默认：noeviction
不驱逐即不删除任何数据，内部不足直接报错
可以从配置文件配置，里面里面有两个非常重要的概念，
一个是LRU，另外一个是LFU
LRU的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
LFU的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

持久化

Redis写内存由主线程来做，写完内存后给客户端返回结果，redis用另外一个线程去写磁盘，这样可避免主线程写磁盘对性能的影响

快照：快照的瞬间，记录某一时刻下redis的数据 也就是持久化方案：RDB AOF
RDB:主进程进行写的操作，fork一个子进程，将上一次持久化后的临时文件替换

​ AOF:每次写操作均持久化到磁盘

AOF瘦身（rewrite）

混合持久化

由主从弊端引出哨兵

​ 哨兵弊端：哨兵询问master时，网络通讯发生问题，哨兵可能会误判

​ 解决：部署多个哨兵，分布在不同机器上，一起监测master的状态

​ 多个哨兵监测流程：

​ 其中一点：一旦有一个哨兵判定master异常，就”询问其他哨兵，若多个哨兵（设置阈值）都认为master判定master异常后，判定master确实发生故障“

​ 问题又来了：哪个哨兵发起主从切换？ ——选举哨兵的领导者——选举

​ 选举规则：分布式系统领域的* 共识算法* ，节点数量必须是奇数 ”为毛是奇数个“？？？？

​

写请求量增长：但我们只有一个master实例，实例达到性能瓶颈---->分片集群

多实例如何组织：
1.每个节点存储一部分数据，所有节点数据之和才是全量数据
2.指定路由规则，对于不同key,路由到固定的一个实例上进行读写

分片集群根据路由规则的不同，还可以分为两大类：客户端分片与服务端分片

客户端分片：

​ 缺点：客户端需要维护路由规则，即把路由规则写到了业务代码，如何规避耦合？–>把路由规则封装成模块，当需要使用时，集成这个模块即可，这就是 Redis Cluster采用的方案（内置了哨兵逻辑，无需再部署哨兵）

服务端分片：

​ 路由规则不放在客户端来做，而是在客户端和服务端之间增加一个【中间代理层】，这个代理就【proxy】,proxy把请求根据路由规则转发到对应redis节点上，，而且当集群实例不足以支撑更大流量请求时，还可横向扩容，添加redis实例

​ 分片集群方案：Codis

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iSj6Khgq-1642986737263)(/Users/zhaoheeeeee/Library/Application Support/typora-user-images/image-20220114101900355.png)]

-------------------新版本控制线------------------------

分片集群（横向扩展）：

​ 一.定义：一个实例扛不住“写”压力，部署多个实例，按照一定规则组织起来作为一个整体

​ 二.规则：
​ 每个节点各自存储一部分数据，所有节点数据之 和为全量数据
​ 制定路由规则，对于不同key，把它路由固定到一个实例上读写

​ 三.分类：根据路由规则所在端的不同，分为：客户端分片 服务端分片

​ 四.客户端分片：使用Redis Cluster SDK

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZpO1cScS-1642986737264)(/Users/zhaoheeeeee/Library/Application Support/typora-user-images/image-20220117175049666.png)]

​ Redis Cluster内置了哨兵逻辑，不用再部署哨兵，且业务应用需要使用配套的Redis SDK(已集成好路由规则)

​ 服务端分片：在客户端和服务端增加一个中间代理层（proxy），路由规则由Proxy维护，常用中间件如Codis

​

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vRkPPwTN-1642986737264)(/Users/zhaoheeeeee/Library/Application Support/typora-user-images/image-20220117175116379.png)]

哨兵：故障自动切换

​

一.作用：监测master的健康状态，若没有哨兵，只能人为手动切主，解决【故障自动切换】

二.演化过程：
1.哨兵每隔一段时间询问master是否正常，若超时异常，及时切主，问题来了？若因网络故障，岂不是哨兵会误判

​ ↓

​ 2.部署多个哨兵，分布于不同机器，一旦有一哨兵判定master异常，则询问其他哨兵，如果多个哨兵（设置阈值）认为master异常，则进行切主

​ ↓

三.哨兵选皇帝

​ **选举规则：**每个哨兵询问其他哨兵，请求对方为自己投票，且只能投给第一次请求的哨兵，首先拿到超过半数票的哨兵将成为leader

​ Raft共识算法选举：分布式系统（多个机器部署哨兵）领域，多个节点就一个问题达成共识的算法

​

四：图解

​

主从复制：多副本

一.作用

1.缩短不可用时间，master宕机，手动切主

2.提升读性能：分担读请求

解决一个实例宕机，只能用数据恢复的弊端

数据持久化：有备无患

RDB：主进程不进行IO操作，几乎不会损失性能，fork子进程将临时文件快照到磁盘，采用二进制＋数据压缩方式存储，文件体积小
AOF：记录每次“写”操作，数据全

混合持久化：aof rewrite时，直接把RDB内容写到AOF文件开头，再把期间产生的写指令追加到AOF文件中
Redis 4.0以上版本支持

​

​