qq_37080455的博客

通常用于构建布隆过滤器业务场景需要频繁的查询数据库里的数据，但是这些数据又不一定都存在，一些大量无效的数据库请求，占用了数据库的链接。解决：1、把查询的数据key放入redis Set中，只有存在才会去查询，问题就是set过于大，检查是否存在也会变慢2、当库中不存在该值时，依然创建一个value设置为空值，等过期时间后，自行删除。有可能上一秒库中不存在，下一秒有了，拿走依然是空值，也不行。3、布隆过滤器布隆过滤器（Bloom Filter）是 1970 年由布隆提出的。

一、lua脚本一般我会用lua脚本来代替。官方默认lua脚本是原子性的，应该是和MySQL的原子行差不多的。lua脚本的所有命令要么全部执行成功要么全部执行失败。一般是做一些逻辑比较严密的处理。阻塞其他redis操作，直到lua脚本完全执行完毕才会执行其他命令。我认为lua可以执行批量处理如果lua脚本执行的时间太长，那么要优化下lua脚本，因为lua会阻塞其他操作，所以说lua脚本不适合执行太长时间。三、pipeline1、批量处理数据，一次性返回所有结果集。

1、简介在客户端请求数据时，如果能在缓存中命中数据，那就查询缓存，不用在去查询数据库，从而减轻数据库的压力，提高服务器的性能。

当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。

原理：1、原理。

缓存异常会面临的三个问题：缓存雪崩、击穿和穿透。其中，缓存雪崩和缓存击穿主要原因是数据不在缓存中，而导致大量请求访问了数据库，数据库压力骤增，容易引发一系列连锁反应，导致系统奔溃。不过，一旦数据被重新加载回缓存，应用又可以从缓存快速读取数据，不再继续访问数据库，数据库的压力也会瞬间降下来。因此，缓存雪崩和缓存击穿应对的方案比较类似。而缓存穿透主要原因是数据既不在缓存也不在数据库中。因此，缓存穿透与缓存雪崩、击穿应对的方案不太一样。

基于ZooKeeper 的分布式锁，适用于高可靠（高可用）而并发量不是太大的场景；基于Redis 的分布式锁，适用于并发量很大、性能要求很高的、而可靠性问题可以通过其他方案去弥补的场景。

Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速度非常快，常用于缓存，消息队列、分布式锁等场景。Redis 提供了多种数据类型来支持不同的业务场景，比如 String(字符串)、Hash(哈希)、 List (列表)、Set(集合)、Zset(有序集合)、Bitmaps（位图）、HyperLogLog（基数统计）、GEO（地理信息）、Stream（流），并且对数据类型的操作都是原子性的，因为执行命令由单线程负责的，不存在并发竞争的问题。除此之外，Redis 还支持。

我画了一张 Redis 数据类型和底层数据结构的对应关图，左边是 Redis 3.0版本的，也就是《Redis 设计与实现》这本书讲解的版本，现在看还是有点过时了，右边是现在 Redis 7.0 版本的。String 类型的底层的数据结构实现主要是 SDS（简单动态字符串）。List 类型的底层数据结构是由。Hash 类型的底层数据结构是由。Zset 类型的底层数据结构是由。Set 类型的底层数据结构是由。String 类型内部实现。List 类型内部实现。Hash 类型内部实现。Set 类型内部实现。

： 计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中，numkeys：表示参与运算的集合数，将score相加作为结果的score。在有序集合中保留了不能有重复成员的特性，但其中的成员是可以排序的，每一个元素都会关联一个double类型的分数（score）作为排序依据，score相同时按字典顺序排序。字符串类型是Redis最基础的数据结构，其它的几种数据结构都是在字符串类型基础上构建的，字符串的值可以是：字符串、数字、二进制，但其值最大不能超过512M。

通过上面的介绍，相信大家对Redis的过期数据删除策略和内存淘汰策略有一定的了解了。这里总结一下：Redis过期删除策略是采用惰性删除和定期删除这两种方式组合进行的，惰性删除能够保证过期的数据我们在获取时一定获取不到，而定期删除设置合适的频率，则可以保证无效的数据及时得到释放，而不会一直占用内存数据。但是我们说Redis是部署在物理机上的，内存不可能无限扩充的，当内存达到我们设定的界限后，便自动触发Redis内存淘汰策略，而具体的策略方式要根据实际业务情况进行选取。

因此，合理控制n的大小，避免复杂度过高的操作，是保持JIMDB服务的稳定性和可用性的重要考虑因素。：创建JIMDB集群时结合业务场景选择合适的淘汰策略，如volatile-lru（设置了过期时间的Key按照lru进行逐出）、allkeys-lru（所有Key按照lru进行逐出）、noeviction（不淘汰数据，但写入会失败）等，确保高效利用有限资源，同时提高缓存命中率。集群，确保业务间的隔离性，以便更容易定位和解决潜在的问题，提高系统的稳定性和可维护性。集群，通过双写的形式满足更高的高可用需求。

应用持续访问又大又热的key，会造成Redis实例CPU高、流量被打满、数据在内存积压，甚至导致实例达到配额限制被oom-kill。在异步调用、pipeline、mget等批量调用场景比较常见。大key分为两种情况。