| ... |
... |
@@ -108,7 +108,7 @@ |
| 108 |
108 |
|
| 109 |
109 |
:执行dictDelete方法，删除dict表中具体的数据; |
| 110 |
110 |
if(删除成功)then(yes) |
| 111 |
|
-:在集群模式下的redis，还需要删除cluster中的key，防止路由查询key失败; |
|
111 |
+:对应集群模式的服务器，还需要删除cluster中的key，防止路由查询key失败; |
| 112 |
112 |
:返回1; |
| 113 |
113 |
else |
| 114 |
114 |
:返回0; |
| ... |
... |
@@ -118,47 +118,3 @@ |
| 118 |
118 |
end |
| 119 |
119 |
@enduml |
| 120 |
120 |
{{/plantuml}} |
| 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的策略 |
| 130 |
|
-{{plantuml}} |
| 131 |
|
-@startuml |
| 132 |
|
-start |
| 133 |
|
- |
| 134 |
|
- |
| 135 |
|
-if(key过期表是否为空)then(no) |
| 136 |
|
-:删除过期表中的key; |
| 137 |
|
-endif |
| 138 |
|
- |
| 139 |
|
-:调用dictUnlink方法在dict上删除key指针; |
| 140 |
|
-note left |
| 141 |
|
-这里dictUnlink方法可以看作是上面dictDelete的一个同名方法，区别在于，dictDelete会明确告诉redis尽可能free掉key和value占用的空间（如果key和value没用被共享的情况下）， |
| 142 |
|
-而dictUnlink则只移除dict上的key即可，一定不要free具体的内存，并把对应的entry（key->value的封装，类似于java中的map.entry对象）返回 |
| 143 |
|
-endnote |
| 144 |
|
- |
| 145 |
|
-:获取entry中value占用的大小; |
| 146 |
|
-if(如果value的占用空间过多)then(yes) |
| 147 |
|
-:由于清理起来会耗用很长时间，这里会创建一个删除任务，本质是将要删除的entry扔到一个清理队列中，后台线程定期对这个队列中的数据清理; |
| 148 |
|
-:将entry指针指向空; |
| 149 |
|
-endif |
| 150 |
|
- |
| 151 |
|
-if(entry不为空，说明没有被异步删除)then(yes) |
| 152 |
|
-:直接清理entry; |
| 153 |
|
-:返回1; |
| 154 |
|
-else(no) |
| 155 |
|
-:返回0; |
| 156 |
|
-endif |
| 157 |
|
- |
| 158 |
|
- |
| 159 |
|
- |
| 160 |
|
-end |
| 161 |
|
-@enduml |
| 162 |
|
-{{/plantuml}} |
| 163 |
|
- |
| 164 |
|
- |