leveldb源码学习——Cache

本文深入解析Leveldb中LRU Cache的设计与实现。LRU Cache利用哈希表快速定位,并通过双链表区分数据的新鲜度。在缓存空间不足时,采用最近最少使用策略替换数据。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Leveldb中会使用cache来提高读取性能,cache两种数据,1,file meta信息,2,data block信息。
leveldb开放了cache的接口,用户可以通过自定义cache类,完成对cache的定制化实现,另外leveldb定义了一个default cache,叫做LRU cache,在用户未实现自定义cache类时,将使用此类作为level的cache,本文脱离业务,单纯分析LRU cache的实现.

首先概括此cache的特点,cache是为了提高性能,用户在获取数据前(读磁盘或者rpc)前,可以先通过在cache中查询,用户在存储数据后,需要把最新数据写入cache,或者失效之前的数据。

内存容量有限,所以cache需要限定capacity。如果插入的数据导致cache内存占用超出了capacity,则需要选择需要覆盖的数据。这是内存cache设计最重要的方面之一。

LRUcache的特点是使用least recently used 策略来选择需要覆盖的数据,即,内存中优先保存最近使用过的数据,而覆盖那些最久没有使用过的数据

leveldb中的 LRUcache,关键点有

  • 使用hashtable 来实现查找节点
  • 使用两个双链表来区分数据新鲜度,in-use链表中保存新鲜数据,lru-list中保存已经很久没有被使用的数据。通过节点的ref值来代表其新鲜度。

下面介绍具体类

LRUHandler

handler是cache中用到的基本存储单元,有三个身份
- 保存了k-v数据
- 双链表的节点
- hashtable的节点

// An entry is a variable length heap-allocated structure.  Entries
// are kept in a circular doubly linked list ordered by access time.
struct LRUHandle {
  void* value; //要cache的用户数据
  void (*deleter)(const Slice&, void* value); //释放数据的方法
  LRUHandle* next_hash;//hash表的指针
  LRUHandle* next;//双链表的指针
  LRUHandle* prev;
  size_t charge;      // TODO(opt): Only allow uint32_t?
  size_t key_length;
  bool in_cache;      // Whether entry is in the cache.
  uint32_t refs;      // References, including cache reference, if present.
  uint32_t hash;      // Hash of key(); used for fast sharding and comparisons
  char key_data[1];   // Beginning of key

  Slice key() const {
    // For cheaper lookups, we allow a temporary Handle object
    // to store a pointer to a key in "value".
    if (next == this) {
      return *(reinterpret_cast<Slice*>(value));
    } else {
      return Slice(key_data, key_length);
    }                                                                                                                                                                              
  }
};

hash table

一个开链hash表。不同hash值的节点被组织在一条链表中保存,链表头保存在一个数组中
hash table的主要方法包括
lookup
insert
remove

另外,当hash table中总的节点个数超过一定数值后,hash table将自动resize为之前的两倍大,并将旧数据重新hash到新table中,完成扩容。

LRUCache

LRU cache通过维护 hash table和两个链表,来提供cache功能。
hash table和链表的节点是共享的,都是同一个LRU handler

这里写图片描述

in-use链表中索引ref值大于1的节点, lru链表中索引ref=1的节点

每次lookup查到的节点,其ref值会增1,此时可能触发lru链表中的节点进入in-use链表

用户使用完节点后,会调用unref,ref值会减一,可能触发in-use链表中的节点转移到lru链表中。

ShardedLRUCache

多个LRUCache 均衡负担一个名字空间的所有数据的cache任务,组成一个shardedLRU cache
这样可以降低并发查询cache时的竞争,查询同一个LRUCache时需要上锁, 如果所有的查询都发往同一个Cache,造成的竞争会比较严重。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值