文章1、缓存透明解决方案1 :缓存空数据使用方法2 :验证拦截方法3 :使用光晕过滤器方法2；缓存破坏解决方案1 :设置热点数据不过期方法2 :应用级别锁定控制的同时使用方法3 3 使用缓存平衡器1 :使用高可用性缓存2 :缓存宕机(虚拟支持)方法3:Redis备份和快速预热4，同时写入缓存和数据库时
一.缓存直通
缓存直通是指既不在缓存中也不在数据库中的数据，用户不断请求源id为-1的数据，以及最大且不存在的数据等。 黑客可能会利用漏洞攻击破坏APP应用程序的数据库。
解决方案对于缓存直通问题，常见的解决方案有以下三种：
监听验证：在界面层进行用户权限验证、ID等字段的基本验证，如直接监听id=0的字段等；
空数据缓存：如果数据库查询检索到的数据为空，则缓存也会缓存此数据，但缓存的有效性会设置得较短，以免影响正常数据的缓存。
布隆过滤器的使用：布隆过滤器是一种比较独特的数据结构，有一定的误差。 数据被指定存在的情况下，它不一定存在；但数据被指定不存在的情况下，它不一定存在。
方案1 )缓存空数据)如果数据库查询检索到的数据为空，也会缓存该数据，但请将缓存的有效性设置得较短，以免影响正常数据的缓存。
好处：
在此方案中，您可以确保一次向数据库发出请求，并阻止后续重复请求，从而轻松直接地实现短缺。
如果攻击提供的查询值不重复，则无法有效缓存持续累积的缓存key，浪费缓存区域的场景2 )验证和验证接口层。 例如，认证用户的权限，基本上验证ID等字段。 例如，id=0的字段直接阻塞。 维护最大id缓存信息，直接拒绝超出的数据
优点：发布内容后，需要保持最大身份信息的实施也相对不简单。 如果在最大id高速缓存中存在初始写入成本恒定的数据查询数据库，以保持一致性(例如并发性和增量性)，例如，只需要满足关键值(例如id信息连续或数据不稀疏的场景)就必须保持最大id 数据被指定存在的情况下，它不一定存在；但数据被指定不存在的情况下，它不一定存在。
bloom过滤器的实现原理也很简单，首先使用多个位而不是HashMap中的数组。 这样做可以确保存储空间。 然后，对Key进行多次散列，将Key散列后的值所对应的bit位置设为1。
在确定某个元素是否存在时，确定这个值散列中的所有比特是否都为1，而如果全部为1，则可以存在也可以不存在(下图f )。 但是，如果有不是1的比特，则这个密钥一定不存在。
注意： bloom过滤器不支持删除操作，仅支持添加操作。 这个很容易理解。 因为要删除数据，相应的bit位的位置必须为0，而与您的Key相对应的bit位也可能与其他Key相对应。
优点：可以使用开源工具类，redis分布式版本空间占有量少。 多次散列性能开销对存在的数据有一定的误判定率。 另外，随着数据的增加，错误判定率需要对存在的数据启动，不能删除热数据。 缓存雪崩二(不适合具有大量数据删除场景的情况)是指，当当前热点数据存储过期时，多个线程同时访问热点数据。 所有并发请求都将向数据库查询数据，因为缓存刚刚过期。 主要是由于数据访问用户同时多发、缓存失效等原因，同时请求同时开始数据库读取操作，数据库压力瞬间增大的情况。
解决方案1 :设置热点数据过期的优势：最简单和不足：需要通过task等其他方式维护数据更新方案2 :应用级别锁定控制并独立运行时，应用级别锁定控制并同时运行
优点：可以减少对并发请求的并发APP应用级别的支持，从而相对容易地实现不足。 未获取锁定的线程被阻止，不适合高速缓存写入等逻辑复杂且耗时的情况3 :使用分布式锁定查询数据库并写入高速缓存的操作请求需要获取分布式锁定
好处：
对数据库的并发请求最小且不足：
引入分布式锁定操作但未能锁定的请求必须定期重试或返回降级的内容。 第三，缓存平衡器缓存平衡器主要对大量缓存同时批量失效，大量查询直接渗透到数据库级，导致CPU和内存过载，损坏数据库。
简单的雪崩过程：
Redis集群发生了大面积的故障； 缓存失败。 此时仍然存在访问Redis缓存服务器的大量请求。大量Redis请求失败后，这些请求将访问数据库。由于APP应用程序的设计依赖于数据库和Redis服务，因此很快会引起服务器群集的雪崩解决方案1 :高可用性缓存高可用性缓存是防止整个缓存出现故障。 即使各个节点、机器甚至机房关闭，系统也可以提供服务，而Redis哨兵(Sentinel )和Redis集群(cluster )可以实现高可用性。
场景2 )缓存降级(临时支持)访问次数很快
剧增加导致服务出现问题时，我们如何确保服务仍然可用。在国内使用比较多的是 Hystrix，它通过熔断、降级、限流三个手段来降低雪崩发生后的损失。只要确保数据库不死，系统总可以响应请求，每年的春节 12306 我们不都是这么过来的吗？只要还可以响应起码还有抢到票的机会； 方案3：Redis 备份和快速预热Redis 数据备份和恢复、快速缓存预热。
四、缓存与数据库双写时的数据一致性你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？
解决方案一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况
串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。