集群的主从切换
主从切换分为两种，一种是主服务器下线，一种是从服务器下线。
- 从服务器下线，一个 从节点下线，可以从主的日志中看到，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了。希望与诸君在学习和进步的路上越走越远。
