集群的主从切换

主从切换分为两种，一种是主服务器下线，一种是从服务器下线。

• 从服务器下线，一个 从节点下线，可以从主的日志中看到，10秒连接不上，就下线，下线后再上线主向从节点复制数据。其它主从会记录整个集群状态
• 主服务器下线，master一段时间失联，被slave谋朝篡位，当它再回来的时候，只能屈居为一个小小的slave。一个 主节点下线，从节点尝试重连，连到10秒【10次】，认为主节点失败，自己申请成为主节点，主重新连接后成为了slave，已经被改朝换代了。其它主从会记录整个集群状态

以上就是主从切换的场景。

主从复制

在主从切换的过程中使用到了主从复制，数据同步。主从复制有非常重要的作用，和kafka及ES的集群架构本质相同，都是为了三高设计的：

• 读写分离：master写，slave读，提高服务器读写负载能力
• 负载均衡：基于主从结构，配合读写分离，由slave来分担master的负载，并根据需求的变化，弹性扩容slave的数量，通过多节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量。
• 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
• 高可用基石：基于主从复制，构建哨兵模式与集群,实现Redis的高可用方案

了解了主从复制的优势，我们来看看主从复制的实现流程，整体分为三个阶段：建立连接阶段【slave发起】、数据同步阶段【master发起】、命令传播阶段【master和slave互发指令】

建立连接阶段

建立slave到master的连接，使master能够识别slave，并保存slave的端口号。建立连接阶段主要有以下几个步骤：

数据同步阶段

数据同步阶段主要工作就是将master的数据全量的【包含历史数据快照以及同步过程中新进来的指令，也就是RDB和AOF混合模式】同步到slave机器，让他们之间保持数据状态一致，主要流程如下：

数据同步和命令传播阶段的详细实现工作流程如下，第一次slave连接时发送的是psync2 ? -1，拿到runid和offset后即可进行增量的数据请求：

对于Master而言需要注意以下几点数据同步时的场景需求，Master需要进行如下的选择和配置以达到数据同步的最佳状态：

• 同步时机：如果master数量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
• 复制缓冲区设置：复制缓冲区大小设置应合理，否则会导致指令溢出，这种情况下数据可能会丢失，同步到slave的也不全，丢失后必须重新进行RDB，然后指令再溢出，导致陷入死循环，大小可以依据业务场景设置，我这里设置为100m：repl-backlog-size 100mb，具体应该依据业务场景判断
  
• 内存使用设置：master单机内存占用主机内存比例不应过大，建议使用50%-70%的内存，留下30%-50%内存用于执行bgsave命令创建和复制缓冲区

以上就是master部分需要设置的，当然slave也需要做一些设置和配置，Slave需要进行如下的选择和配置以达到数据同步的最佳状态：

• 关闭对外写服务：为避免slave进行全量、部分复制时服务器阻塞，建议slave保持关闭服务状态：slave-server-stale-data no，设置后同步期间外部客户端均不能对slave进行任何操作
• 同步时机：多个slave同时对master请求数据同步，master发送的RDB文件增加，造成带宽冲击，数据同步应错峰执行
• 架构思考：slave过多时，调整拓扑结构为复合架构，多层级架构，这么做可以减少master压力，但需要注意顶层master与底层slave之间的数据同步可能不及时。

以上就是slave部分需要设置和注意的内容

命令传播阶段

数据同步完成后就开始周期性的进行指令的传播，进行反复同步，实际上就是AOF不停的从master发到slave，slave重写指令后执行指令，达到数据复制的目的。需要注意，其实在数据同步阶段的时候命令也在不停的传播，这个过程中是通过心跳检测机制来进行的。

缓存穿透、缓存雪崩、缓存击穿

关于企业级的一些Redis缓存解决方案，包括：缓存预热、缓存雪崩、缓存击穿、缓存穿透，以及一些简单的性能监测指标。依据政策流程以及可能会在什么分支上发生什么灾难，我构建了下列的流程图，正确请求是先从缓存拿数据，拿不到再从数据库里拿。

缓存预热、缓存雪崩、缓存击穿主要原因为频繁访问数据库更新缓存，造成数据库压力过大，而穿透则是因为数据库也没有数据，不停的进行穿透请求，造成Redis服务器和数据库压力均很大。心里有个数后可以详细的看看各种情况及处理手段。

缓存雪崩

缓存雪崩是指缓存中短期内有大批量的key集中过期，而查询数据量巨大，导致短期内应用服务器、数据库、Redis服务器和集群扛不住压力集中宕机。

现象和问题原因

为了便于理解，我将雪崩时的现象和背后的原因做了一个对应关系的展示：

解决方案

其实主要问题就是短时间内key的集中化过期，我们让这些key不集中过期其实就是解决这个问题的关键。

• 调整删除策略，LRU和LFU的删除策略，按照命中次数去进行删除，保留高热数据key
• 稀释数据有效期，对不同的业务数据进行统计和分类错峰过期，错峰使用随机时间实现，稀释key的集中到期数量
• 超热数据使用永久的key
• 定期维护，对即将过期的热点数据进行延时策略，延长过期时间
• 加锁，缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这时过来1000个请求999个都在阻塞的。同样会导致用户等待超时，加锁排队有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！

缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。导致短期内数据库扛不住压力集中宕机

现象和问题原因

为了便于理解，我将击穿时的现象和背后的原因做了一个对应关系的展示：

解决方案

其实主要问题就是单个超热key的高并发访问，我们让超热key不过期其实就是解决这个问题的关键。

• 预先设定超热Key，对此类Key设置长期Key并追加延时策略【后台开启定时任务刷新有效期】
• 临时设置永久Key，访问业务量短期内激增的时候，临时设置为永久Key保证不过期
• 加分布式锁，防止被击穿，其实就是降低对数据库的访问压力，但整体依然是阻塞的。

简单地来说，加分布式锁就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是在获取到锁后再进行操作。

缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，数据库的压力骤增。 导致短期内数据库扛不住压力宕机

现象和问题原因

为了便于理解，我将穿透时的现象和背后的原因做了一个对应关系的展示：

解决方案

其实主要问题就是大量请求对数据库击穿，我们让请求到不了数据库就行了：

• 缓存null，如果一个查询返回的数据为空（无论是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。问题是：空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间（最长不超过五分钟），让其自动剔除。还有就是缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象
• 白名单策略，提前预热所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力
• 实时监控，实时监控redis命中率中null的占比，平时监测一个数量，如果超过多少倍就认定有攻击，增加黑名单策略
• key加密，防止黑客知道哪些key不存在，让key加密。

以上就是整个缓存穿透的一个解决方案

行文至此，已洋洋洒洒7万言，关于Redis的知识要点都已在此做了重点说明，看此一篇基本就能上手Redis了。希望与诸君在学习和进步的路上越走越远。