... |
... |
@@ -63,7 +63,7 @@ |
63 |
63 |
endif |
64 |
64 |
|
65 |
65 |
if(服务器正在启动中)then(yes) |
66 |
|
-:过期时间的table可能没完全加载,这时直接返回0; |
|
66 |
+:过期时间的table可能没加载(同步)完全,这时直接返回0; |
67 |
67 |
stop |
68 |
68 |
endif |
69 |
69 |
|
... |
... |
@@ -70,8 +70,8 @@ |
70 |
70 |
if(当前环境是从服务器)then(yes) |
71 |
71 |
:对于从服务器无需删除过期key, 直接计算过期时间和当前时间的关系并返回; |
72 |
72 |
note left |
73 |
|
-过期时间 <= 当前时间,返回1 : 已经过期 |
74 |
|
-过期时间 > 当前时间,返回0 : 没有过期 |
|
73 |
+过期时间 <= 当前时间 : 已经过期 |
|
74 |
+过期时间 > 当前时间 : 没有过期 |
75 |
75 |
endnote |
76 |
76 |
stop |
77 |
77 |
endif |
... |
... |
@@ -127,7 +127,8 @@ |
127 |
127 |
|
128 |
128 |
|
129 |
129 |
再看异步删除dbAsyncDelete的策略 |
130 |
|
-{{plantuml}}@startuml |
|
130 |
+{{plantuml}} |
|
131 |
+@startuml |
131 |
131 |
start |
132 |
132 |
|
133 |
133 |
|
... |
... |
@@ -137,22 +137,13 @@ |
137 |
137 |
|
138 |
138 |
:调用dictUnlink方法在dict上删除key指针; |
139 |
139 |
note left |
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对象)返回 |
|
141 |
+这里dictUnlink方法可以看作是上面dictDelete的一个同名方法,区别在于,dictDelete会明确告诉redis尽可能free掉key和value占用的空间(如果key和value没用被共享的情况下), |
|
142 |
+而dictUnlink则只移除dict上的key即可,一定不要free具体的内存,并把对应的entry(key->value的封装,类似于java中的map.entry对象)返回 |
147 |
147 |
endnote |
148 |
148 |
|
149 |
149 |
:获取entry中value占用的大小; |
150 |
150 |
if(如果value的占用空间过多)then(yes) |
151 |
|
-:由于清理起来会耗用很长时间, |
152 |
|
- |
153 |
|
-这里会创建一个删除任务, |
154 |
|
-本质是将要删除的entry扔到一个清理队列中, |
155 |
|
-后台线程定期对这个队列中的数据清理; |
|
147 |
+:由于清理起来会耗用很长时间,这里会创建一个删除任务,本质是将要删除的entry扔到一个清理队列中,后台线程定期对这个队列中的数据清理; |
156 |
156 |
:将entry指针指向空; |
157 |
157 |
endif |
158 |
158 |
|
... |
... |
@@ -166,4 +166,7 @@ |
166 |
166 |
|
167 |
167 |
|
168 |
168 |
end |
169 |
|
-@enduml{{/plantuml}} |
|
161 |
+@enduml |
|
162 |
+{{/plantuml}} |
|
163 |
+ |
|
164 |
+ |