• 2、对于逻辑性错误，比如本来应该把一个数加1，但是程序逻辑写成了加2，那么这种错误也是无法通过事务回滚来进行解决。

• 3、Redis追求的是简单高效，而传统事务的实现相对比较复杂，这和Redis的设计思想相违背。

C-一致性

一致性指的就是事务执行前后的数据符合数据库的定义和要求。这一点Redis是符合要求的，上面讲述原子性的时候已经提到，不论是发生语法错误还是运行时错误，错误的命令均不会被执行。

I-隔离性

事务中的所有命令都会按顺序执行，在执行Redis事务的过程中，另一个客户端发出的请求不可能被服务，这保证了命令是作为单独的独立操作执行的。所以Redis当中的事务是符合隔离性要求的。

D-持久性

如果Redis当中没有被开启持久化，那么就是纯内存运行的，一旦重启，所有数据都会丢失，所以不具备持久性，而如果Redis开启了持久化，那么也需要看开启的持久化模式是RDB还是AOF，还要视具体配置具体分析，这一点我们后面讲述持久化的时候会专门分析。

WATCH命令

---

上面我们讲述事务的时候还提到了一个WATCH命令，这个又是做什么用的呢？我们还是先来看一个例子。

首先打开客户端1，并开启事务：

上面事务中，如果这时候去执行exec，那么正常是第一句话返回nil，第二句话ok，第三句话lonely_wolf。

但是这个时候我在另一个客户端2执行一个set name zhangsan命令：

执行成功，这时候再返回到客户端1执行exec命令：

可以发现，第一句话返回了zhangsan，也就是说，name这个key值在入队之后到exec之前发生了变化，这种在有些场景可能会导致数据被覆盖等问题的发生，那么如何解决呢？这时候watch命令就可以闪亮登场了。

watch命令的作用

watch命令可以为Redis事务提供CAS乐观锁行为，它可以在exec命令执行之前，监视任意key值的变化，也就是说当多个线程更新同一个key值的时候，会跟原值做比较，一旦发现它被修改过，则拒绝执行命令，并且会返回nil给客户端。

下面还是通过一个示例来演示一下：

首先客户端1监视key值name，然后开启事务：

客户端2执行set name zhangsan命令：

这时候客户端1再提交事务,会发现，事务中所有的命令都没有被执行（也就是说，只要检测到一个key值被修改过，那么整个事务都不会被执行）：

watch原理分析

下面是一个Redis服务的数据结构定义：

typedef struct redisDb {

dict watched_keys; / WATCHED keys for MULTI/EXEC CAS */

int id; /* Database ID */

//省略了其他属性

} redisDb;

可以看到，redisDb中的watched_keys存储了一个字典，这个字典当中的key存的就是被监视的key，然后字典的值存的就是客户端id

然后每个客户端还有一个标记属性CLIENT_DIRTY_CAS：

一旦我们执行了一些如set，sadd等能修改key值对应value的命令，那么CLIENT_DIRTY_CAS标记将会被修改，后面执行事务提交命令exec时一旦发现这个标记被修改过，则会拒绝执行事务。

内存回收

=================================================================

Redis当中我们可以通过4个命令来给一个键设置过期时间：

• expire key ttl：将key值的过期时间设置为ttl秒

• pexpire key ttl：将key值的过期时间设置为ttl毫秒

• expireat key timestamp：将key值的过期时间设置为指定的timestamp秒数

• pexpireat key timestamp：将key值的过期时间设置为指定的timestamp毫秒数

PS:不管使用哪一个命令，最终Redis底层都是使用pexpireat命令来实现的，另外，set等命令也可以设置key的同时加上过期时间，这样可以保证设值和设过期时间的原子性。

最后我们可以通过ttl和pttl两个命令来查询剩余过期时间：

• ttl key 返回key剩余过期秒数，

• pttl key 返回key剩余过期的毫秒数

如果未设置过期时间则上面两个命令返回-1，如果设置了一个非法的过期时间，则都返回-2。

过期策略

---

如果将一个过期的键删除，我们一般都会有三种策略：

• 1、定时删除：为每个键设置一个定时器，一旦过期时间到了，则将键删除。这种策略对内存很友好，但是对CPU不友好。因为每个定时器都会占用一定的CPU资源。

