高并发/高可用/哨兵机制/集群模式/高可用与主备切换/主从复制/断点续传
高并发
单机的 Redis，能够承载的 QPS大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。
高可用
Redis哨兵集群实现高可用，哨兵是一个分布式系统,你可以在一个架构中运行多个哨兵进程,这些进程使用流言协议来接收关于主节点是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个备节点作为新的主节点。每个哨兵会向其它哨兵、主节点、备节点定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂.若“哨兵群”中的多数哨兵,都报告某一主节点没响应,系统才认为该主节点"彻底死亡",通过算法,从剩下的备节点中,选一台提升为主节点,然后自动修改相关配置。
哨兵机制
哨兵是一个分布式系统，你可以在一个架构中运行多个哨兵进程，这些进程使用流言协议来接收关于主节点是否下线的信息，并使用投票协议来决定是否执行自动故障迁移，以及选择哪个备节点作为新的主节点。每个哨兵会向其它哨兵、主节点、备节点定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂。
若“哨兵群”中的多数哨兵，都报告某一主节点没响应，系统才认为该主节点"彻底死亡"，通过算法，从剩下的备节点中，选一台提升为主节点，然后自动修改相关配置。可以通过修改sentinel.conf配置文件，配置主节点名称，IP，端口号，选举次数，主服务器的密码，心跳检测毫秒数，做多少个节点等。
Redis 哨兵主备切换的数据丢失问题
异步复制导致的数据丢失
master->slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了。 脑裂导致的数据丢失：某个 master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master还运行着。此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个master ，也就是所谓的脑裂。 此时虽然某个 slave 被切换成了 master，但是可能 client 还没来得及切换到新的master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client写入的数据，因此，这部分数据也就丢失了
解决方案：
进行配置：min-slaves-to-write 1 min-slaves-max-lag 10
通过配置至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒，超过了master 就不会再接收任何请求了。
减少异步复制数据的丢失
一旦 slave 复制数据和 ack 延时太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样可以把 master宕机时由于部分数据未同步到 slave 导致的数据丢失降低的可控范围内。 减少脑裂的数据丢失：如果一个 master 出现了脑裂，跟其他slave 丢了连接，如果不能继续给指定数量的slave 发送数据，而且 slave 超过10 秒没有给自己ack消息，那么就直接拒绝客户端的写请求。因此在脑裂场景下，最多就丢失10 秒的数据。
集群模式
数据量很少的情况下，比如你的缓存一般就几个 G，单机就足够了，可以使用 replication，一个 master 多个 slaves，要几个 slave 跟你要求的读吞吐量有关，然后自己搭建一个 sentinel 集群去保证 Redis 主从架构的高可用性。
海量数据+高并发+高可用的场景的情况下，使用Redis cluster ，自动将数据进行分片，每个 master 上放一部分数据，它支撑 N个 Redis master node，每个 master node 都可以挂载多个 slave node。 这样整个 Redis就可以横向扩容了，如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master节点就能存放更多的数据了。而且部分 master 不可用时，还是可以继续工作的。
在 Redis cluster 架构下，使用cluster bus 进行节点间通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了一种二进制的协议， gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。
集群协议
集群元数据的维护：集中式、Gossip 协议
集中式
集中式是将集群元数据（节点信息、故障等等）几种存储在某个节点上。集中式元数据集中存储的一个典型代表，就是大数据领域的 storm。它是分布式的大数据实时计算引擎，是集中式的元数据存储的结构，底层基于zookeeper对所有元数据进行存储维护。集中式的好处在于，元数据的读取和更新，时效性非常好，一旦元数据出现了变更，就立即更新到集中式的存储中，其它节点读取的时候就可以感知到；不好在于，所有的元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。
gossip 协议
gossip 协议，所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，就不断将元数据发送给其它的节点，让其它节点也进行元数据的变更。gossip好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续打到所有节点上去更新，降低了压力；不好在于，元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。
在 Redis cluster 架构下，每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，每个 Redis 要放开两个端口号，比如 7001，那么用于节点间通信的就是 17001 端口，17001端口号是用来进行节点间通信的，也就是 cluster bus 的东西。每个节点每隔一段时间都会往另外几个节点发送 ping 消息，同时其它几个节点接收到 ping 之后返回 pong 。
Redis cluster 的高可用与主备切换原理
如果一个节点认为另外一个节点宕机，这是属于主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是客观宕机，跟哨兵的原理几乎一样，sdown，odown。流程为：如果一个节点认为某个节点pfail 了，那么会在 gossip ping 消息中， ping 给其他节点，如果超过半数的节点都认为 pfail 了，那么就会变成fail 。 每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。所有的 master node 开始 slave 选举投票，给要进行选举的slave 进行投票，如果大部分 master node （N/2 + 1） 都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。从节点执行主备切换，从节点切换为主节点。
主从复制原理
当启动一个slave node的时候，它会发送一个psync命令给master node，如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization。开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
主从架构下的数据部分复制（断点续传）
当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。
总结
以上就是今天要讲的内容，还希望各位读者大大能够在评论区积极参与讨论，给文章提出一些宝贵的意见或者建议📝，合理的内容，我会采纳更新博文，重新分享给大家。
