是否可以采用服务熔断、服务降级、请求限流的方法来应对缓存穿透问题？ 我觉得需要区分场景来看。 如果缓存穿透的原因是恶意攻击，攻击者故意访问数据库中不存在的数据。这种情况可以先使用服务熔断、服务降级、请求限流的方式，对缓存和数据库层增加保护，防止大量恶意请求把缓存和数据库压垮。在这期间可以对攻击者进行防护，例如封禁IP等操作。 如果缓存穿透的原因是，业务层误操作把数据从缓存和数据库都删除了，如果误删除的数据很少，不会导致大量请求压到数据库的情况，那么快速恢复误删的数据就好了，不需要使用服务熔断、服务降级、请求限流。如果误操作删除的数据范围比较广，导致大量请求压到数据库层，此时使用服务熔断、服务降级、请求限流的方法来应对是有帮助的，使用这些方法先把缓存和数据库保护起来，然后使用备份库快速恢复数据，在数据恢复期间，这些保护方法可以为数据库恢复提供保障。 还有一种缓存穿透的场景，我们平时会遇到的，和大家分享一下。 对于一个刚上线的新业务模块，如果还没有用户在这个模块内产生业务数据，当用户需要查询这个业务模块自己的数据时，由于缓存和数据库都没有这个用户的数据，此时也会产生缓存穿透，但这种场景不像误删数据和恶意攻击那样，而是属于正常的用户行为。 这种场景采用服务熔断、服务降级、请求限流的方式就没有任何意义了，反而会影响正常用户的访问。这种场景只能使用缓存回种空值、布隆过滤器来解决。 可见，服务熔断、服务降级、请求限流的作用是，当系统内部发生故障或潜在问题时，为了防止系统内部的问题进一步恶化，所以会采用这些方式对系统增加保护，待系统内部故障恢复后，可以依旧继续对外提供服务，这些方法属于服务治理的范畴，在任何可能导致系统故障的场景下，都可以选择性配合使用。 另外，关于文章所讲的由于“Redis缓存实例发生故障宕机”导致缓存雪崩的问题，我觉得一个可以优化的方案是，当Redis实例故障宕机后，业务请求可以直接返回错误，没必要再去请求数据库了，这样就不会导致数据库层压力变大。当然，最好的方式还是Redis部署主从集群+哨兵，主节点宕机后，哨兵可以及时把从节点提升为主，继续提供服务。 关于布隆过滤器的使用，还有几点和大家分享。 1、布隆过滤器会有误判：由于采用固定bit的数组，使用多个哈希函数映射到多个bit上，有可能会导致两个不同的值都映射到相同的一组bit上。虽然有误判，但对于业务没有影响，无非就是还存在一些穿透而已，但整体上已经过滤了大多数无效穿透请求。 2、布隆过滤器误判率和空间使用的计算：误判本质是因为哈希冲突，降低误判的方法是增加哈希函数 + 扩大整个bit数组的长度，但增加哈希函数意味着影响性能，扩大数组长度意味着空间占用变大，所以使用布隆过滤器，需要在误判率和性能、空间作一个平衡，具体的误判率是有一个计算公式可以推导出来的（比较复杂）。但我们在使用开源的布隆过滤器时比较简单，通常会提供2个参数：预估存入的数据量大小、要求的误判率，输入这些参数后，布隆过滤器会有自动计算出最佳的哈希函数数量和数组占用的空间大小，直接使用即可。 3、布隆过滤器可以放在缓存和数据库的最前面：把Redis当作布隆过滤器时（4.0提供了布隆过滤器模块，4.0以下需要引入第三方库），当用户产生业务数据写入缓存和数据库后，同时也写入布隆过滤器，之后当用户访问自己的业务数据时，先检查布隆过滤器，如果过滤器不存在，就不需要查询缓存和数据库了，可以同时降低缓存和数据库的压力。 4、Redis实现的布隆过滤器bigkey问题：Redis布隆过滤器是使用String类型实现的，存储的方式是一个bigkey，建议使用时单独部署一个实例，专门存放布隆过滤器的数据，不要和业务数据混用，否则在集群环境下，数据迁移时会导致Redis阻塞问题。