• 2、惰性删除：不管键有没有过期都不主动删除，等到每次去获取键时再判断是否过期，如果过期就删除该键，否则返回键对应的值。这种策略对内存不够友好，可能会浪费很多内存。

• 3、定期扫描：系统每隔一段时间就定期扫描一次，发现过期的键就进行删除。这种策略相对来说是上面两种策略的折衷方案，但是这个定期的频率需要结合实际情况掌控好，但是这种方案也可能会出现过期的键也被返回。

在Redis当中，其选择的是策略2和策略3的综合使用。不过Redis的定期扫描只会扫描设置了过期时间的键，因为设置了过期时间的键Redis会单独存储，所以不会出现扫描所有键的情况：

typedef struct redisDb {

dict *dict; //所有的键值对

dict *expires; //设置了过期时间的键值对

dict *blocking_keys; //被阻塞的key,如客户端执行BLPOP等阻塞指令时

dict watched_keys; / WATCHED keys for MULTI/EXEC CAS */

int id; /* Database ID */

//省略了其他属性

} redisDb;

淘汰策略

---

假如Redis当中所有的键都没有过期，而且此时内存满了，那么客户端继续执行set等命令时Redis会怎么处理呢？Redis当中提供了不同的淘汰策略来处理这种场景。

首先Redis提供了一个参数maxmemory 来配置Redis最大使用内存

maxmemory

或者也可以通过命令config set maxmemory 1GB来动态修改。

如果没有设置该参数，那么在32位的操作系统中最多使用3GB内存，而在64位的操作系统中不作限制。

Redis中提供了8种淘汰策略，通过参数maxmemory-policy进行配置：

| 淘汰策略 | 说明 |

| — | — |

| volatile-lru | 根据LRU算法删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错 |

| allkeys-lru | 根据LRU算法删除所有的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错 |

| volatile-lfu | 根据LFU算法删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错 |

| allkeys-lfu | 根据LFU算法删除所有的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错 |

| volatile-random | 随机删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错 |

| allkeys-random | 随机删除所有键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错 |

| volatile-ttl | 根据键值对象的ttl属性， 删除最近将要过期数据。 如果没有，则直接报错 |

| noeviction | 默认策略，不作任何处理，直接报错 |

PS：淘汰策略也可以根据命令config set maxmemory-policy <策略>进行动态删除

LRU算法

---

LRU：Least Recently Used，即：最近最长时间未被使用。这个主要针对的是使用时间。

Redis改进后的LRU算法

在Redis当中，并没有采用传统的LRU算法，因为传统的LRU算法存在2个问题：

• 1、需要额外的空间进行存储。

• 2、可能存在某些key值使用很频繁，但是最近没被使用，从而被LRU算法删除。

为了避免以上2个问题，Redis当中对传统的LRU算法进行了改造，通过抽样的方式进行删除。

配置文件中提供了一个属性maxmemory_samples 5，默认值就是5，表示随机抽取5个key值，然后对这5个key值按照LRU算法进行删除，所以很明显，key值越大，删除的准确度越高。

对抽样LRU算法和传统的LRU算法，Redis官网当中有一个对比图：

• 浅灰色带是被删除的对象。

• 灰色带是未被删除的对象。

• 绿带是添加的对象

左上角第一幅图代表的是传统LRU算法，可以看到，当抽样数达到10个(右上角)，已经和传统的LRU算法非常接近了。

Redis如何管理热度数据

前面我们讲述字符串对象的SDS原理时，提到了redisObject对象中存在一个lru属性：

typedef struct redisObject {

unsigned type:4;//对象类型（4位=0.5字节）

unsigned encoding:4;//编码（4位=0.5字节）

unsigned lru:LRU_BITS;//记录对象最后一次被应用程序访问的时间（24位=3字节）

int refcount;//引用计数。等于0时表示可以被垃圾回收（32位=4字节）

void *ptr;//指向底层实际的数据存储结构，如：SDS等(8字节)

} robj;

这个注释上写了，这个值是相对于全局变量lru_clock而言的

