Redis【超全笔记 看完必懂 待更新】

Redis【超全笔记 看完必懂 待更新】

一、思考

redis是什么

• Rdies 是K-V的数据库

• 单线程（原子性），因此它是线程安全的

• 大量的操作都是在内存中完成，读写效率高，广泛用于缓存

• 并发量非常大的时候 可以作为中间件缓存 降低数据库的压力

• 不适合存储大文件 理论上每个key-value不能超过512MB

演化之路

单机版的Redis

假设有一个App 引入了Redis做缓存提高性能

把 Redis 当做缓存来使用，从 MySQL 中查询数据，然后写入到 Redis 中，之后业务应用再从 Redis 中读取这些数据，由于 Redis 的数据都存储在内存中，所以这个速度飞快

数据持久化

假设当业务变多，极其依赖Redis缓存，Redis因各种原因宕机，所有业务流量全部打向Mysql，Mysql也有可能宕机

解决方案：重启Redis

如若没有数据持久化 Redis所有数据存在缓存 即便重启 所有业务流量还是会打到Mysql

将数据一份写到缓存 一份也写到磁盘 Redis重启则快速读取磁盘恢复数据 Redis则可以正常提供服务

将内存数据写到磁盘的过程就是【数据持久化】

AOF

Redis 每一次执行写操作，除了写内存之外，同时也写一份到磁盘上

既写内存 又写磁盘 这样肯定会影响Redis性能 为了提升效率 分析内存数据写到磁盘 分2步

1. 程序写文件的 PageCache（write）

2. 把 PageCache 刷到磁盘（fsync）

写入磁盘的速度拖慢了

优化：Redis 写内存由主线程来做，写内存完成后就给客户端返回结果，然后 Redis 用「另一个线程」去写磁盘，这样就可以避免主线程写磁盘对性能的影响。

Redis AOF 持久化提供了 3 种刷盘机制：

1. appendfsync always：主线程同步 fsync
2. appendfsync no：依赖操作系统自动 fsync
3. appendfsync everysec：后台线程每间隔1秒 fsync

AOF 瘦身

随着时间 AOF越来越大 恢复速度变慢 压缩AOF的体积

例如执行 set k1 v1，set k1 v2，其实我们只关心数据的最终版本 v2 就可以了

ROB 快照

记录某一时刻下 Redis 中的数据，然后只需要把这个数据快照写到磁盘上就可以了

优点：

1. 持久化文件体积小（二进制 + 压缩）
2. 写盘频率低（定时写入）

缺点：因为是定时持久化，数据肯定没有 AOF 实时持久化完整，如果你的 Redis 只当做缓存，对于丢失数据不敏感（可从后端的数据库查询），那这种持久化方式是非常合适的

混合持久化

同时使用RDB和AOF两种持久化方式的一种配置方式

可以在保证数据安全性和恢复速度的同时，兼顾了RDB的快速恢复和AOF的实时操作记录

这样可以使Redis在各种故障情况下更具弹性和可靠性

持久化选择

1. 业务对于数据丢失不敏感，选 RDB
2. 业务对数据完整性要求比较高，选 AOF
3. 具弹性和可靠性 选混合持久化

主从复制：多副本

Redis宕机 恢复不管时间多少 期间是无法提供服务的 只能用恢复数据解决 思考一下 我们如部署多个实例 实例之间保持数据同步 宕机一个 手动从剩下的选择一个继续提供服务

实时读写的节点叫做 master 另一个实时同步数据的节点叫做 slave

优点：

1. 缩短不可用时间：master 发生宕机，我们可以手动把 slave 提升为 master 继续提供服务
2. 提升读性能：让 slave 分担一部分读请求，提升应用的整体性能

哨兵：故障自动切换

主从复制比恢复数据快上很多 但需人工介入 人工的时间 业务还是会受到影响 切换过程变为自动化？

创建哨兵 实时检测master健康状态：

1. 哨兵每间隔一段时间，询问 master 是否正常
2. master 正常回复，表示状态正常，回复超时表示异常
3. 哨兵发现异常，发起主从切换
   

一个哨兵 网络问题可能会误判 部署多个哨兵 在不同的机器上 一起检测master

1. 多个哨兵每间隔一段时间，询问 master 是否正常
2. master 正常回复，表示状态正常，回复超时表示异常
3. 一旦有一个哨兵判定 master 异常（不管是否是网络问题），就询问其它哨兵，如果多个哨兵（设置一个阈值）都认为 master 异常了，这才判定 master 确实发生了故障
4. 多个哨兵经过协商后，判定 master 故障，则发起主从切换

由哪个哨兵发起主从切换？制定这样一个选举规则：

1. 每个哨兵都询问其它哨兵，请求对方为自己投票
2. 每个哨兵只投票给第一个请求投票的哨兵，且只能投票一次
3. 首先拿到超过半数投票的哨兵，当选为领导者，发起主从切换

这个选举的过程：分布式系统领域中的「共识算法」

容错性和高可用性，建议至少部署三个以上的哨兵节点 奇数个节点

分片集群：横向扩展

小结

Redis 从最简单的单机版，经过数据持久化、主从多副本、哨兵集群，这一路优化下来， Redis 不管是性能还是稳定性，都越来越高，就算节点发生故障，也不用担心了。

Redis 以这样的架构模式部署，基本上就可以稳定运行很长时间了。

1. 数据怕丢失：持久化（RDB/AOF）
2. 恢复时间久：主从副本（副本随时可切）
3. 手动切换时间长：哨兵集群（自动切换）
4. 读存在压力：扩容副本（读写分离）
5. 写存在压力：一个 mater 扛不住怎么办？