Wiki源代码Redis源码

由用户 xu yang 在 2022/04/27 13:56 保存的版本 19.1

Show last authors
1 get命令本质是调用了lookupKeyRead这个底层方法,
2 lookupKeyRead方法如下:
3
4 {{plantuml}}
5 @startuml
6 start
7
8
9 : lookupKeyReadWithFlags;
10
11
12 end
13 @enduml
14 {{/plantuml}}
15
16
17 lookupKeyReadWithFlags方法如下:
18
19 {{plantuml}}
20 @startuml
21 start
22
23 if(调用expireIfNeeded方法判断key是否过期)then(1:代表过期)
24 if(当前环境为主节点)then(yes)
25 :返回null;
26 stop
27 endif
28
29 if(当前环境为从节点,并且命令为读的时候,那说明key过期是安全的)then(yes)
30 :返回null;
31 stop
32 endif
33 endif
34
35 :调用lookupKey方法,查询value的值;
36 if(返回值为空)then(yes)
37 :缓存命中+1;
38 else(no)
39 :缓存非命中+1;
40 endif
41
42 :返回查询的结果;
43
44 end
45 @enduml
46 {{/plantuml}}
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)
66 :过期时间的table可能没加载(同步)完全,这时直接返回0;
67 stop
68 endif
69
70 if(当前环境是从服务器)then(yes)
71 :对于从服务器无需删除过期key, 直接计算过期时间和当前时间的关系并返回;
72 note left
73 过期时间 <= 当前时间 : 已经过期
74 过期时间 > 当前时间 : 没有过期
75 endnote
76 stop
77 endif
78
79 :写aof删除过期key;
80 :创建消息通知,用来回调那些监控key过期的钩子;
81 if(判断服务器是否打开惰性删除)then(yes)
82 :调用dbAsyncDelete方法异步删除;
83 else(no)
84 :调用dbSyncDelete方法同步删除;
85 endif
86 :返回删除结果;
87 note left
88 删除方法返回值说明
89 1: 说明数据被删除了
90 0: 说明数据删除失败了,在过期表中key还存在
91 endnote
92
93 end
94 @enduml
95 {{/plantuml}}
96
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)
111 :在集群模式下的redis,还需要删除cluster中的key,防止路由查询key失败;
112 :返回1;
113 else
114 :返回0;
115 endif
116
117
118 end
119 @enduml
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