Hide last authors
xu yang 2.1 1 get命令本质是调用了lookupKeyRead这个底层方法,
2 lookupKeyRead方法如下:
3
xu yang 1.1 4 {{plantuml}}
5 @startuml
6 start
7
8
xu yang 2.1 9 : lookupKeyReadWithFlags;
xu yang 1.1 10
11
12 end
13 @enduml
14 {{/plantuml}}
15
xu yang 2.1 16
17 lookupKeyReadWithFlags方法如下:
18
xu yang 1.1 19 {{plantuml}}
20 @startuml
21 start
22
xu yang 15.1 23 if(调用expireIfNeeded方法判断key是否过期)then(1:代表过期)
xu yang 8.1 24 if(当前环境为主节点)then(yes)
xu yang 9.1 25 :返回null;
xu yang 2.1 26 stop
27 endif
xu yang 1.1 28
xu yang 8.1 29 if(当前环境为从节点,并且命令为读的时候,那说明key过期是安全的)then(yes)
xu yang 2.1 30 :返回null;
31 stop
32 endif
xu yang 10.1 33 endif
xu yang 1.1 34
xu yang 11.1 35 :调用lookupKey方法,查询value的值;
xu yang 10.1 36 if(返回值为空)then(yes)
xu yang 7.1 37 :缓存命中+1;
38 else(no)
39 :缓存非命中+1;
40 endif
xu yang 5.1 41
xu yang 2.1 42 :返回查询的结果;
43
xu yang 1.1 44 end
45 @enduml
46 {{/plantuml}}
xu yang 16.1 47
48
49 expireIfNeeded方法用来判断一个key是否过期
50 返回1,说明已经过期
51 返回0,说明数据没有过期
52
53 {{plantuml}}
54 @startuml
55 start
56
57
58 :查询key的过期时间戳;
59 :获取当前时刻的时间戳;
60 if(过期时间<0)then(yes)
61 :说明该key不存在过期设置,返回0;
62 stop
63 endif
64
65 if(服务器正在启动中)then(yes)
xu yang 17.1 66 :过期时间的table可能没加载(同步)完全,这时直接返回0;
xu yang 16.1 67 stop
68 endif
69
70 if(当前环境是从服务器)then(yes)
71 :对于从服务器无需删除过期key, 直接计算过期时间和当前时间的关系并返回;
72 note left
73 过期时间 <= 当前时间 : 已经过期
74 过期时间 > 当前时间 : 没有过期
xu yang 17.1 75 endnote
xu yang 16.1 76 stop
77 endif
78
79 :写aof删除过期key;
80 :创建消息通知,用来回调那些监控key过期的钩子;
81 if(判断服务器是否打开惰性删除)then(yes)
82 :调用dbAsyncDelete方法异步删除;
83 else(no)
84 :调用dbSyncDelete方法同步删除;
85 endif
xu yang 17.1 86 :返回删除结果;
87 note left
88 删除方法返回值说明
89 1: 说明数据被删除了
90 0: 说明数据删除失败了,在过期表中key还存在
91 endnote
xu yang 16.1 92
xu yang 17.1 93 end
94 @enduml
95 {{/plantuml}}
xu yang 16.1 96
xu yang 17.1 97
98 先说明,redis中,过期时间等信息是单独放在一个table中存储的,因为不是所有key都设有过期时间,放在一起存储会额外增加存储成本。
99 再看同步删除dbSyncDelete的策略
100
101 {{plantuml}}
102 @startuml
103 start
104
105 if(key过期表是否为空)then(no)
106 :删除过期表中的key;
107 endif
108
109 :执行dictDelete方法,删除dict表中具体的数据;
110 if(删除成功)then(yes)
xu yang 18.1 111 :在集群模式下的redis,还需要删除cluster中的key,防止路由查询key失败;
xu yang 17.1 112 :返回1;
113 else
114 :返回0;
115 endif
116
117
xu yang 16.1 118 end
119 @enduml
120 {{/plantuml}}
xu yang 19.1 121
122 关于dictDelete这里就先不画图了,讲一下主要的实现代码吧。
123 java中的map或者说hashmap对应的就是redis中的dict结构,区别是jdk在1.8版本之后使用拉链转红黑树的方式处理哈希冲突,而redis使用的方法还是拉链存储法,对应着jdk1.7。
124 在redis中存在内存常量池的概念,主要是对应对应字符串这种结构设计的,对于相同的字符串使用同一块内容空间。
125 这样的结构在删除key和value的时候就存在一个额外的问题,如果我直接free掉这块内存,那么其他key和value指向这块内存的读写就会存在异常。
126 redis为了避免这样的问题,在dict删除一个key的过程实际只是将dict中的对应的key的指针删除,然后再根据实际调用场景判断是否要清理key和value占用的那块内存。
127
128
129 再看异步删除dbAsyncDelete的策略
xu yang 20.1 130 {{plantuml}}@startuml
xu yang 19.1 131 start
132
133
134 if(key过期表是否为空)then(no)
135 :删除过期表中的key;
136 endif
137
138 :调用dictUnlink方法在dict上删除key指针;
139 note left
xu yang 20.1 140 这里dictUnlink方法可以看作是上面dictDelete的一个同名方法,
141 区别在于,
142 dictDelete会明确告诉redis尽可能free掉key和value占用的空间(如果key和value没用被共享的情况下),
143
144 而dictUnlink则只移除dict上的key即可,
145 一定不要free具体的内存,
146 并把对应的entry(key->value的封装,类似于java中的map.entry对象)返回
xu yang 19.1 147 endnote
148
149 :获取entry中value占用的大小;
150 if(如果value的占用空间过多)then(yes)
xu yang 20.1 151 :由于清理起来会耗用很长时间,
152
153 这里会创建一个删除任务,
154 本质是将要删除的entry扔到一个清理队列中,
155 后台线程定期对这个队列中的数据清理;
xu yang 19.1 156 :将entry指针指向空;
157 endif
158
159 if(entry不为空,说明没有被异步删除)then(yes)
160 :直接清理entry;
161 :返回1;
162 else(no)
163 :返回0;
164 endif
165
166
167
168 end
xu yang 20.1 169 @enduml{{/plantuml}}