实际上就是为 keyspace 增加了一个 key 是包含字符串“mobile”的字符串对象,value 为包含字符“13800000000”的字符串对象。
看图:
对于删改查,没啥好说的。类似java 的 map 操作,大多数程序员应该都能理解。
需要特别注意的是,再执行对键的读写操作的时候,Redis 还要做一些额外的维护动作:
-
维护 hit 和 miss 两个计数器。用于统计 Redis 的缓存命中率。
-
更新键的 LRU 时间,记录键的最后活跃时间。
-
如果在读取的时候发现键已经过期,Redis 先删除这个过期的键然后再执行余下操作。
-
如果有客户对这个键执行了 WATCH 操作,会把这个键标记为 dirty,让事务注意到这个键已经被改过。
-
没修改一次 dirty 会增加1。
-
如果服务器开启了数据库通知功能,键被修改之后,会按照配置发送通知。
键的过期实现
Redis 作为缓存使用最主要的一个特性就是可以为键值对设置过期时间。就看看 Redis 是如果实现这一个最重要的特性的?
在 Redis 中与过期时间有关的命令
-
EXPIRE 设置 key 的存活时间单位秒
-
EXPIREAT 设置 key 的过期时间点单位秒
-
PEXPIRE 设置 key 的存活时间单位毫秒
-
PEXPIREAT 设置 key 的过期时间点单位毫秒
其实这些命令,底层的命令都是由 REXPIREAT 实现的。
在 redisDb 中使用了 dict *expires,来存储过期时间的。其中 key 指向了 keyspace 中的 key(c 语言中的指针), value 是一个 long long 类型的时间戳,标定这个 key 过期的时间点,单位是毫秒。
如果我们为上文的 mobile 增加一个过期时间。
>redis PEXPIREAT mobile 1521469812000
这个时候就会在过期的 字典中增加一个键值对。如下图:
对于过期的判断逻辑就很简单:
-
在 字典 expires 中 key 是否存在。
-
如果 key 存在,value 的时间戳是否小于当前系统时间戳。
接下来就需要讨论一下过期的键的删除策略。
key的删除有三种策略:
-
定时删除,Redis定时的删除内存里面所有过期的键值对,这样能够保证内存友好,过期的key都会被删除,但是如果key的数量很多,一次删除需要CPU运算,CPU不友好。
-
惰性删除,只有 key 在被调用的时候才去检查键值对是否过期,但是会造成内存中存储大量的过期键值对,内存不友好,但是极大的减轻CPU 的负担。
-
定时部分删除,Redis定时扫描过期键,但是只删除部分,至于删除多少键,根据当前 Redis 的状态决定。
这三种策略就是对时间和空间有不同的倾向。Redis为了平衡时间和空间,采用了后两种策略 惰性删除和定时部分删除。
惰性删除比较简单,不做过多介绍。主要讨论一下定时部分删除。
过期键的定时删除的策略由 expire.c/activeExpireCycle() 函数实现,server.c/serverCron() 定时的调用?activieExpireCycle()
?。
activeExpireCycle 的大的操作原则是,如果过期的key比较少,则删除key的数量也比较保守,如果,过期的键多,删除key的策略就会很激进。
static unsigned int current_db = 0; /* Last DB tested. */
static int timelimit_exit = 0; /* Time limit hit in previous call? */
static long long last_fast_cycle = 0; /* When last fast cycle ran. */
-
首先三个?
static
?全局参数分别记录目前遍历的 db下标,上一次删除是否是超时退出的,上一次快速操作是什么时候进行的。 -
计算?
timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;
?可以理解为 25% 的 cpu 时间。 -
如果 db 中 expire 的大小为0 不操作
-
expire 占总 key 小于 1% 不操作
最后
现在其实从大厂招聘需求可见,在招聘要求上有高并发经验优先,包括很多朋友之前都是做传统行业或者外包项目,一直在小公司,技术搞的比较简单,没有怎么搞过分布式系统,但是现在互联网公司一般都是做分布式系统。
所以说,如果你想进大厂,想脱离传统行业,这些技术知识都是你必备的,下面自己手打了一份Java并发体系思维导图,希望对你有所帮助。