缓存

1. 描述

缓存能够说是无处不在，好比PC电脑中的内存、CPU中的二级缓存、HTTP协议中的缓存控制、CDN加速技术都是使用了缓存的思想来解决性能问题。

缓存是用于解决高并发场景下系统的性能及稳定性问题的银弹。

 1.1 缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存和数据源都不会命中。出于容错的考虑，若是从数据层查不到数据则不写入缓存，即数据源返回值为null时，不缓存null。缓存穿透问题可能会使后端数据负载加大，因为不少后端数据源不具有高并发性，甚至可能形成后端数据源宕机。

为了解决这个问题，通常建议（1）减小回源请求并发数，下降数据源的负载（2）将null值进行缓存，可是为了不数据不一致和没必要要的内存占用，建议缩短缓存过时时间，并增长相关的主动删除缓存功能。

2. 缓存设计的核心要素

2.1 容量规划

• 缓存内容的大小
• 缓存内容的数量
• 淘汰机制
• 缓存的数据结构
• 每秒的读峰值
• 每秒的写峰值

（1）缓存系统主要消耗的是服务器的内存，所以，在使用缓存时必需要先对应用须要缓存的数据大小进行评估，包括缓存的数据结构、缓存大小、缓存数量、缓存的失效时间，而后根据业务状况自行推算在将来一段时间内的容量的使用状况，根据容量评估的结果来申请和分配缓存资源，不然会形成资源浪费或者缓存空间不够。

（2）缓存通常是用来加速数据库的读操做的，通常先访问缓存后访问数据库，因此缓存的超时时间的设置是很重要的。笔者曾经在一家互联网公司遇到过因为运维操做失误致使缓存超时设置得较长，从而拖垮服务的线程池，最终致使服务雪崩的状况。

（3）任何缓存的key都必须设定缓存失效时间，且失效时间不能集中在某一点（能够经过增长随机时间），不然会致使缓存占满内存或者缓存雪崩。

（4）低频访问的数据不要放在缓存中，如咱们前面所说的，咱们使用缓存的主要目的是提升读取性能。

（5）缓存的数据不易过大，尤为是Redis，由于Redis使用的是单线程模型，在单个缓存key的数据过大时，会阻塞其余请求的处理。

（6）对于存储较多value的key，尽可能不要使用HGETALL等集合操做，该操做会形成请求阻塞，影响其余应用的访问。

（7）缓存通常用于在交易系统中加速查询的场景，有大量的更新数据时，尤为是批量处理时，请使用批量模式，可是这种场景较少。

（8）在一般状况下，读的顺序是先缓存，后数据库；写的顺序是先数据库，后缓存。

（9）在使用本地缓存（如Ehcache）时，必定要严格控制缓存对象的个数及声明周期。因为JVM的特性，过多的缓存对象会极大影响JVM的性能，甚至致使内存溢出等。

2.2 性能优化

• 线程模型
• 预热方法
• 缓存分片
• 冷热数据的比例

（1）若是对性能的要求不是很是高，则尽可能使用分布式缓存，而不要使用本地缓存，由于本地缓存在服务的各个节点之间复制，在某一时刻副本之间是不一致的，若是这个缓存表明的是开关，并且分布式系统中的请求有可能会重复，就会致使重复的请求走到两个节点，一个节点的开关是开，一个节点的开关是关，若是请求处理没有作到幂等，就会形成处理重复，在严重状况下会形成资金损失。

2.3 高可用

• 复制模型
• 失效转移
• 持久策略
• 缓存重建

（1）建议将使用缓存的业务进行分离，核心业务和非核心业务使用不一样的缓存实例，从物理上进行隔离，若是有条件，则请对每一个业务使用单独的实例或集群，以减小应用之间相互影响的可能性。笔者就常常据说有的公司应用了共享数据，形成缓存数据被覆盖以及缓存数据错乱的线上事故。

（2）咱们不推荐多个业务共享一个缓存实例，可是因为成本控制的缘由，这种状况常常出现，咱们须要经过规范来限制各个应用使用的key有惟一的前缀，并进行隔离设计，避免产生缓存互相覆盖的问题。

（3）在写缓存时必定要写入彻底正确的数据，若是缓存数据的一部分有效、一部分无效，则宁肯放弃缓存，也不要把部分数据写入缓存，不然会形成空指针、程序异常等。

（4）在使用缓存时，必定要有降级处理，尤为是对关键的业务环节，缓存有问题或者失效时也要能回源到数据库进行处理。

2.4 缓存监控

• 缓存服务监控
• 缓存容量监控
• 缓存请求监控
• 缓存响应时间监控

（1）全部的缓存实例都须要添加监控，这是很是重要的，咱们须要对慢查询、大对象、内存使用状况作可靠的监控。

2.5 注意事项

• 是否有可能发生缓存穿透
• 是否有大对象
• 是否使用缓存实现分布式锁
• 是否使用缓存支持的脚步
• 是否避免了Race Condition

3. 常见缓存问题集锦

3.1 某应用程序的数据库负载瞬时升高