lru属性是创建对象的时候会写入，对象被访问到时也会进行更新。正常人的思路就是最后决定要不要删除他肯定是用当前时间戳减去lru，差值最大的就优先被删除。

但是Redis里面并不是这么做的，Redis中维护了一个全局属性lru_clock，这个属性是通过一个全局函数serverCron每隔100毫秒执行一次来更新的，记录的是当前unix时间戳，

最后决定删除的数据是通过lru_clock全局属性减去对象的lru属性得出的。那么为什么Redis要这么做呢？直接取全局时间不是更准确吗？这是因为这么做可以避免每次更新对象的lru属性的时候可以直接取全局属性，而不需要去调用系统函数来获取系统时间，从而提升效率（Redis当中有很多这种细节考虑来提升性能，可以说是对性能尽可能的优化到极致）。

不过这里还有一个问题，我们看到，redisObject对象中的lru属性只有24位，24位只能存储194天的时间戳大小，一旦超过194天之后就会重新从0开始计算，所以这时候就会出现redisObject对象中的lru属性大于全局的lru_clock属性的情况。

正因为如此，计算的时候也需要分为2种情况，下面就是源码的计算方式(evict.c内)：

• 1、当全局lruclock>lru，则使用lruclock-lru得到空闲时间。

• 2、当全局lruclock<lru，则使用lruclock_max-lru+lruclock得到空闲时间。

需要注意的是，这种计算方式并不能保证抽样的数据中一定能删除空闲时间最长的。

这是因为首先超过194天还不被使用的情况很少，再次只有lruclock第2轮继续超过lru属性时，计算才会出问题。比如对象A记录的lru是1天，而lruclock第二轮都到10天了，这时候就会导致计算结果只有10-1=9天，实际上应该是194+10-1=203天。但是这种情况可以说又是更少发生，所以说这种处理方式是可能存在删除不准确的情况，但是我们只需要达到基本准确就可以了。

LFU算法

---

LFU：Least Frequently Used，即：最近最少频率使用，这个主要针对的是使用频率。

这个属性也是记录在redisObject中的lru属性内。

当我们采用LFU回收策略时，lru属性的高16位用来记录访问时间（last decrement time：ldt，单位为分钟），低8位用来记录访问频率（logistic counter：logc），简称counter。

访问频次递增

LFU计数器每个键只有8位，它能表示的最大值是255，所以Redis使用的是一种基于概率的对数器来实现counter的递增。

给定一个旧的访问频次，当一个键被访问时，counter按以下方式递增：

• 1、提取0和1之间的随机数R

• 2、概率P计算为1/(old_value*lfu_log_factor+1)。

• 3、当R<P时，频次进行递增

公式中的lfu_log_factor称之为对数因子，默认是10，可以通过参数来进行控制：

lfu_log_factor 10

下图就是对数因子lfu_log_factor和频次counter增长的关系图：

可以看到，当对数因子lfu_log_factor为100时，10M(1000万)次访问才会将访问counter才增长到255，而默认的10也能支持到1M(100万)次访问counter才能达到255上限，这在大部分场景都是足够满足需求的。

访问频次递减

如果访问频次counter只是一直在递增，那么迟早会全部都到255，也就是说counter一直递增不能完全反应一个key的热度的，所以当某一个key一段时间不被访问之后，counter也需要对应减少。

counter的减少速度由参数lfu-decay-time进行控制,默认是1，单位是分钟，默认值1表示：N分钟内没有访问，counter就要减N。

lfu-decay-time 1

具体算法如下：

• 1、获取当前时间戳，转化为分钟后取低16位（为了方便后续计算，这个值记为now）。

• 2、取出对象内的lru属性中的高16位（为了方便后续计算，这个值记为ldt）。

• 3、当lru>now时，默认为过了一个周期(16位，最大65535)，则取差值65535-ldt+now；当lru <=now时，取差值now-ldt（为了方便后续计算，这个差值记为idle_time）。

• 4、取出配置文件中的lfu_decay_time值，然后计算：idle_time / lfu_decay_time（为了方便后续计算，这个值记为num_periods）。

• 5、最后将counter减少：counter - num_periods

