| ... |
... |
@@ -46,6 +46,8 @@ |
| 46 |
46 |
{{/plantuml}} |
| 47 |
47 |
|
| 48 |
48 |
|
|
49 |
+先说明，redis中，过期时间等信息是单独放在一个table中存储的，因为不是所有key都设有过期时间，放在一起存储会额外增加存储成本。 |
|
50 |
+ |
| 49 |
49 |
expireIfNeeded方法用来判断一个key是否过期 |
| 50 |
50 |
返回1，说明已经过期 |
| 51 |
51 |
返回0，说明数据没有过期 |
| ... |
... |
@@ -63,7 +63,7 @@ |
| 63 |
63 |
endif |
| 64 |
64 |
|
| 65 |
65 |
if(服务器正在启动中)then(yes) |
| 66 |
|
-:过期时间的table可能没加载（同步）完全，这时直接返回0; |
|
68 |
+:过期时间的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 |
|
-过期时间 <= 当前时间 : 已经过期 |
| 74 |
|
-过期时间 > 当前时间 : 没有过期 |
|
75 |
+过期时间 <= 当前时间，返回1 : 已经过期 |
|
76 |
+过期时间 > 当前时间，返回0 : 没有过期 |
| 75 |
75 |
endnote |
| 76 |
76 |
stop |
| 77 |
77 |
endif |
| ... |
... |
@@ -95,7 +95,6 @@ |
| 95 |
95 |
{{/plantuml}} |
| 96 |
96 |
|
| 97 |
97 |
|
| 98 |
|
-先说明，redis中，过期时间等信息是单独放在一个table中存储的，因为不是所有key都设有过期时间，放在一起存储会额外增加存储成本。 |
| 99 |
99 |
再看同步删除dbSyncDelete的策略 |
| 100 |
100 |
|
| 101 |
101 |
{{plantuml}} |
| ... |
... |
@@ -119,16 +119,16 @@ |
| 119 |
119 |
@enduml |
| 120 |
120 |
{{/plantuml}} |
| 121 |
121 |
|
| 122 |
|
-关于dictDelete这里就先不画图了，讲一下主要的实现代码吧。 |
| 123 |
|
-java中的map或者说hashmap对应的就是redis中的dict结构，区别是jdk在1.8版本之后使用拉链转红黑树的方式处理哈希冲突，而redis使用的方法还是拉链存储法，对应着jdk1.7。 |
| 124 |
|
-在redis中存在内存常量池的概念，主要是对应对应字符串这种结构设计的，对于相同的字符串使用同一块内容空间。 |
|
123 |
+ |
|
124 |
+关于dictDelete这里就先不画图了，讲一下主要的实现逻辑吧。 |
|
125 |
+可以大概认为，java中hashmap结构对应的就是redis中的dict结构，区别是jdk在1.8版本之后使用拉链转红黑树的方式处理哈希冲突，而redis使用的方法还是拉链存储法，对应着jdk1.7。 |
|
126 |
+在redis中也存在内存常量池的概念，主要为是对应字符串/数字这种结构设计的，对于相同的字符串使用同一块内存空间。 |
| 125 |
125 |
这样的结构在删除key和value的时候就存在一个额外的问题，如果我直接free掉这块内存，那么其他key和value指向这块内存的读写就会存在异常。 |
| 126 |
|
-redis为了避免这样的问题，在dict删除一个key的过程实际只是将dict中的对应的key的指针删除，然后再根据实际调用场景判断是否要清理key和value占用的那块内存。 |
|
128 |
+redis为了避免这样的问题，在dict删除一个key的过程实际是先将dict中的对应的key的指针删除，然后然后在根据情况（内存是否被共享）再决定是否去free内存空间。 |
| 127 |
127 |
|
| 128 |
128 |
|
| 129 |
129 |
再看异步删除dbAsyncDelete的策略 |
| 130 |
|
-{{plantuml}} |
| 131 |
|
-@startuml |
|
132 |
+{{plantuml}}@startuml |
| 132 |
132 |
start |
| 133 |
133 |
|
| 134 |
134 |
|
| ... |
... |
@@ -138,13 +138,22 @@ |
| 138 |
138 |
|
| 139 |
139 |
:调用dictUnlink方法在dict上删除key指针; |
| 140 |
140 |
note left |
| 141 |
|
-这里dictUnlink方法可以看作是上面dictDelete的一个同名方法，区别在于，dictDelete会明确告诉redis尽可能free掉key和value占用的空间（如果key和value没用被共享的情况下）， |
| 142 |
|
-而dictUnlink则只移除dict上的key即可，一定不要free具体的内存，并把对应的entry（key->value的封装，类似于java中的map.entry对象）返回 |
|
142 |
+这里dictUnlink方法可以看作是上面dictDelete的一个同名方法， |
|
143 |
+区别在于， |
|
144 |
+dictDelete会明确告诉redis尽可能free掉key和value占用的空间（如果key和value没用被共享的情况下）， |
|
145 |
+ |
|
146 |
+而dictUnlink则只移除dict上的key即可， |
|
147 |
+一定不要free具体的内存， |
|
148 |
+并把对应的entry（key->value的封装，类似于java中的map.entry对象）返回 |
| 143 |
143 |
endnote |
| 144 |
144 |
|
| 145 |
145 |
:获取entry中value占用的大小; |
| 146 |
146 |
if(如果value的占用空间过多)then(yes) |
| 147 |
|
-:由于清理起来会耗用很长时间，这里会创建一个删除任务，本质是将要删除的entry扔到一个清理队列中，后台线程定期对这个队列中的数据清理; |
|
153 |
+:由于清理起来会耗用很长时间， |
|
154 |
+ |
|
155 |
+这里会创建一个删除任务， |
|
156 |
+本质是将要删除的entry扔到一个清理队列中， |
|
157 |
+后台线程定期对这个队列中的数据清理; |
| 148 |
148 |
:将entry指针指向空; |
| 149 |
149 |
endif |
| 150 |
150 |
|
| ... |
... |
@@ -158,7 +158,4 @@ |
| 158 |
158 |
|
| 159 |
159 |
|
| 160 |
160 |
end |
| 161 |
|
-@enduml |
| 162 |
|
-{{/plantuml}} |
| 163 |
|
- |
| 164 |
|
- |
|
171 |
+@enduml{{/plantuml}} |