Redis

Redis的压缩列表ziplist到紧凑列表listpack ziplist 的结构（老版本用的） 大概长这样： 12345[zlbytes][zltail][zllen][entry1][entry2]...[entryN][0xFF]● *zlbytes*，记录整个压缩列表占用对内存字节数；● *zltail*，记录压缩列表「尾部」节点距离起始地址由多少字节，也就是列表尾的偏移量；● *zllen*，记录压缩列表包含的节点数量；● *0xFF*，标记压缩列表的结束点，固定值 0xFF（十进制255）。 每个 entry 里： 1[prevlen][encoding][data] prevlen：前一个 entry 的长度（1 或 5 字节） encoding：当前 entry 是字符串还是整数，长度是多少 data：真正的数据 listpack 的结构（新版本用的） 大概长这样： 1234[total_bytes][count][entry1][entry2]...[entryN][0xFF]total_bytes：整个 listpack...

Redis网络模型（io多路复用） 阻塞IO(Blocking IO) 假设服务端只开启一个线程处理请求，第一个请求到来，开始调用内核read函数，然后就会发生阻塞，第二个请求到来时服务端将无法处理，只能等第一个请求读取完成。这种方式的缺点很明显，每次只能处理一个请求，无法发挥cpu多核优势，性能低下。 为了解决这个问题，我们可以引入多线程，这样就可以同时处理多个请求了，但服务端可能同时有成千上万的请求需要处理，随之而来的是线程数膨胀，频繁创建、销毁线程带来的性能影响，当然我们可以使用线程池，但服务能处理的总体数量就会受限于线程池线程数量。 非阻塞IO(NON-Blocking...

redis做为缓存，mysql的数据如何与redis进行同步呢？（双写一致性） 在项目中，我们主要通过 Redisson 的读写锁机制 来保证数据的强一致性。 当执行读取操作时，我们会加上读锁（共享锁），这样可以做到： 读读不互斥； 读写互斥。 而在更新数据时，我们会加上写锁（排他锁），此时写写、读写都互斥。 这样可以确保在写入数据库的同时，其他线程无法读取缓存数据，从而避免出现脏读或不一致的情况。 这里需要注意的一点是：读写方法必须使用同一把锁，才能真正保证互斥关系成立。 除了使用分布式锁，我们也考虑过使用 “延迟双删”策略 来实现最终一致性。 具体做法是： 先删除缓存； 再更新数据库； 最后延时一段时间后，再删除一次缓存。 不过，延迟的时间点很难精确把握。在延时窗口内仍可能出现脏数据问题，无法满足强一致性场景，因此我们最终没有采用这种方式。 在我最近做的项目中（例如简历中提到的 xxxx 功能）， 系统对数据一致性的实时性要求没有那么高，可以接受一定的同步延时。 因此我们采用了 阿里巴巴的 Canal 组件 来实现最终一致性的数据同步。 Canal...

Redis分布式锁方案 使用 Redis 的 SET key value NX EX实现分布式锁时，主要问题是锁过期时间不好设置：如果设置过短，业务未完成锁就过期；设置过长，会降低系统并发度。为此可以使用 Redisson 封装的分布式锁，它内部通过「看门狗机制」自动续期锁（默认锁 30 秒，每 10 秒续期一次），同时通过 Lua 脚本保证加解锁的原子性，从而确保分布式环境下的并发安全。 Redisson分布式锁自动续约机制（看门狗） 线程1尝试tryLock锁未指定锁的过期时间 获取成功后会自动启动看门狗机制 初始加锁： ​ 当调用 lock() 时，Redisson 会通过 Lua 脚本向 Redis 发送加锁命令，设置锁的初始过期时间为 LockWatchdogTimeout（默认 30 秒）。 ​ 锁的数据结构为 Hash，键为锁名称，field 为线程 ID，value 为重入次数。 启动定时任务： ​ 加锁成功后，Redisson 会启动一个后台定时任务（通过 Netty 的 HashedWheelTimer 实现），每隔 10 秒执行一次。 ...

Redis 的数据过期策略 Redis 采用 「惰性删除 + 定期删除」 两种策略相结合的方式，在 CPU 性能开销 与 内存占用 之间取得平衡。 一、惰性删除（Lazy Expiration） 当客户端访问或修改某个键时，Redis 会在操作前调用 expireIfNeeded() 函数检查该键是否已过期： 若已过期： Redis 会立即删除该键，然后向客户端返回 null。 删除方式由配置项 lazyfree-lazy-expire 决定： 若开启（yes），则采用 异步删除； 若关闭（no），则采用 同步删除。 若未过期： 直接返回该键对应的正常值，不做任何额外处理。 这种方式的优点是 删除时机精准、不会浪费 CPU 时间； 缺点是：若某些过期键一直未被访问，就无法被清除，会长期占用内存。 二、定期删除（Active Expiration Cycle） 为了解决惰性删除的不足，Redis 还会周期性地扫描部分键空间，清除已过期的数据。 1. 检查频率 Redis 默认每秒执行 10 次过期扫描，这一频率由配置文件 redis.conf 中的参数 hz...

缓存穿透 缓存穿透指的是：一个缓存和数据库中都不存在的数据，由于数据库无法写入缓存，导致频繁请求直接打到数据库，从而造成数据库压力过大甚至被“打穿”。 常见的解决方法包括：缓存空值 或 布隆过滤器。 布隆过滤器由一个全 0 的位图数组和 n 个哈希函数组成。当一个数据在请求缓存前，会先经过布隆过滤器。过滤器会通过 n 个哈希函数计算出 n 个哈希值，再分别对数组长度取模，并将对应的数组下标置为 1。 查询时，只需要查看位图数组中这 n 个位置是否全部为 1： 若存在某个位为 0，则说明该数据一定不存在于数据库中； 若全部为 1，则说明该数据可能存在，但不一定真的存在，因为可能出现哈希碰撞。 因此，布隆过滤器判断“存在”时并不能保证数据真的存在，但判断“不存在”时一定准确。 缓存雪崩 缓存雪崩指的是：大量的缓存 Key 在同一时间失效，或者 Redis 服务器宕机，导致所有请求同时打到数据库，造成数据库瞬时压力过大，甚至宕机的情况。 解决方法： 为缓存设置 固定过期时间 + 随机过期时间，让不同 Key 的过期时间错开，避免在同一时间集中失效。 ...