一、缓存设计

（1）缓存更新策略

缓存中的数据通常都是有生命周期的，需要在指定时间后被删除或更新，这样可以保证缓存空间在一个可控的范围。但是缓存中的数据会和数据源中的真实数据有一段时间窗口的不一致，需要利用某些策略进行更新。下面将分别从使用场景、一致性、开发人员开发/维护成本三个方面介绍三种缓存的更新策略。

1.LRU/LFU/FIFO算法剔除 使用场景。剔除算法通常用于缓存使用量超过了预设的最大值时候，如何对现有的数据进行剔除。例如Redis使用maxmemory-policy这个配置作为内存最大值后对于数据的剔除策略。

一致性。要清理哪些数据是由具体算法决定，开发人员只能决定使用哪种算法，所以数据的一致性是最差的。维护成本。算法不需要开发人员自己来实现，通常只需要配置最大maxmemory和对应的策略即可。开发人员只需要知道每种算法的含义，选择适合自己的算法即可。

2.超时剔除 使用场景。超时剔除通过给缓存数据设置过期时间，让其在过期时间后自动删除，例如Redis提供的expire命令。如果业务可以容忍一段时间内，缓存层数据和存储层数据不一致，那么可以为其设置过期时间。在数据过期后，再从真实数据源获取数据，重新放到缓存并设置过期时间。例如一个视频的描述信息，可以容忍几分钟内数据不一致，但是涉及交易方面的业务， 后果可想而知。

一致性。一段时间窗口内（取决于过期时间长短）存在一致性问题，即缓存数据和真实数据源的数据不一致。 维护成本。维护成本不是很高，只需设置expire过期时间即可，当然前提是应用方允许这段时间可能发生的数据不一致。

3.主动更新使用场景。应用方对于数据的一致性要求高，需要在真实数据更新后，立即更新缓存数据。例如可以利用消息系统或者其他方式通知缓存更新。

一致性。一致性最高，但如果主动更新发生了问题，那么这条数据很可能很长时间不会更新，所以建议结合超时剔除一起使用效果会更好。 维护成本。维护成本会比较高，开发者需要自己来完成更新，并保证更新操作的正确性。

（2）缓存粒度

缓存通常有两种选择：缓存全部列和缓存部分重要列究竟是缓存全部属性还是只缓存部分重要属性呢？下面将从通用性、空间占用、代码维护三个角度进行说明。

• 1.通常性。

缓存全部数据比部分数据更加通用，但从实际经验看，很长时间内应用只需要几个重要的属性。

• 2.空间占用。

缓存全部数据要比部分数据占用更多的空间，可能存在以下问题：

-->全部数据会造成内存的浪费。

-->全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在极端情况下会阻塞网络。

-->全部数据的序列化和反序列化的CPU开销更大。

• 3.代码维护。

全部数据的优势更加明显，而部分数据一旦要加新字段需要修改业务代码，而且修改后通常还需要刷新缓存数据。

（3）缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层。

造成缓存穿透的基本原因有两个。

第一，自身业务代码或者数据出现问题。

第二，一些恶意攻击、爬虫等造成大量空命中。下面我们来看一下如何解决缓存穿透问题。

• 1.缓存空对象

当存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，这样就保护了后端数据源。

• 2.布隆过滤器拦截

在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截。例如：一个推荐系统有4亿个用户id，每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可 以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户id不存在，那么就不会访问存储层，在一定程度保护了存储层。

（4）缓存雪崩

什么是缓存雪崩：由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。缓存雪崩的英文原意是stampeding herd（奔逃的野牛），指的是缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储。

预防和解决缓存雪崩问题，可以从以下三个方面进行着手。

1）保证缓存层服务高可用性。和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的Redis Sentinel和Redis Cluster都实现了高可用。

2）依赖隔离组件为后端限流并降级。无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部阻塞（hang）在这个资源上，造成整个系统不可用。降级机制在高并发系统中是非常普遍的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开 天窗。在实际项目中，我们需要对重要的资源（例如Redis、MySQL、HBase、外部接口）都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管理，比如如何关闭资源池、开启资源池、资源池阀值管理，这些做起来还是相当复杂的。这里推荐一个Java依赖隔离工具Hystrix（https://github.com/netflix/hystrix）。