缘由：在应用程序中对使用的大量缓存key设置了同一个固定的失效时间，当缓存失效时，会形成在一段时间内同时访问数据库，形成数据库的压力较大。

总结：在使用缓存时须要进行缓存设计，要充分考虑如何避免常见的缓存穿透、缓存雪崩、缓存并发等问题，尤为是对于高并发的缓存使用，须要对key的过时时间进行随机设置，例如，将过时时间设置为10秒+random(2)，也就是将过时时间随机设置成10～12秒。

 3.2 致使迁移先后两个系统的核心操做重复

缘由：在迁移的过程当中，重复的流量进入了不一样的节点，因为使用了本地缓存存储迁移开关，而迁移开关在开关打开的瞬间致使各个节点的开关状态不一致，有的是开、有的是关，因此对于不一样节点的流量的处理重复，一个走了开关开的逻辑，一个走了开关关的逻辑。

总结：避免使用本地缓存来存储迁移开关，迁移开关应该在有状态的订单上标记。

3.3 模块设计使用了缓存加速数据库的读操做的性能，但发现数据库负载并无明显降低

缘由：因为这个模块的使用方查询请求的数据在数据库中不存在，是非法的数据，因此致使缓存没有命中，每次都穿透到数据库，且量级较大。

总结：在使用缓存时须要进行缓存设计，要充分考虑如何避免常见的缓存穿透、缓存雪崩、缓存并发等问题，尤为是对高并发的缓存使用，须要对无效的key进行缓存，以抵挡恶意的或者无心的对无效缓存查询的攻击或影响。

 3.4 监控系统报警，Redis中单个哈希键占用的空间巨大

缘由：应用系统使用了哈希键，哈希键自己有过时时间，可是哈希键里面的每一个键值对没有过时时间。

总结：在设计Redis的过程当中，若是有大量的键值对要保存，则请使用字符串键的数据库类型，并对每一个键都设置过时时间，请不要在哈希键内部存储一个没有边界的集合数据。实际上，不管是对缓存、内存仍是对数据库的设计，若是使用任意一个集合的数据结构，则都要考虑为它设置最大限制，避免内存用光，最多见的是集合溢出致使的内存溢出的问题。

3.5 某业务项目因为缓存宕机致使业务逻辑中断，数据不一致

缘由：Redis进行主备切换，致使瞬间内应用链接Redis异常，应用并无对缓存作降级处理。

总结：对于核心业务，在使用缓存时必定要有降级方案。常见的降级方案是在数据库层次预留足够的容量，在某一部分缓存出现问题时，可让应用暂时回源到数据库继续业务逻辑，而不该该中断业务逻辑，可是这须要严格的容量评估，请参考《分布式服务架构：原理设计与实战》第3章的内容。

3.6 某应用系统负载升高，响应变慢，发现应用进行频繁GC，甚至出现OutOfMemroyError: GC overhead limt exceed的错误日志

缘由：由于这个项目是个历史项目，使用了Hibernate ORM框架，在Hibernate中开启了二级缓存，使用了Ehcache；可是在Ehcache中没有控制缓存对象的个数，缓存对象增多，致使内存紧张，因此进行了频繁的GC操做。

总结：使用本地缓存（如Ehcache、OSCache、应用内存）时，必定要严格控制缓存对象的个数及声明周期。

3.7 某个正常运行的应用忽然报警线程数太高，以后很快就出现了内存溢出

现象：某个正常运行的应用忽然报警线程数太高，以后很快就出现了内存溢出。

缘由：因为缓存链接数达到最大限制，应用没法链接缓存，而且超时时间设置得较大，致使访问缓存的服务都在等待缓存操做返回，因为缓存负载较高，处理不完全部的请求，可是这些服务都在等待缓存操做返回，服务这时在等待，并无超时，就不能降级并继续访问数据库。这在BIO模式下线程池就会撑满，使用方的线程池也都撑满；在NIO模式下同样会使服务的负载增长，服务响应变慢，甚至使服务被压垮。

总结：在使用远程缓存（如Redis、Memcached）时，必定要对操做超时时间进行设置，这是很是关键的，通常咱们设计缓存做为加速数据库读取的手段，也会对缓存操做作降级处理，所以推荐使用更短的缓存超时时间，若是必定要给出一个数字，则但愿是100毫秒之内。

3.8 某项目使用缓存存储业务数据，上线后出现错误问题，开发人员一筹莫展

缘由：开发人员不知道如何发现、排查、定位和解决缓存问题。

总结：在设计缓存时要有降级方案，在遇到问题时首先使用降级方法，还要设计完善的监控和报警功能，帮助开发人员快速发现缓存问题，进而来定位和解决问题。

3.9 某项目在使用缓存后，开发测试经过，到生产环境后，服务却出现了不可预知的问题

缘由：该应用的缓存key与其余应用缓存 key冲突，致使互相覆盖，出现逻辑错误。

总结：在使用缓存时必定要有隔离的设计，能够经过不一样的缓存实例来作物理隔离，也能够经过各个应用的缓存key使用不一样的前缀进行逻辑隔离。

 

x. 参考资料

http://www.sohu.com/a/224864978_411876