redis简介

Redis是一个完全开源的内存数据结构存储工具，它支持多种数据结构，以及多种功能。Redis还提供了持久化功能，可以将数据存储到磁盘上，以便在重启后恢复数据。由于其高性能、可靠性和灵活性，Redis被广泛应用于缓存、会话管理、排行榜、实时分析、消息队列等领域。

应用场景

缓存
数据共享
分布式锁
计数器
限流
时间轴
消息队列
注册中心
排行榜
标签
。。。。。

redis的四大模式

单机模式
主从模式
哨兵模式
集群模式

单机模式

单机模式就是只在一台服务器上搭建单台redis服务，所有业务都通过该服务处理缓存等业务

读写不分离。

优点：

部署非常简单，单台服务器安装配置启动即可，好维护
性能高，数据处理速度快，不需要同步数据
成本相对非常低，不管是维护成本和服务器成本都是单项，没有其它开支

缺点：

单台服务器受限cpu的处理能力
海量数据存储问题
Redis不具备自动容错和恢复功能，不保证数据的可靠性

主从模式

主从模式是指有多台redis服务器，其中一台为主服务，其它都为从服务，主服务只负责写入数据以及向从服务器发送同步最新的数据，从服务只负责复制主服务的数据与来自客户端读取数据

优点：

读写分离，主写从读，可以根据访问量多少来定制从节点数量
数据冗余，主从复制实现了对数据的热备份
可用性，多节点提供服务时，其中一台宕机后，其它服务仍旧可以提供服务
故障恢复，可以快速提升从服务为主服务
负载均衡，多节点分摊数据访问压力

缺点：

主服务宕机后，从服务需要升级为主服务，需要手动切换，部分数据不能及时同步从服务，造成数据不一致
从服务宕机恢复后，大量的同步给主服务造成一定的IO压力
主从服务只有一个主服务，写数据的能力会收到单机的限制
海量数据存储限制

主从复制原理

全量复制

从服务连接到主服务，便开始进行数据同步，从节点发送psync命令给到主节点（psync包含两个参数runID主库的id以及offset进度位置）

1.runID为实例启动自动生成的随机标识，当从服务第一次连接主服务是不知道
主服务的runID的实际值，从而把runID设置为"?"对主服务进行询问，得到主服
务给的回答后，后续便会把runID设置成主服务的实际值

2.offset表示为同步进度的标识，第一次从服务连接主服务时，该标识为表示以
前从未有复制过主服务的数据，把该值设置为-1，主从都各自维护自己的主从复
制偏移量offset，当主节点有写入命令时，offset=offset+命令的字节长度。
从节点在收到主节点发送的命令后，也会增加自己的offset，并把自己的offset
发送给主节点。这样，主节点同时保存自己的master_repl_offset，从节点的
slave_repl_offset，通过对比offset来判断主从节点数据是否一致

主服务收到psync命令之后，判断是否为第一次复制是的话返回FULLRESYNC {runId} {offset}，如果回复 +CONTINUE，触发部分复制。
从服务收到主服务给过来的信息后，将信息保存到info中
主服务发送FULLRESYNC后，执行 bgsave命令，生成RDB快照并将其发给从库，在从服务加载数据期间主服务写命令放入缓冲区replication buffer
从服务清理自己的数据，完成后开始加载RDB文件，将数据提取到自己的内存中
待从节点加载完成后，会将replication buffer中产生的该写操作发送给从服务
主从之间维护一个长连接，后续涉及到改/写的动作，主服务会比较offset给从服务发送增量数据给从服务同步

增量/部分复制

当从节点出现不可以预知的中断时，主服务会把收到的改/写等操作命令写入环形缓冲区主服务会记录自己所在的偏移位置，从服务也会有自己已经读到的进度偏移位置
从服务器恢复连接后，从服务会重新发送自己的psync，这时候offset是自己的偏移位置，给主服务比较，如果刚好存在缓冲区内，主服务会将增量数据发送给从服务
如果不存在，则需要进行再一次全量更新

哨兵模式

优点：

读写分离，主写从读，可以根据访问量多少来定制从节点数量
数据冗余，主从复制实现了对数据的热备份
可用性，多节点提供服务时，其中一台宕机后，其它服务仍旧可以提供服务
故障恢复，当主服务宕机时通过自定选举提升从服务为主服务，弥补了主从模式下的手动操作
负载均衡，多节点分摊数据访问压力

缺点：

从服务宕机恢复后，大量的同步给主服务造成一定的IO压力
主从服务只有一个主服务，写数据的能力会收到单机的限制
海量数据存储限制

主要功能

建立集群监控，负责监控主从服务是否正常工作
如果某个服务宕机，哨兵间传递消息
自动故障转移，当主服务宕机后，会重新在从服务之间选举出新主

主服务看成执政的皇帝，从服务堪称国家的储君，当主服务还在执政期间，从服务都要好好配合皇帝工作，而哨兵就像是太医院，时刻关注着皇帝与皇子的身体健康，当检查到从服务不健康时，就直接把它除名告知天下，当检查到主服务不健康宕机了之后，当即会告知天下，然后在剩下的皇子中选举出新皇，然后安排新皇登基，其它皇子重新辅助新皇，而旧皇医治好后(重新上线)，也只能承认失去皇权，也只能退居二线，重新辅佐新皇但是重新享有皇位继承权

集群模式

不管上面的主从还是哨兵模式，都无法解决单节点写操作的问题。如果这时写操作的并发比较高。这是可以实验集群化模式【去中心化模式】

优点

无中心架构，支持动态扩容
Cluster自动具备哨兵监控和故障转移（主从切换）能力
客户端连接集群内部地址可自动发现
高性能、高可用，有效解决了Redis分布式需求

缺点

不支持原子操作：在Redis集群中，不同节点之间的数据访问会出现延迟，因此不支持原子操作，可能会导致数据的不一致性。
需要配置复杂：Redis集群需要配置投票数、数据分片等参数，增加了配置的复杂度。
高成本：Redis集群需要多台服务器运行，因此需要更多的硬件成本和维护成本。

只有主节点故障才需要故障转移。cluster集群模式不需要哨兵，自身已具备了故障转移功能。

节点通信：

Redis 集群中的节点通过 Gossip 协议进行通信。节点之间定期交换有关其自身状态和已知其他节点的信息，以便检测故障并作出相应调整。

故障检测：

每个节点向集群中其它节点每隔一定时间发送ping消息，如果该节点没在规定时间内返回pong消息，就会认为下线

故障转移步骤：

1. 集群中的其他节点会检测到主节点已下线。
2. 资格检查每个从节点都要检查最后与主节点断线时间，判断是否有资格替换故障的主节点
3. 准备选举时间从节点符合故障转移资格后，更新触发故障选举时间，只有到达该时间才能执行后续流程。采用延迟触发机制，主要是对多个从节点使用不同的延迟选举时间来支持优先级。复制偏移量越大说明从节点延迟越低，那么它应该具有更高的优先级。
4. 选举投票只有持有槽的主节点才会处理故障选举消息，每个持有槽的节点在一个配置纪元内都有唯一的一张选票，当接到第一个请求投票的从节点消息，回复消息作为投票，之后相同配置纪元内其它从节点的选举消息将忽略。投票过程其实是一个领导者选举的过程。
5. 替换主节点当前从节点取消复制变为主节点，撤销故障主节点负责的槽，把这些槽委派给自己，并向集群广播告知所有节点当前从节点变为主节点。