看起来这么复杂，其实计算公式就是一句话，就是取出当前的时间戳对比对象中的lru属性，计算出当前多久没有被访问到，比如计算得到的结果是100分钟没有被访问，然后再去除配置参数lfu_decay_time，如果这个配置默认为1也即是100/1=100，代表100分钟没访问counter就减少100。

下面3幅图就是源码内的主要计算方法

源码db.c内：

源码evict.c内：

Redis持久化机制

=======================================================================

Redis虽然是定义为一个内存数据库，但是为了防止数据丢失，其仍然提供了两种持久化机制：RDB和AOF。

RDB机制

---

RDB即：Redis DataBase，是Redis当中默认的持久化方案，当触发持久化条件时，Redis会生成一个dump.rdb文件，Redis在重启的时候就会通过解析dump.rdb文件进行数据恢复。

RDB机制触发条件

RDB持久化机制有两种触发方式：自动触发和手动触发。

自动触发

自动触发方式也可以分为三种：

• 1、执行flushall命令(flushdb命令不会触发)时，不过此时生成的读，dump文件内的数据是空的（dump文件还会存储一些头信息，所以文件本身是有内容的，只是没有数据），没有什么太大的意义。

• 2、执行shutdown命令时会触发生成dump文件。

下面就是我这边重启之后的一个例子，数据全部都可以正常恢复：

Redis启动之后日志如下，第一行就是显示了Redis从硬盘中进行了数据恢复：

• 3、通过配置文件自动生成，Redis中配置文件默认配置如下：

save 900 1 //900秒内至少有1个key被添加或者更新

save 300 10 //300秒内至少有10个key被添加或者更新

save 60 10000 //60秒内至少有10000个key被添加或者更新

也就是说只要达到这三个条件中的任意一个，就会触发Redis的RDB持久化机制。

手动触发

除了自动触发，Redis中还提供了2个手动触发RDB机制的命令。

• save：这个命令会阻塞Redis服务器进程，直到成功创建RDB文件，也就是说在生成RDB文件之前，服务器不能处理客户端发送的任何命令。

• bgsave：父进程会执行fork操作来创建一个子进程。RDB文件由子进程来负责生成，父进程可以正常处理客户端发送的命令

如果想要知道上一次成功执行save或者bgsave命令的时间，可以执行lastsave命令进行查看，lastsave命令返回的是一个unix时间戳。

PS：需要注意的是这两个命令不能同时被执行，一旦一个命令正在执行中，另一个命令会被拒绝执行。

RDB机制相关配置文件

除了上面提到的触发生成rdb的配置参数，RDB持久化机制还有如下一些相关命令：

• dir：rdb文件生成目录。默认是./(当前目录)，可以执行命令：config get dir进行查看

• dbfilename：rdb文件名。默认是dump.rdb

• rdbcompression：rdb文件是否是LZF压缩文件。默认是yes

• rdbchecksum：是否开启数据校验。默认是yes

RDB机制优点

• 1、RDB是一个非常紧凑的压缩文件，保存了不同时间点上的文件，非常适合用来灾备和数据恢复。

• 2、RDB最大限度地提高了Redis的性能，因为Redis父进程需要做的唯一的工作就是派生一个子进程来完成剩下的工作。父进程永远不会执行磁盘I/O或类似的操作。

• 3、与AOP机制想必，RDB方式恢复数据的速度更快

RDB机制缺点

• 1、RDB无法做到实时备份，所以如果Redis停止工作而没有正确的关机，那么从上一次备份的到异常宕机的这一段时间的数据将会丢失。

• 2、RDB通常需要父进程来执行fork()操作创建子线程，所以如果频繁执行fork()的而CPU性能又不是很高的话可能会造成短时间内父进程不可用。

AOF机制

---

AOF即：Append Only File，是Redis当中提供的另一种持久化机制。AOF采用日志的形式将每个写操作追加到文件中。开启AOF机制后，只要执行更改Redis数据的命令时，命令就会被写入到AOF文件中。在Redis重启的时候会根据日志内容执行一次AOF文件中的命令来恢复数据。

AOF和RDB最大的不同时AOF记录的是执行命令（类似于MySQL中binlog的statement格式），而RDB记录的是数据（类似于MySQL中binlog的row格式）。

需要注意的是，假如同时开启了RDB和AOF两种机制，那么Redis会优先选择AOF持久化文件来进行数据恢复。

