缓存设计1、缓存的收益和成本2、缓存更新策略2.1、LRU/LFU/FIFO算法剔除2.2、超时剔除2.3、主动更新2.4、最佳实践3、缓存粒度控制4、穿透优化4.1、缓存空对象4.2、布隆过滤器拦截4.3、两种方案对比5、无底洞优化5.1、串行命令5.2、串行IO5.3、并行IO5.4、hash_tag实现6、雪崩优化7、热点key重建优化7.1、互斥锁(mutex key)7.2、永远不过期1、缓存的收益和成本下图左侧为客户端直接调用存储层的架构右侧为比较典型的缓存层存储层架构下面分析一下缓存加入后带来的收益和成本。收益如下加速读写因为缓存通常都是全内存的例如Redis、Memcache​而存储层通常读写性能不够强悍例如MySQL​通过缓存的使用可以有效地加速读写优化用户体验。降低后端负载帮助后端减少访问量和复杂计算例如很复杂的SQL语句​在很大程度降低了后端的负载。成本如下数据不一致性缓存层和存储层的数据存在着一定时间窗口的不一致性时间窗口跟更新策略有关。代码维护成本加入缓存后需要同时处理缓存层和存储层的逻辑增大了开发者维护代码的成本。运维成本以Redis Cluster为例加入后无形中增加了运维成本。缓存的使用场景基本包含如下两种开销大的复杂计算以MySQL为例子一些复杂的操作或者计算例如大量联表操作、一些分组计算​如果不加缓存不但无法满足高并发量同时也会给MySQL带来巨大的负担。加速请求响应即使查询单条后端数据足够快例如select*from table where id​那么依然可以使用缓存以Redis为例子每秒可以完成数万次读写并且提供的批量操作可以优化整个IO链的响应时间。2、缓存更新策略缓存中的数据通常都是有生命周期的需要在指定时间后被删除或更新这样可以保证缓存空间在一个可控的范围。但是缓存中的数据会和数据源中的真实数据有一段时间窗口的不一致需要利用某些策略进行更新。下面将分别从使用场景、一致性、开发人员开发/维护成本三个方面介绍三种缓存的更新策略。2.1、LRU/LFU/FIFO算法剔除使用场景。剔除算法通常用于缓存使用量超过了预设的最大值时候如何对现有的数据进行剔除。例如Redis使用maxmemory-policy这个配置作为内存最大值后对于数据的剔除策略。一致性。要清理哪些数据是由具体算法决定开发人员只能决定使用哪种算法所以数据的一致性是最差的。维护成本。算法不需要开发人员自己来实现通常只需要配置最大maxmemory和对应的策略即可。开发人员只需要知道每种算法的含义选择适合自己的算法即可。2.2、超时剔除使用场景。超时剔除通过给缓存数据设置过期时间让其在过期时间后自动删除例如Redis提供的expire命令。如果业务可以容忍一段时间内缓存层数据和存储层数据不一致那么可以为其设置过期时间。在数据过期后再从真实数据源获取数据重新放到缓存并设置过期时间。例如一个视频的描述信息可以容忍几分钟内数据不一致但是涉及交易方面的业务后果可想而知。一致性。一段时间窗口内取决于过期时间长短存在一致性问题即缓存数据和真实数据源的数据不一致。维护成本。维护成本不是很高只需设置expire过期时间即可当然前提是应用方允许这段时间可能发生的数据不一致。2.3、主动更新使用场景。应用方对于数据的一致性要求高需要在真实数据更新后立即更新缓存数据。例如可以利用消息系统或者其他方式通知缓存更新。一致性。一致性最高但如果主动更新发生了问题那么这条数据很可能很长时间不会更新所以建议结合超时剔除一起使用效果会更好。维护成本。维护成本会比较高开发者需要自己来完成更新并保证更新操作的正确性。2.4、最佳实践下表给出了缓存的三种常见更新策略的对比。有两个建议低一致性业务建议配置最大内存和淘汰策略的方式使用。高一致性业务可以结合使用超时剔除和主动更新这样即使主动更新出了问题也能保证数据过期时间后删除脏数据。3、缓存粒度控制下图是很多项目关于缓存比较常用的选型缓存层选用Redis存储层选用MySQL。例如现在需要将MySQL的用户信息使用Redis缓存可以执行如下操作从MySQL获取用户信息select*fromuserwhereid{id}将用户信息缓存到Redis中setuser:{id}select * from user where id{id}假设用户表有100个列需要缓存到什么维度呢缓存全部列setuser:{id}select * from user where id{id}缓存部分重要列setuser:{id}select {importantColumn1}, {important Column2} … {importantColumnN} from user where id{id}上述这个问题就是缓存粒度问题究竟是缓存全部属性还是只缓存部分重要属性呢下面将从通用性、空间占用、代码维护三个角度进行说明。通用性。缓存全部数据比部分数据更加通用但从实际经验看很长时间内应用只需要几个重要的属性。空间占用。缓存全部数据要比部分数据占用更多的空间可能存在以下问题全部数据会造成内存的浪费。全部数据可能每次传输产生的网络流量会比较大耗时相对较大在极端情况下会阻塞网络。全部数据的序列化和反序列化的CPU开销更大。代码维护。全部数据的优势更加明显而部分数据一旦要加新字段需要修改业务代码而且修改后通常还需要刷新缓存数据。下表给出缓存全部数据和部分数据在通用性、空间占用、代码维护上的对比开发人员可以酌情选择。缓存粒度问题是一个容易被忽视的问题如果使用不当可能会造成很多无用空间的浪费网络带宽的浪费代码通用性较差等情况需要综合数据通用性、空间占用比、代码维护性三点进行取舍。4、穿透优化缓存穿透是指查询一个根本不存在的数据缓存层和存储层都不会命中通常出于容错的考虑如果从存储层查不到数据则不写入缓存层如图所示整个过程分为如下3步缓存层不命中。存储层不命中不将空结果写回缓存。返回空结果。缓存穿透将导致不存在的数据每次请求都要到存储层去查询失去了缓存保护后端存储的意义。缓存穿透问题可能会使后端存储负载加大由于很多后端存储不具备高并发性甚至可能造成后端存储宕掉。造成缓存穿透的基本原因有两个。第一自身业务代码或者数据出现问题第二一些恶意攻击、爬虫等造成大量空命中。下面我们来看一下如何解决缓存穿透问题。4.1、缓存空对象如图所示当第2步存储层不命中后仍然将空对象保留到缓存层中之后再访问这个数据将会从缓存中获取这样就保护了后端数据源。缓存空对象会有两个问题第一空值做了缓存意味着缓存层中存了更多的键需要更多的内存空间如果是攻击问题更严重​比较有效的方法是针对这类数据设置一个较短的过期时间让其自动剔除。第二缓存层和存储层的数据会有一段时间窗口的不一致可能会对业务有一定影响。例如过期时间设置为5分钟如果此时存储层添加了这个数据那此段时间就会出现缓存层和存储层数据的不一致此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。下面给出了缓存空对象的实现代码Stringget(Stringkey){// 从缓存中获取数据StringcacheValuecache.get(key);// 缓存为空if(StringUtils.isBlank(cacheValue)){// 从存储中获取StringstorageValuestorage.get(key);cache.set(key,storageValue);// 如果存储数据为空需要设置一个过期时间(300秒)if(storageValuenull){cache.expire(key,60*5);}returnstorageValue;}else{// 缓存非空returncacheValue;}}4.2、布隆过滤器拦截如图所示在访问缓存层和存储层之前将存在的key用布隆过滤器提前保存起来做第一层拦截。例如一个推荐系统有4亿个用户id每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中但是最新的用户由于没有历史行为就会发生缓存穿透的行为为此可以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户id不存在那么就不会访问存储层在一定程度保护了存储层。有关布隆过滤器的相关知识可以参考https://en.wikipedia.org/wiki/Bloom_filter可以利用Redis的Bitmaps实现布隆过滤器GitHub上已经开源了类似的方案可以进行参考https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter。这种方法适用于数据命中不高、数据相对固定、实时性低通常是数据集较大的应用场景代码维护较为复杂但是缓存空间占用少。4.3、两种方案对比前面介绍了缓存穿透问题的两种解决方法实际上这个问题是一个开放问题有很多解决方法​下面通过下表从适用场景和维护成本两个方面对两种方案进行分析。5、无底洞优化2010年Facebook的Memcache节点已经达到了3000个承载着TB级别的缓存数据。但开发和运维人员发现了一个问题为了满足业务要求添加了大量新Memcache节点但是发现性能不但没有好转反而下降了当时将这种现象称为缓存的“无底洞”现象。那么为什么会产生这种现象呢通常来说添加节点使得Memcache集群性能应该更强了但事实并非如此。键值数据库由于通常采用哈希函数将key映射到各个节点上造成key的分布与业务无关但是由于数据量和访问量的持续增长造成需要添加大量节点做水平扩容导致键值分布到更多的节点上所以无论是Memcache还是Redis的分布式批量操作通常需要从不同节点上获取相比于单机批量操作只涉及一次网络操作分布式批量操作会涉及多次网络时间。下图展示了在分布式条件下一次mget操作需要访问多个Redis节点需要多次网络时间。命令本身的优化例如优化SQL语句等。减少网络通信次数。降低接入成本例如客户端使用长连/连接池、NIO等。这里我们假设命令、客户端连接已经为最优重点讨论减少网络操作次数。以Redis批量获取n个字符串为例有三种实现方法如图所示。5.1、串行命令由于n个key是比较均匀地分布在Redis Cluster的各个节点上因此无法使用mget命令一次性获取所以通常来讲要获取n个key的值最简单的方法就是逐次执行n个get命令这种操作时间复杂度较高它的操作时间n次网络时间n次命令时间网络次数是n。很显然这种方案不是最优的但是实现起来比较简单如图所示。Jedis客户端示例代码如下ListStringserialMGet(ListStringkeys){// 结果集ListStringvaluesnewArrayListString();// n次串行getfor(Stringkey:keys){StringvaluejedisCluster.get(key);values.add(value);}returnvalues;}5.2、串行IORedis Cluster使用CRC16算法计算出散列值再取对16383的余数就可以算出slot值同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系有了这两个数据就可以将属于同一个节点的key进行归档得到每个节点的key子列表之后对每个节点执行mget或者Pipeline操作它的操作时间node次网络时间n次命令时间网络次数是node的个数整个过程如图所示很明显这种方案比第一种要好很多但是如果节点数太多还是有一定的性能问题。MapString,StringserialIOMget(ListStringkeys){// 结果集MapString,StringkeyValueMapnewHashMapString,String();// 属于各个节点的key列表,JedisPool要提供基于ip和port的hashcode方法MapJedisPool,ListStringnodeKeyListMapnewHashMapJedisPool,ListString();// 遍历所有的keyfor(Stringkey:keys){// 使用CRC16本地计算每个key的slotintslotJedisClusterCRC16.getSlot(key);// 通过jedisCluster本地slot-node映射获取slot对应的nodeJedisPooljedisPooljedisCluster.getConnectionHandler().getJedisPoolFromSlot(slot);// 归档if(nodeKeyListMap.containsKey(jedisPool)){nodeKeyListMap.get(jedisPool).add(key);}else{ListStringlistnewArrayListString();list.add(key);nodeKeyListMap.put(jedisPool,list);}}// 从每个节点上批量获取这里使用mget也可以使用pipelinefor(EntryJedisPool,ListStringentry:nodeKeyListMap.entrySet()){JedisPooljedisPoolentry.getKey();ListStringnodeKeyListentry.getValue();// 列表变为数组String[]nodeKeyArraynodeKeyList.toArray(newString[nodeKeyList.size()]);// 批量获取可以使用mget或者PipelineListStringnodeValueListjedisPool.getResource().mget(nodeKeyArray);// 归档for(inti0;inodeKeyList.size();i){keyValueMap.put(nodeKeyList.get(i),nodeValueList.get(i));}}returnkeyValueMap;}5.3、并行IO此方案是将方案2中的最后一步改为多线程执行网络次数虽然还是节点个数但由于使用多线程网络时间变为O(1)这种方案会增加编程的复杂度。它的操作时间为max_slow(node网络时间)n次命令时间整个过程如图所示。Jedis客户端示例代码如下只需要将串行IO变为多线程MapString,StringparallelIOMget(ListStringkeys){// 结果集MapString,StringkeyValueMapnewHashMapString,String();// 属于各个节点的key列表MapJedisPool,ListStringnodeKeyListMapnewHashMapJedisPool,ListString();…和前面一样// 多线程mget最终汇总结果for(EntryJedisPool,ListStringentry:nodeKeyListMap.entrySet()){// 多线程实现}returnkeyValueMap;}5.4、hash_tag实现Redis Cluster的hash_tag功能它可以将多个key强制分配到一个节点上它的操作时间1次网络时间n次命令时间如图所示。如图所示所有key属于node2节点。Jedis客户端示例代码如下ListStringhashTagMget(String[]hashTagKeys){returnjedisCluster.mget(hashTagKeys);}上面已经对批量操作的四种方案进行了介绍最后通过下表来对四种方案的优缺点、网络IO次数进行一个总结。6、雪崩优化下图描述了什么是缓存雪崩由于缓存层承载着大量请求有效地保护了存储层但是如果缓存层由于某些原因不能提供服务于是所有的请求都会达到存储层存储层的调用量会暴增造成存储层也会级联宕机的情况。缓存雪崩的英文原意是stampeding herd奔逃的野牛​指的是缓存层宕掉后流量会像奔逃的野牛一样打向后端存储。预防和解决缓存雪崩问题可以从以下三个方面进行着手。保证缓存层服务高可用性。和飞机都有多个引擎一样如果缓存层设计成高可用的即使个别节点、个别机器、甚至是机房宕掉依然可以提供服务例如前面介绍过的Redis Sentinel和Redis Cluster都实现了高可用。依赖隔离组件为后端限流并降级。无论是缓存层还是存储层都会有出错的概率可以将它们视同为资源。作为并发量较大的系统假如有一个资源不可用可能会造成线程全部阻塞(hang)在这个资源上造成整个系统不可用。降级机制在高并发系统中是非常普遍的比如推荐服务中如果个性化推荐服务不可用可以降级补充热点数据不至于造成前端页面是开天窗。在实际项目中我们需要对重要的资源例如Redis、MySQL、HBase、外部接口都进行隔离让每种资源都单独运行在自己的线程池中即使个别资源出现了问题对其他服务没有影响。但是线程池如何管理比如如何关闭资源池、开启资源池、资源池阀值管理这些做起来还是相当复杂的。这里推荐一个Java依赖隔离工具Hystrix(https://github.com/netflix/hystrix)如图所示。Hystrix是解决依赖隔离的利器但是该内容已经超出本书的范围同时只适用于Java应用所以这里不会详细介绍。提前演练。在项目上线前演练缓存层宕掉后应用以及后端的负载情况以及可能出现的问题在此基础上做一些预案设定。7、热点key重建优化开发人员使用“缓存过期时间”的策略既可以加速数据读写又保证数据的定期更新这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现可能就会对应用造成致命的危害当前key是一个热点key例如一个热门的娱乐新闻​并发量非常大。重建缓存不能在短时间完成可能是一个复杂计算例如复杂的SQL、多次IO、多个依赖等。在缓存失效的瞬间有大量线程来重建缓存如图所示​造成后端负载加大甚至可能会让应用崩溃。要解决这个问题也不是很复杂但是不能为了解决这个问题给系统带来更多的麻烦所以需要制定如下目标减少重建缓存的次数。数据尽可能一致。较少的潜在危险。7.1、互斥锁(mutex key)此方法只允许一个线程重建缓存其他线程等待重建缓存的线程执行完重新从缓存获取数据即可整个过程如图所示。下面代码使用Redis的setnx命令实现上述功能Stringget(Stringkey){// 从Redis中获取数据Stringvalueredis.get(key);// 如果value为空则开始重构缓存if(valuenull){// 只允许一个线程重构缓存使用nx并设置过期时间exStringmutexKeymutext:key:key;if(redis.set(mutexKey,1,ex 180,nx)){// 从数据源获取数据valuedb.get(key);// 回写Redis并设置过期时间redis.setex(key,timeout,value);// 删除key_mutexredis.delete(mutexKey);}// 其他线程休息50毫秒后重试else{Thread.sleep(50);get(key);}}returnvalue;}1)从Redis获取数据如果值不为空则直接返回值否则执行下面的2.1)和2.2)步骤。- 2.1)如果setnx和ex结果为true说明此时没有其他线程重建缓存那么当前线程执行缓存构建逻辑。- 2.2)如果setnx和ex结果为false说明此时已经有其他线程正在执行构建缓存的工作那么当前线程将休息指定时间例如这里是50毫秒取决于构建缓存的速度后重新执行函数直到获取到数据。7.2、永远不过期“永远不过期”包含两层意思从缓存层面来看确实没有设置过期时间所以不会出现热点key过期后产生的问题也就是“物理”不过期。从功能层面来看为每个value设置一个逻辑过期时间当发现超过逻辑过期时间后会使用单独的线程去构建缓存。整个过程如图所示。从实战看此方法有效杜绝了热点key产生的问题但唯一不足的就是重构缓存期间会出现数据不一致的情况这取决于应用方是否容忍这种不一致。下面代码使用Redis进行模拟Stringget(finalStringkey){Vvredis.get(key);Stringvaluev.getValue();// 逻辑过期时间longlogicTimeoutv.getLogicTimeout();// 如果逻辑过期时间小于当前时间开始后台构建if(v.logicTimeoutSystem.currentTimeMillis()){StringmutexKeymutex:key:key;if(redis.set(mutexKey,1,ex 180,nx)){// 重构缓存threadPool.execute(newRunnable(){publicvoidrun(){StringdbValuedb.get(key);redis.set(key,(dbvalue,newLogicTimeout));redis.delete(mutexKey);}});}}returnvalue;}作为一个并发量较大的应用在使用缓存时有三个目标第一加快用户访问速度提高用户体验。第二降低后端负载减少潜在的风险保证系统平稳。第三保证数据“尽可能”及时更新。下面将按照这三个维度对上述两种解决方案进行分析。互斥锁(mutex key)这种方案思路比较简单但是存在一定的隐患如果构建缓存过程出现问题或者时间较长可能会存在死锁和线程池阻塞的风险但是这种方法能够较好地降低后端存储负载并在一致性上做得比较好。“永远不过期”​这种方案由于没有设置真正的过期时间实际上已经不存在热点key产生的一系列危害但是会存在数据不一致的情况同时代码复杂度会增大。两种解决方法对比如表所示。