实际开发时redis缓存穿透出现的几率大吗

如题，实际开发时redis缓存穿透出现的几率大吗，按我的理解，一般缓存穿透都是服务器受到了恶意攻击，请求的数据在redis不存在，并且数据库里也不存在，这种实际开发被恶意攻击出现的几率大吗

有帮助的话 采纳一下呦
在实际的开发中,Redis 缓存穿透出现的概率其实不是很大。
主要原因如下:

1. 绝大多数情况下,系统中的数据查询请求都是合法的,不会有大量对不存在数据的查询。即使偶尔出现少量不存在的键查询,也不会对系统产生实质影响。
2. 对于可能存在缓存穿透问题的关键数据查询,一般都会在业务代码中增加校验逻辑,比如先查询数据库判断数据是否存在,不存在的请求直接返回,不再继续查询缓存和数据库。
3. 对于一个规模较大的系统,会使用网关、WAF、防火墙等技术进行安全防护,可以防止恶意攻击导致的缓存穿透。
4. 即使出现了某些缓存穿透的情况,也可以通过Redis的限流、阈值报警等机制来防止问题进一步扩大。
5. 业界也有比较成熟的解决缓存穿透的方案可供选择,比如设置缓存空值、布隆过滤器等。
   所以在系统设计得当的情况下,Redis缓存穿透出现的可能性并不高。相比之下,更多需要注意的是其他缓存问题,如缓存击穿、缓存雪崩等场景的预防。总体来说,缓存穿透不太可能是一个严重或经常性的问题。

• 帮你找了个相似的问题, 你可以看下: https://ask.csdn.net/questions/688091
• 我还给你找了一篇非常好的博客，你可以看看是否有帮助，链接：redis缓存穿透,瞬间并发,缓存雪崩的解决方法,、缓存预热、缓存更新、缓存降级
• 除此之外, 这篇博客: 10分钟彻底理解Redis持久化和主从复制中的 但是，在如今的大多数服务器架构中，Redis 不单单只是扮演一个缓存服务器的角色，还可以作为数据库，保存我们的业务数据，此时，我们则需要好好了解有关 Redis 持久化策略的区别与选择。 部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读:
  