3）提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

二、主从复制

1、配置与复制过程

主从复制过程：

1.保存主节点信息

2.从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。

3.发送ping命令

4.权限验证

5.同步数据集

6.命令持续复制

配置复制的三种方法：

1）在配置文件中加入slaveof{masterHost}{masterPort}随Redis启动生效。

2）在redis-server启动命令后加入--slaveof{masterHost}{masterPort}生效。

redis-cli redis-6380 --slaveof 127.0.0.1 6379

3）直接使用命令：slaveof{masterHost}{masterPort}生效。

redis-cli -p 6380 
slaveof 127.0.0.1 6379

断开复制连接，使用slaveof no one命令

slaveof no one

2、心跳机制

主从心跳判断机制：

1）主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令查看复制相关客户端信息，主节点的连接状态为flags=M，从节点连接状态为flags=S。

2）主节点默认每隔10秒对从节点发送ping命令，判断从节点的存活性和连接状态。可通过参数replping-slave-period控制发送频率。

3）从节点在主线程中每隔1秒发送replconf ack{offset}命令，给主节点上报自身当前的复制偏移量。replconf命令主要作用如下：

--->实时监测主从节点网络状态。

--->上报自身复制偏移量，检查复制数据是否丢失，如果从节点数据丢失，再从主节点的复制缓冲区中拉取丢失数据。

--->实现保证从节点的数量和延迟性功能，通过min-slaves-to-write、minslaves-max-lag参数配置定义。主节点根据replconf命令判断从节点超时时间，体现在info replication统计中的lag信息中，lag表示与从节点最后一次通信延迟的秒数，正常延迟应该在0和1之间。

如果超过repl-timeout配置的值（默认60秒），则判定从节点下线并断开复制客户端连接。即使主节点判定从节点下线后，如果从节点重新恢复，心跳检测会继续进行。

3、哨兵

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。

整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。

Sentinel节点的启动方法有两种：

方法一，使用redis-sentinel命令：

redis-sentinel redis-sentinel-26379.conf

方法二，使用redis-server命令加--sentinel参数：

redis-server redis-sentinel-26379.conf --sentinel

sentinel配置说明

1.sentinel monitor

sentinel monitor <master-name> <ip> <port> <quorum> 
Sentinel节点会定期监控主节点，所以从配置上必然也会有所体现，本配置说明Sentinel节点要监控的是一个名字叫做<master-name>，ip地址和端口为<ip><port>的主节点。 
<quorum>代表要判定主节点最终不可达所需要的票数

2.sentinel down-after-milliseconds

sentinel down-after-milliseconds <master-name> <times> 
每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达， 如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，<times> （单位为毫秒）就是超时时间。这个配置是对节点失败判定的重要依据。

3.sentinel parallel-syncs

sentinel parallel-syncs <master-name> <nums> 
当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的 主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之 后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节点会向新的主节点同时发起复 制操作，尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制，必然会对主节点所在的机器造 成一定的网络和磁盘IO开销。

4.sentinel failover-timeout

sentinel failover-timeout <master-name> <times> 
failover-timeout通常被解释成故障转移超时时间

5.sentinel auth-pass

sentinel auth-pass <master-name> <password> 
如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止 Sentinel节点对主节点无法监控。

6.sentinel notificaton-script

sentinel notification-script <master-name> <script-path> 
sentinel notification-script的作用是在故障转移期间，当一些警告级别的Sentinel事件发生 （指重要事件，例如-sdown：客观下线、-odown：主观下线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。

7.sentinel client-reconfig-script

sentinel client-reconfig-script <master-name> <script-path> 
sentinel client-reconfig-script的作用是在故障转移结束后，会触发对应路径的脚本，并向脚本 发送故障转移结果的相关参数。和notification-script类似，可以在/opt/redis/scripts/下配 置了client-reconfig.sh，该脚本会接收每个Sentinel节点传过来的故障转移结果参数，并触发类似 短信和邮件报警。