@@ -182,7 +182,40 @@ type NodeLiveness struct {
182182
183183 mu struct {
184184 syncutil.RWMutex
185- callbacks []IsLiveCallback
185+ callbacks []IsLiveCallback
186+ // nodes is an in-memory cache of liveness records that NodeLiveness
187+ // knows about (having learnt of them through gossip or through KV).
188+ // It's a look-aside cache, and is accessed primarily through
189+ // `getLivenessLocked` and callers.
190+ //
191+ // TODO(irfansharif): The caching story for NodeLiveness is a bit
192+ // complicated. This can be attributed to the fact that pre-20.2, we
193+ // weren't always guaranteed for us liveness records for every given
194+ // node. Because of this it wasn't possible to have a
195+ // look-through cache (it wouldn't know where to fetch from if a record
196+ // was found to be missing).
197+ //
198+ // Now that we're always guaranteed to have a liveness records present,
199+ // we should change this out to be a look-through cache instead (it can
200+ // fall back to KV when a given record is missing). This would help
201+ // simplify our current structure where do the following:
202+ //
203+ // - Consult this cache to find an existing liveness record
204+ // - If missing, fetch the record from KV
205+ // - Update the liveness record in KV
206+ // - Add the updated record into this cache (see `maybeUpdate`)
207+ //
208+ // (See `StartHeartbeat` for an example of this pattern.)
209+ //
210+ // What we want instead is a bit simpler:
211+ //
212+ // - Consult this cache to find an existing liveness record
213+ // - If missing, fetch the record from KV, update and return from cache
214+ // - Update the liveness record in KV
215+ // - Add the updated record into this cache
216+ //
217+ // More concretely, we want `getLivenessRecordFromKV` to be tucked away
218+ // within `getLivenessLocked`.
186219 nodes map [roachpb.NodeID ]LivenessRecord
187220 heartbeatCallback HeartbeatCallback
188221 // Before heartbeating, we write to each of these engines to avoid
0 commit comments