• 什么是 Reids 主从复制？

  上面，我们了解了 Redis 两种不同的持久化方式，Redis 服务器通过持久化，把 Redis 内存中持久化到硬盘当中，当 Redis 宕机时，我们重启 Redis 服务器时，可以由 RDB 文件或 AOF 文件恢复内存中的数据。
  不过持久化后的数据仍然只在一台机器上，因此当硬件发生故障时，比如主板或 CPU 坏了，这时候无法重启服务器，有什么办法可以保证服务器发生故障时数据的安全性？或者可以快速恢复数据呢？

  想做到这一点，我们需要再了解 Redis 另外一种机制：主从复制。

  Redis 的主从复制机制是指可以让从服务器（Slave）能精确复制主服务器（Master）的数据，如下图所示：

  

  上面的图表示的是一台 Master 服务器与 Slave 服务器的情况，其实一台 Master 服务器也可以对应多台 Slave 服务器，如下图所示：

  

  另外，Slave 服务器也可以有自己的 Slave 服务器，这样的服务器称为 Sub-Slave。

  而这些 Sub-Slave 通过主从复制最终数据也能与 Master 保持一致，如下图所示：

  

  主从复制的方式和工作原理

  
  Redis 的主从复制是异步复制，异步分为两个方面：

  • 一个是 Master 服务器在将数据同步到 Slave 时是异步的，因此 Master 服务器在这里仍然可以接收其他请求。

  • 一个是 Slave 在接收同步数据也是异步的。

  ①复制方式

  
  Redis 主从复制分为以下三种方式：

  • 当 Master 服务器与 Slave 服务器正常连接时，Master 服务器会发送数据命令流给 Slave 服务器，将自身数据的改变复制到 Slave 服务器。

  • 当因为各种原因 Master 服务器与 Slave 服务器断开后，Slave 服务器在重新连上 Master 服务器时会尝试重新获取断开后未同步的数据即部分同步，或者称为部分复制。

  • 如果无法部分同步（比如初次同步），则会请求进行全量同步，这时 Master 服务器会将自己的 RDB 文件发送给 Slave 服务器进行数据同步，并记录同步期间的其他写入，再发送给 Slave 服务器，以达到完全同步的目的，这种方式称为全量复制。

  ②工作原理

  
  Master 服务器会记录一个 Replication Id 的伪随机字符串，用于标识当前的数据集版本，还会记录一个当数据集的偏移量 Offset。

  不管 Master 是否有配置 Slave 服务器，Replication Id 和 Offset 会一直记录并成对存在，我们可以通过以下命令查看 Replication Id和 Offset：

  > info repliaction

  通过 redis-cli 在 Master 或 Slave 服务器执行该命令会打印类似以下信息（不同服务器数据不同，打印信息不同）：

  connected_slaves:1
  slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1
  master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee
  master_repl_offset:9472

  当 Master 与 Slave 正常连接时，Slave 使用 PSYNC 命令向 Master 发送自己记录的旧 Master 的 Replication id 和 Offset。

  而 Master 会计算与 Slave 之间的数据偏移量，并将缓冲区中的偏移数量同步到 Slave，此时 Master 和 Slave 的数据一致。
  而如果 Slave 引用的 Replication 太旧了，Master 与 Slave 之间的数据差异太大，则 Master 与 Slave 之间会使用全量复制的进行数据同步。

  配置主从复制

  Redis 的主从配置非常简单，我们可以使用两种方式来配置主从服务器，在这时我们先假设 Redis 的 Master 服务器地址为 192.168.0.101。

  客户端发送同步命令：

  # 向客户端
  saveof 192.168.1.101 6379

  Slave 服务器配置主服务器：在这里 Slave 服务器的 redis.conf 通过 saveof 选项，可以指定 Master 服务器，如下：

  slaveof 192.168.1.101 6379

  通过上面两种方式的配置，Master 服务器与 Slave 服务器便已经可以开始进行数据同步了。

  Master 要求验证：上面配置的是 Master 服务器没有设置密码的情况，如果 Master 设置了密码，则可以在连接到 Slave 服务器的 redis-cli 执行下面的命令：

  # <password>指代实际的密码
  config set masterauth <password>

  或者在 Slave 服务器的 redis.conf 中配置下面的选项：

  # <password>指代实际的密码
  masterauth <password>

  避免 Slave 被清空

  Slave 会被清空？Slave 不用同步了 Master 的数据吗？备份的数据怎么会清空了呢？

  当 Master 服务器关闭了持久化时，如果发生故障后自动重启时，由本地没有保存持久化的数据，重启的 Redis 内存数据为空，而 Slave 会自动同步 Master 的数据，这时候，Slave 服务器的数据也会被清空。

  如何避免 Slave 被清空呢？如果条件允许（一般都可以的），Master 服务器还是要开启持久化，这样 Master 故障重启时，可以快速恢复数据，而同步这台 Master 的 Slave 数据也不会被清空。

  如果 Master 不能开启持久化，则不应该设置让 Master 发生故障后重启（有些机器会配置自动重启），而是将某个 Slave 服务器升级为 Master 服务器，对外继续提供服务。

  Slave 默认为只读的

  
  在 Redis 2.6 以后，Slave 只读模式是默认开启的，我们可以通过配置文件中的 slave-read-only 选项配置是否开启只读模式：

  # 默认是yes
  slave-read-only yes/no 

  或者在客户端中通过 config set 命令设置是否开启只读模式：

  config set slave-read-only no 

  上面将 Slave 服务器设置为可以写入，但是要注意，如果 Slave 也配置了自己的从服务器（Sub-Slave），那么 Sub-Slave 只会同步从 Master 服务器同步到 Slave 的数据，而并会同步我们直接写入 Slave 服务器的数据。

  主从复制中的 Key 过期问题

  我们都知道 Redis 可以通过设置 Key 的过期时间来限制 Key 的生存时间，Redis 处理 Key 过期有惰性删除和定期删除两种机制。

  而在配置主从复制后，Slave 服务器就没有权限处理过期的 Key，这样的话，对于在 Master 上过期的 Key，在 Slave 服务器就可能被读取。

  所以 Master 会累积过期的 Key，积累一定的量之后，发送 Del 命令到 Slave，删除 Slave 上的 Key。

  如果 Slave 服务器升级为 Master 服务器 ，则它将开始独立地计算 Key 过期时间，而不需要通过 Master 服务器的帮助。

  主从复制的作用

  ①保存 Redis 数据副本

  当我们只是通过 RDB 或 AOF 把 Redis 的内存数据持久化毕竟只是在本地，并不能保证绝对的安全，而通过将数据同步 Slave 服务器上，可以保留多一个数据备份，更好地保证数据的安全。

  ②读写分离

  
  在配置了主从复制之后，如果 Master 服务器的读写压力太大，可以进行读写分离，客户端向 Master 服务器写入数据，在读数据时，则访问 Slave 服务器，从而减轻 Master 服务器的访问压力

  

  

  ③高可用性与故障转移

  服务器的高可用性是指服务器能提供 7*24 小时不间断的服务，Redis 可以通过 Sentinel 系统管理多个 Redis 服务器。

  当 Master 服务器发生故障时，Sentineal 系统会根据一定的规则将某台 Slave 服务器升级为 Master 服务器，继续提供服务，实现故障转移，保证 Redis 服务不间断。

• 您还可以看一下 帅岭老师的redis缓存实战案例及问题解决：击穿，穿透，雪崩课程中的 使用redis的必要性小节, 巩固相关知识点
  

只要你写了这种接口那么就有概率发生