qq_52988841的博客

假说说1000w条数据，redis只能存20w我们这时候就用拒绝策略去保证存的都是热点数据我们先来看一下几种拒绝策略检测易失数据（可能会过期的数据集server.db[i].expires ）① volatile-lru：挑选最近最少使用的数据淘汰② volatile-lfu：挑选最近使用次数最少的数据淘汰③ volatile-ttl：挑选将要过期的数据淘汰④ volatile-random：任意选择数据淘汰检测全库数据（所有数据集server.db[i].dict ）

缓存穿透是指当用户在查询一条数据的时候，而此时数据库和缓存却没有关于这条数据的任何记录，而这条数据在缓存中没找到就会向数据库请求获取数据。用户拿不到数据时，就会一直发请求，查询数据库，这样会对数据库的访问造成很大的压力。如：用户查询一个 id = -1 的商品信息，一般数据库 id 值都是从 1 开始自增，很明显这条信息是不在数据库中，当没有信息返回时，会一直向数据库查询，给当前数据库的造成很大的访问压力。

Redis 属于分布式系统，当有多个客户端需要争抢锁时，我们必须要保证，这把锁不能是某。

集合全量查询和聚合操作；bigkey 删除；清空数据库；AOF 日志同步写；从库加载 RDB 文件为了避免阻塞式操作，Redis 提供了异步线程机制。所谓的异步线程机制，就是指，Redis 会启动一些子线程，然后把一些任务交给这些子线程，让它们在后台完成，而不再由主线程来执行这些任务。使用异步线程机制执行操作，可以避免阻塞主线程。

Redis 设计了简单动态字符串（Simple Dynamic String，SDS）的结构，用来表示字符串。相比于 C 语言中的字符串实现，SDS 这种字符串的实现方式，会提升字符串的操作效率，并且可以用来。

回顾Redis 的AOF的持久化机制。Redis 避免数据丢失的 AOF 方法。这个方法的好处，是每次执行只需要记录操作命令，需要持久化的数据量不大。一般而言，只要你采用的不是 always 的持久化策略，就不会对性能造成太大影响。但是，也正因为记录的是操作命令，而不是实际的数据，所以，用 AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很缓慢，影响到正常使用。所谓内存快照，就是指内存中的数据在某一个时刻的状态记录。

当服务器宕机后，数据全部丢失：我们很容易想到的一个解决方案是从后端数据库恢复这些数据，但这种方式存在两个问题：一是，需要频繁访问数据库，会给数据库带来巨大的压力；二是，这些数据是从慢速数据库中读取出来的，性能肯定比不上从 Redis 中读取，导致使用这些数据的应用程序响应变慢。所以，对 Redis 来说，实现数据的持久化，避免从后端数据库中进行恢复，是至关重要的。目前，Redis 的持久化主要有两大机制，即 AOF 日志和 RDB 快照。

redis 为什么要这莫快？一个就是他是基于内存的，另外一个就是他是他的数据结构说到这儿，你肯定会说：“这个我知道，不就是 String（字符串）、List（列表）、Hash（哈希）、Set（集合）和 Sorted Set（有序集合）吗？”其实，这些只是 Redis 键值对中值的数据类型，也就是数据的保存形式。而这里，我们说的数据结构，是要去看看它们的底层实现。简单来说，底层数据结构一共有 6 种，分别是简单动态字符串、双向链表、压缩列表、哈希表、跳表和整数数组。

体来说，一个键值数据库包括了访问框架、索引模块、操作模块和存储模块四部分（见下图）。接下来，我们就从这四个部分入手，继续构建我们的 SimpleKV。

为了保证数据的可靠性，Redis 需要在磁盘上读写 AOF 和 RDB，但在高并发场景里，这就会直接带来两个新问题：一个是写 AOF 和RDB 会造成 Redis 性能抖动，另一个是 Redis 集群数据同步和实例恢复时，读 RDB 比较慢，限制了同步和恢复速度。