下图就是同时开启了RDB和AOF两种机制的情况，Redis选择了使用AOF机制来进行数据恢复：

AOF机制如何开启

AOF机制默认是关闭的

appendonly no //是否开启AOF机制，默认是no

appendfilename “appendonly.aof” //AOF文件名

把appendonly参数修改为yes则可以开启AOF持久化机制。

PS：和RDB机制一样，其路径也是通过dir配置文件进行配置。

AOF机制数据是否实时写入磁盘

AOF机制下数据是否实时写入磁盘，这个和MySQL的redo log机制很类似，也是需要通过参数来进行控制。

AOF数据何时写入磁盘通过参数appendfsync来进行控制：

| appendfsync | 描述 | Redis作者描述 |

| — | — | — |

| always | 写入缓存的同时通知操作系统刷新(fsync)到磁盘(但是也可能会有部分操作系统只是尽快刷盘，而不是实时刷盘) | Slow, Safest |

| everysec | 先写入缓存，然后每秒中刷一次盘(默认值)，这种模式极端情况可能会丢失1s的数据 | Compromise |

| no | 只写入缓存，什么时候刷盘由操作系统自己决定 | Faster |

AOF重写

AOF机制主要是通过记录执行命令的方式来实现的，那么随着时间的增加，AOF文件不可避免的会越来越大，而且可能会出现很多冗余命令。比如同一个key值执行了10000次set操作，实际上前面9999次对用户来说都是没用的，用户只需要最后一次执行命令，所以AOF机制就提供了重写功能。

重写原理分析

AOF重写时Redis并不会去分析原有的文件，因为如果原有文件过大，分析也会很耗时，所以Redi选择的做法就是重新去Redis中读取现有的键值，然后用一条命令记录键值对的值。

源码server.h中定义了1个常量，常量值等于64：

#define AOF_REWRITE_ITEMS_PER_CMD 64

如果在AOF重写的时候，如果一个集合键或者列表键或者哈希键内包含的元素超过64个，那么也会采用多条命令来进行重写。

AOF重写的时候一般都会有大量的写操作，所以为了不阻塞客户端的命令请求，Redis会把重写操作放入到子进程中执行，但是放入子进程中执行也会带来一个问题，那就是重写期间如果有其他命令被执行了，如何保证数据的一致性？
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

看完美团、字节、腾讯这三家的面试问题，是不是感觉问的特别多，可能咱们又得开启面试造火箭、工作拧螺丝的模式去准备下一次的面试了。

开篇有提及我可是足足背下了1000道题目，多少还是有点用的呢，我看了下，上面这些问题大部分都能从我背的题里找到的，所以今天给大家分享一下互联网工程师必备的面试1000题。

注意不论是我说的互联网面试1000题，还是后面提及的算法与数据结构、设计模式以及更多的Java学习笔记等，皆可分享给各位朋友

互联网工程师必备的面试1000题

而且从上面三家来看，算法与数据结构是必备不可少的呀，因此我建议大家可以去刷刷这本左程云大佬著作的《程序员代码面试指南 IT名企算法与数据结构题目最优解》，里面近200道真实出现过的经典代码面试题。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

看完美团、字节、腾讯这三家的面试问题，是不是感觉问的特别多，可能咱们又得开启面试造火箭、工作拧螺丝的模式去准备下一次的面试了。

开篇有提及我可是足足背下了1000道题目，多少还是有点用的呢，我看了下，上面这些问题大部分都能从我背的题里找到的，所以今天给大家分享一下互联网工程师必备的面试1000题。

注意不论是我说的互联网面试1000题，还是后面提及的算法与数据结构、设计模式以及更多的Java学习笔记等，皆可分享给各位朋友

[外链图片转存中…(img-j5s02k3w-1713535432046)]

互联网工程师必备的面试1000题

而且从上面三家来看，算法与数据结构是必备不可少的呀，因此我建议大家可以去刷刷这本左程云大佬著作的《程序员代码面试指南 IT名企算法与数据结构题目最优解》，里面近200道真实出现过的经典代码面试题。

[外链图片转存中…(img-Q9adrOKh-1713535432047)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！