为什么要搭建自己的缓存管理模块?
\
这个问题其实也是在问,为什么不使用现有的Cache存储系统,比如Redis,比如Memcached。不是说Redis不够好,只是在处理某些场景中使用的Redis会显的太“笨重”了——Redis的优势之一在于能够供多进程共享,有完善的备份和恢复机制。但反过来想,如果你的缓存仅供单个进程,单个Node实例使用,并且可以容忍缓存的丢失,承受冷启动。那么是值得用不到500行的代码来搭建一个速度更快的缓存模块。
\
在Node中做缓存最简单的作法莫过于使用一个Object对象,将缓存以key-value的形式存入这个对象中,并且这么做的理由只有一个,就是更快的存取速度。相比Redis通过TCP连接的形式与客户端进行通信,在程序中直接使用对象进行存储的效率会是Redis的40倍。在文章的最后给出的完整的源代码中,有一个Redis与这个500行代码的性能对比测试:10000次的set操作,Redis使用的时间为12.5秒左右,平均运算次数为(operations per second)为8013 o/s,而如果使用原生的Object对象,10000次操作只需要0.3秒,平均运算次数为322581 o/s
\
搭建自己的Cache模块需要解决什么问题
\
缓存淘汰算法
\
介于缓存只能够有限的使用内存,任何Cache系统都需要一个如何淘汰缓存的方案(缓存淘汰算法,等同于页面置换算法)。在Node中无法像Redis那样设置使用内存大小(通过Redis中的maxmemory配置选项),所以我们只能通过设置缓存的个数(key-value对数)来间接对缓存大小进行控制。但这同时也赋予了我们另一自由,就是用何种算法来淘汰多余的缓存,以便能提高命中率。
\
Redis只提供五种淘汰方案(maxmemory-policy):
\
- volatile-lru: remove a key among the ones with an expire set, trying to remove keys not recently used(根据过期时间,移除最长时间没有使用过的).\
- volatile-ttl: remove a key among the ones with an expire set, trying to remove keys with short remaining time to live(根据过期时间,移除即将过期的).\
- volatile-random: remove a random key among the ones with an expire set(根据过期时间任意移除一个).\
- allkeys-lru: like volatile-lru, but will remove every kind of key, both normal keys or keys with an expire set(无论是否有过期时间,根据LRU原则来移除).\
- allkeys-random: like volatile-random, but will remove every kind of keys, both normal keys and keys with an expire set(无论是否有过期时间,随机移除).\
可见Redis的移除策略大部分是根据缓存的过期时间和LRU(Least Recently Used,最近最少使用,,其核心思想是“如果数据最近被访问过,那么将来被访问的几率也更高”)算法。
\
但过期时间和LRU算法并非适用于任何的业务逻辑:
\
- 有的业务可以无需给缓存设置过期时间;\
- 在某些场景中LFU(Least Frequently Used,最近最多使用,其核心思想是“如果数据过去被访问多次,那么将来被访问的频率也更高”)算法比LRU更优,能够减少缓存缓存污染。\
同时正因为LRU算法存在一定的缺陷(存在热点数据时,LRU的效率很好,但偶发性的、周期性的批量操作会导致LRU命中率急剧下降),才会有一系列的LRU算法的变形,比如LRU-K, Two queues, Multi Queue等。
\
所以我们决定在缓存模块中嵌入多个淘汰算法,不仅仅如此,我还设想将当用户不确定他所需要的淘汰算法时,我们可以同时运行多个算法,比如对前100000次get操作的各个算法进行命中率统计,100000次操作之后自动切换至命中率最高的算法。
\
数据结构
\
以LRU算法为例,因为需要根据缓存访问的新鲜度来淘汰冷门缓存,非常明显这会是一个队首进热门数据,队尾出冷门数据的队列,假设我们用数组来实现:
\
\Recently used unshift in \Cold cache pop\------\u0026gt;[{key: value}, {key: value},{key: value}......\{key: value}]------\u0026gt;\| |\|\u0026lt;--------------Recently used--------------------|
\
每一项的数据结构如下:
\
\var cache = [\ {\ key: key,\ value: value,\ expire: 1000 * 3\ },\ {\ key: key,\ value: value,\ expire: 1000 * 3\ } \ ... \]
\
那么在每一次取缓存时(get操作),就不得不对这个数组进行遍历。因为遍历的时间复杂度会是O(n),如果当n较大时,遍历花费的时间(包括遍历判断是否过期,以及过期之后的连锁操作)是相当可观的。
\
所以我们应该避免遍历——为了争取时间上的优势,就不得不在空间上有所牺牲。
\
仅仅考虑优化get操作的话,最理想的状态是把所有的key-value缓存都存入一个Object中,这样以来每次get操作都无需遍历,直接通过key就可以取得相应的value值:
\
\var cache = {\ key1: {\ value: \"value1\