再谈tokyotyrant的缓存机制-参数rcnum和xmsiz

前几天搬家实在累得够呛，目前已经苦尽甘来，享受到了超近带来的诸如睡懒觉等一系列优势。;)

今天想说一下对TT来说很重要的两个参数，rcnum 和xmsiz ，从而说 一下TT的缓存机制。

TT有两个方面的缓存

• 一是由xmsiz和bnum（buckets number）共同决定的mmap方式的文件缓存
• 二是由rcnum（records cache number）决定的针对记录的缓存

内存映射

第一个很简单，就是将文件开头的一部分做mmap映射，这样在访问bucket索引和某些数据的时候就会很快（因为这时候操作是先在内存进行，一定 条件下同步一下，io操作少了很多。），而既然这个映射的大小是由xmsiz和bnum这两个参数共同决定的，那么他们是如何共同影响的呢？

在open数据一个数据库实例的时候，会先查一下包括所有bucket的文件部分有多大（这里包括文件头及bucket区），再看一下xmsiz有 多大，取二者之中大的一个，也就是说，所有的bucket索引肯定是会被完全映射到的。

而因为开始的时候文件可能不会太大，比如你设置了一个1G的xmsiz值，而文件打开时只有0.5M，那么最开始mmap的大小当然只会有 0.5M，当然这个映射大小会随着文件大小的增大而增大，在增大到超过xmsiz的时候就不会再长了。

这里还有一个小细节，如果现在xmsiz还有50个字节就达到定义值了，而文件又向后扩展了100字节，那这时候是不会映射一半的，他会选择不映 射，所以xmsiz只是设置了一个最大值，通常是一个不太可能对齐的值。:)

这个内存映射的缓存，在TCHDB结构里是一个名叫map的指针。

有朋友聊到当数据文件大于xmsiz后效率下降严重的问题，我想看了上面就不用再回答了吧。呵呵。

记录缓存

下面说一下另一个参数，rcnum。

首先必须申明的是这个参数指定的机制和上面的机制完全不同。

rcnum参数控制的是缓存在内存中的记录条数，他的存储形式是TC的TCMDB表，可以理解为一个内存key-value系统，完全等价于MC， 这个参数设置了其最大缓存条数，像我们在做get操作的时候，全部都是先从这个tcmdb里取数据，取不到再通过的tchdb来取。所以这个参数完全只是 挡在前面的一层缓存层。

至于数据超出这个数据之后，哪些被缓存，哪些被踢掉，作者文档里写了是按LRU(Least recently used)原则设计的算法实现的，不好意思，这块我还没看。就不多说了。

这个记录缓存，在TCHDB结构里是一个名叫recc（records cache）的指针。

闲话

前面看了很多其它方面的东西，比如线程模式等，而应用层的东西几乎是完全没有关心，比如上面这几个参数的具体作用，其实这才是具体应用中应该注意的 东西。感谢codytan同学与我进行的讨论，让我有机会去了解这方面的内容。同时欢迎各位有实际应用经验的同学讨论实际遇到的性能及稳定性方面的问题。