来源: 互联网  发布时间: 2013-11-30

PHP现在推出5.3.0版本了，不过下载的时候有几个不同版本选择。那就是VC6 X86和VC9 X86。
首先我来解答:

VC6是什么？
VC6就是legacy Visual Studio 6 compiler，就是使用这个编译器编译的。

VC9是什么？
VC9就是the Visual Studio 2008 compiler，就是用微软的VS编辑器编译的。
那我们如何选择下载哪个版本的PHP呢？
如果你是在windows下使用Apache+PHP的，请选择VC6版本；
如果你是在windows下使用IIS+PHP的，请选择VC9版本；

那Non Thread Safe是什么？
Non Thread Safe就是非线程安全；

Thread Safe 是什么?
Thread Safe 是线程安全；
官方并不建议你将Non Thread Safe 应用于生产环境，所以我们选择Thread Safe 版本的PHP来使用。
php下载页面：http://windows.php.net/download/

    

    来源: 互联网  发布时间: 2013-11-30

摘要 内存管理对于长期运行的程序，例如服务器守护程序，是相当重要的影响；因此，理解PHP是如何分配与释放内存的对于创建这类程序极为重要。本文将重点探讨PHP的内存管理问题。

一、 内存
在PHP中，填充一个字符串变量相当简单，这只需要一个语句"＜?php $str = 'hello world '; ?＞"即可，并且该字符串能够被自由地修改、拷贝和移动。而在C语言中，尽管你能够编写例如"char *str = "hello world ";"这样的一个简单的静态字符串；但是，却不能修改该字符串，因为它生存于程序空间内。为了创建一个可操纵的字符串，你必须分配一个内存块，并且通过一个函数（例如strdup()）来复制其内容。

由于后面我们将分析的各种原因，传统型内存管理函数（例如malloc()，free()，strdup()，realloc()，calloc()，等等）几乎都不能直接为PHP源代码所使用。

二、 释放内存
在几乎所有的平台上，内存管理都是通过一种请求和释放模式实现的。首先，一个应用程序请求它下面的层(通常指"操作系统")："我想使用一些内存空间"。如果存在可用的空间，操作系统就会把它提供给该程序并且打上一个标记以便不会再把这部分内存分配给其它程序。

当应用程序使用完这部分内存，它应该被返回到OS；这样以来，它就能够被继续分配给其它程序。如果该程序不返回这部分内存，那么OS无法知道是否这块内存不再使用并进而再分配给另一个进程。如果一个内存块没有释放，并且所有者应用程序丢失了它，那么，我们就说此应用程序"存在漏洞"，因为这部分内存无法再为其它程序可用。

在一个典型的客户端应用程序中，较小的不太经常的内存泄漏有时能够为OS所"容忍"，因为在这个进程稍后结束时该泄漏内存会被隐式返回到OS。这并没有什么，因为OS知道它把该内存分配给了哪个程序，并且它能够确信当该程序终止时不再需要该内存。

而对于长时间运行的服务器守护程序，包括象Apache这样的web服务器和扩展php模块来说，进程往往被设计为相当长时间一直运行。因为OS不能清理内存使用，所以，任何程序的泄漏-无论是多么小-都将导致重复操作并最终耗尽所有的系统资源。

现在，我们不妨考虑用户空间内的stristr()函数；为了使用大小写不敏感的搜索来查找一个字符串，它实际上创建了两个串的各自的一个小型副本，然后执行一个更传统型的大小写敏感的搜索来查找相对的偏移量。然而，在定位该字符串的偏移量之后，它不再使用这些小写版本的字符串。如果它不释放这些副本，那么，每一个使用stristr()的脚本在每次调用它时都将泄漏一些内存。最后，web服务器进程将拥有所有的系统内存，但却不能够使用它。

你可以理直气壮地说，理想的解决方案就是编写良好、干净的、一致的代码。这当然不错；但是，在一个象PHP解释器这样的环境中，这种观点仅对了一半。

三、 错误处理
为了实现"跳出"对用户空间脚本及其依赖的扩展函数的一个活动请求，需要使用一种方法来完全"跳出"一个活动请求。这是在Zend引擎内实现的：在一个请求的开始设置一个"跳出"地址，然后在任何die()或exit()调用或在遇到任何关键错误(E_ERROR)时执行一个longjmp()以跳转到该"跳出"地址。

尽管这个"跳出"进程能够简化程序执行的流程，但是，在绝大多数情况下，这会意味着将会跳过资源清除代码部分(例如free()调用)并最终导致出现内存漏洞。现在，让我们来考虑下面这个简化版本的处理函数调用的引擎代码：

当执行到php_error_docref()这一行时，内部错误处理器就会明白该错误级别是critical，并相应地调用longjmp()来中断当前程序流程并离开call_function()函数，甚至根本不会执行到efree(lcase_fname)这一行。你可能想把efree()代码行移动到zend_error()代码行的上面；但是，调用这个call_function()例程的代码行会怎么样呢？fname本身很可能就是一个分配的字符串，并且，在它被错误消息处理使用完之前，你根本不能释放它。

注意，这个php_error_docref()函数是trigger_error()函数的一个内部等价实现。它的第一个参数是一个将被添加到docref的可选的文档引用。第三个参数可以是任何我们熟悉的E_*家族常量，用于指示错误的严重程度。第四个参数（最后一个）遵循printf()风格的格式化和变量参数列表式样。

四、 Zend内存管理器
在上面的"跳出"请求期间解决内存泄漏的方案之一是：使用Zend内存管理(ZendMM)层。引擎的这一部分非常类似于操作系统的内存管理行为-分配内存给调用程序。区别在于，它处于进程空间中非常低的位置而且是"请求感知"的；这样以来，当一个请求结束时，它能够执行与OS在一个进程终止时相同的行为。也就是说，它会隐式地释放所有的为该请求所占用的内存。图1展示了ZendMM与OS以及PHP进程之间的关系。


图1.Zend内存管理器代替系统调用来实现针对每一种请求的内存分配。

除了提供隐式内存清除功能之外，ZendMM还能够根据php.ini中memory_limit的设置控制每一种内存请求的用法。如果一个脚本试图请求比系统中可用内存更多的内存，或大于它每次应该请求的最大量，那么，ZendMM将自动地发出一个E_ERROR消息并且启动相应的"跳出"进程。这种方法的一个额外优点在于，大多数内存分配调用的返回值并不需要检查，因为如果失败的话将会导致立即跳转到引擎的退出部分。

把PHP内部代码和OS的实际的内存管理层"钩"在一起的原理并不复杂：所有内部分配的内存都要使用一组特定的可选函数实现。例如，PHP代码不是使用malloc(16)来分配一个16字节内存块而是使用了emalloc(16)。除了实现实际的内存分配任务外，ZendMM还会使用相应的绑定请求类型来标志该内存块；这样以来，当一个请求"跳出"时，ZendMM可以隐式地释放它。

经常情况下，内存一般都需要被分配比单个请求持续时间更长的一段时间。这种类型的分配（因其在一次请求结束之后仍然存在而被称为"永久性分配"），可以使用传统型内存分配器来实现，因为这些分配并不会添加ZendMM使用的那些额外的相应于每种请求的信息。然而有时，直到运行时刻才会确定是否一个特定的分配需要永久性分配，因此ZendMM导出了一组帮助宏，其行为类似于其它的内存分配函数，但是使用最后一个额外参数来指示是否为永久性分配。

如果你确实想实现一个永久性分配，那么这个参数应该被设置为1；在这种情况下，请求是通过传统型malloc()分配器家族进行传递的。然而，如果运行时刻逻辑认为这个块不需要永久性分配；那么，这个参数可以被设置为零，并且调用将会被调整到针对每种请求的内存分配器函数。

例如，pemalloc(buffer_len，1)将映射到malloc(buffer_len)，而pemalloc(buffer_len，0)将被使用下列语句映射到emalloc(buffer_len)：
#define in Zend/zend_alloc.h:
#define pemalloc(size， persistent) ((persistent)?malloc(size): emalloc(size))

所有这些在ZendMM中提供的分配器函数都能够从下表中找到其更传统的对应实现。
表格1展示了ZendMM支持下的每一个分配器函数以及它们的e/pe对应实现：
表格1.传统型相对于PHP特定的分配器。

分配器函数 e/pe对应实现 void *malloc(size_t count); void *emalloc(size_t count);void *pemalloc(size_t count，char persistent); void *calloc(size_t count); void *ecalloc(size_t count);void *pecalloc(size_t count，char persistent); void *realloc(void *ptr，size_t count); void *erealloc(void *ptr，size_t count);
void *perealloc(void *ptr，size_t count，char persistent); void *strdup(void *ptr); void *estrdup(void *ptr);void *pestrdup(void *ptr，char persistent); void free(void *ptr); void efree(void *ptr);
void pefree(void *ptr，char persistent);

你可能会注意到，即使是pefree()函数也要求使用永久性标志。这是因为在调用pefree()时，它实际上并不知道是否ptr是一种永久性分配。针对一个非永久性分配调用free()能够导致双倍的空间释放，而针对一种永久性分配调用efree()有可能会导致一个段错误，因为内存管理器会试图查找并不存在的管理信息。因此，你的代码需要记住它分配的数据结构是否是永久性的。
除了分配器函数核心部分外，还存在其它一些非常方便的ZendMM特定的函数，例如：
void *estrndup(void *ptr，int len);
该函数能够分配len+1个字节的内存并且从ptr处复制len个字节到最新分配的块。这个estrndup()函数的行为可以大致描述如下：

在此，被隐式放置在缓冲区最后的NULL字节可以确保任何使用estrndup()实现字符串复制操作的函数都不需要担心会把结果缓冲区传递给一个例如printf()这样的希望以为NULL为结束符的函数。当使用estrndup()来复制非字符串数据时，最后一个字节实质上都浪费了，但其中的利明显大于弊。
void *safe_emalloc(size_t size， size_t count， size_t addtl);
void *safe_pemalloc(size_t size， size_t count，size_t addtl，char persistent);
这些函数分配的内存空间最终大小是((size*count)+addtl)。你可以会问："为什么还要提供额外函数呢？为什么不使用一个emalloc/pemalloc呢？"原因很简单：为了安全。尽管有时候可能性相当小，但是，正是这一"可能性相当小"的结果导致宿主平台的内存溢出。这可能会导致分配负数个数的字节空间，或更有甚者，会导致分配一个小于调用程序要求大小的字节空间。而safe_emalloc()能够避免这种类型的陷井-通过检查整数溢出并且在发生这样的溢出时显式地预以结束。
注意，并不是所有的内存分配例程都有一个相应的p*对等实现。例如，不存在pestrndup()，并且在PHP 5.1版本前也不存在safe_pemalloc()。

五、 引用计数
慎重的内存分配与释放对于PHP（它是一种多请求进程）的长期性能有极其重大的影响；但是，这还仅是问题的一半。为了使一个每秒处理上千次点击的服务器高效地运行，每一次请求都需要使用尽可能少的内存并且要尽可能减少不必要的数据复制操作。请考虑下列PHP代码片断：

在第一次调用之后，只有一个变量被创建，并且一个12字节的内存块指派给它以便存储字符串"Hello World"，还包括一个结尾处的NULL字符。现在，让我们来观察后面的两行：$b被置为与变量$a相同的值，然后变量$a被释放。

如果PHP因每次变量赋值都要复制变量内容的话，那么，对于上例中要复制的字符串还需要复制额外的12个字节，并且在数据复制期间还要进行另外的处理器加载。这一行为乍看起来有点荒谬，因为当第三行代码出现时，原始变量被释放，从而使得整个数据复制显得完全不必要。其实，我们不妨再远一层考虑，让我们设想当一个10MB大小的文件的内容被装载到两个变量中时会发生什么。这将会占用20MB的空间，此时，10已经足够了。引擎会把那么多的时间和内存浪费在这样一种无用的努力上吗？
你应该知道，PHP的设计者早已深谙此理。

记住，在引擎中，变量名和它们的值实际上是两个不同的概念。值本身是一个无名的zval*存储体（在本例中，是一个字符串值），它被通过zend_hash_add()赋给变量$a。如果两个变量名都指向同一个值，会发生什么呢？

此时，你可以实际地观察$a或$b，并且会看到它们都包含字符串"Hello World"。遗憾的是，接下来，你继续执行第三行代码"unset($a);"。此时，unset()并不知道$a变量指向的数据还被另一个变量所使用，因此它只是盲目地释放掉该内存。任何随后的对变量$b的存取都将被分析为已经释放的内存空间并因此导致引擎崩溃。

这个问题可以借助于zval（它有好几种形式）的第四个成员refcount加以解决。当一个变量被首次创建并赋值时，它的refcount被初始化为1，因为它被假定仅由最初创建它时相应的变量所使用。当你的代码片断开始把helloval赋给$b时，它需要把refcount的值增加为2；这样以来，现在该值被两个变量所引用：

现在，当unset()删除原变量的$a相应的副本时，它就能够从refcount参数中看到，还有另外其他人对该数据感兴趣；因此，它应该只是减少refcount的计数值，然后不再管它。

六、 写复制（Copy on Write）
通过refcounting来节约内存的确是不错的主意，但是，当你仅想改变其中一个变量的值时情况会如何呢？为此，请考虑下面的代码片断：

通过上面的逻辑流程，你当然知道$a的值仍然等于1，而$b的值最后将是6。并且此时，你还知道，Zend在尽力节省内存-通过使$a和$b都引用相同的zval（见第二行代码）。那么，当执行到第三行并且必须改变$b变量的值时，会发生什么情况呢？

回答是，Zend要查看refcount的值，并且确保在它的值大于1时对之进行分离。在Zend引擎中，分离是破坏一个引用对的过程，正好与你刚才看到的过程相反：

现在，既然引擎有一个仅为变量$b所拥有的zval*（引擎能知道这一点），所以它能够把这个值转换成一个long型值并根据脚本的请求给它增加5。

七、 写改变（change-on-write）
引用计数概念的引入还导致了一个新的数据操作可能性，其形式从用户空间脚本管理器看来与"引用"有一定关系。请考虑下列的用户空间代码片断：

在上面的PHP代码中，你能看出$a的值现在为6，尽管它一开始为1并且从未(直接)发生变化。之所以会发生这种情况是因为当引擎开始把$b的值增加5时，它注意到$b是一个对$a的引用并且认为"我可以改变该值而不必分离它，因为我想使所有的引用变量都能看到这一改变"。

但是，引擎是如何知道的呢？很简单，它只要查看一下zval结构的第四个和最后一个元素（is_ref）即可。这是一个简单的开/关位，它定义了该值是否实际上是一个用户空间风格引用集的一部分。在前面的代码片断中，当执行第一行时，为$a创建的值得到一个refcount为1，还有一个is_ref值为0，因为它仅为一个变量($a)所拥有并且没有其它变量对它产生写引用改变。在第二行，这个值的refcount元素被增加为2，除了这次is_ref元素被置为1之外（因为脚本中包含了一个"&"符号以指示是完全引用）。

最后，在第三行，引擎再一次取出与变量$b相关的值并且检查是否有必要进行分离。这一次该值没有被分离，因为前面没有包括一个检查。下面是get_var_and_separate()函数中与refcount检查有关的部分代码：

这一次，尽管refcount为2，却没有实现分离，因为这个值是一个完全引用。引擎能够自由地修改它而不必关心其它变量值的变化。

八、 分离问题
尽管已经存在上面讨论到的复制和引用技术，但是还存在一些不能通过is_ref和refcount操作来解决的问题。请考虑下面这个PHP代码块：

在此，你有一个需要与三个不同的变量相关联的值。其中，两个变量是使用了"change-on-write"完全引用方式，而第三个变量处于一种可分离的"copy-on-write"（写复制）上下文中。如果仅使用is_ref和refcount来描述这种关系，有哪些值能够工作呢？
回答是：没有一个能工作。在这种情况下，这个值必须被复制到两个分离的zval*中，尽管两者都包含完全相同的数据(见图2)。

图2.引用时强制分离

　　同样，下列代码块将引起相同的冲突并且强迫该值分离出一个副本(见图3)。

图3.复制时强制分离

注意，在这里的两种情况下，$b都与原始的zval对象相关联，因为在分离发生时引擎无法知道介于到该操作当中的第三个变量的名字。

九、 总结
PHP是一种托管语言。从普通用户角度来看，这种仔细地控制资源和内存的方式意味着更为容易地进行原型开发并导致出现更少的冲突。然而，当我们深入"内里"之后，一切的承诺似乎都不复存在，最终还要依赖于真正有责任心的开发者来维持整个运行时刻环境的一致性。

    

    来源: 互联网  发布时间: 2013-11-30

先说redis
redis是一个类似memcached的key/value存储系统，它支持存储的value类型相对较多，包括string(字符串)、 list(链表)、set(集合)和zset(有序集合)。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件(这点儿个人觉得redis比memcache 在数据保存上要安全一些)，并且在此基础上实现了master- slave(主从)同步。

redis的存取性能很高，SET操作每秒钟 110000 次，GET操作每秒钟 81000 次（速度很爽！）。
Redis针对不同的存储类型对象提供了不同的命令。
redis目前提供四种数据类型：string,list,set及zset(sorted set)。
string是最简单的类型，你可以理解成与Memcached一模一个的类型，一个key对应一个value，其上支持的操作与Memcached的操 作类似。但它的功能更丰富。

list是一个链表结构，主要功能是push、pop、获取一个范围的所有值等等。操作中key理解为链表的名字。
set是集合，和我们数学中的集合概念相似，对集合的操作有添加删除元素，有对多个集合求交并差等操作。操作中key理解为集合的名字。

zset是set的一个升级版本，他在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，zset会自动重新按新的 值调整顺序。可以理解了有两列的mysql表，一列存value，一列存顺序。操作中key理解为zset的名字。

下面提供redis命令：
适合全体类型的命令
EXISTS key 判断一个键是否存在;存在返回 1;否则返回0;
DEL key 删除某个key,或是一系列key;DEL key1 key2 key3 key4
TYPE key 返回某个key元素的数据类型 ( none:不存在,string:字符,list,set,zset,hash)
KEYS pattern 返回匹配的key列表 (KEYS foo*:查找foo开头的keys)
RANDOMKEY 随机获得一个已经存在的key，如果当前数据库为空，则返回空字符串
RENAME oldname newname更改key的名字，新键如果存在将被覆盖
RENAMENX oldname newname 更改key的名字，如果名字存在则更改失败
DBSIZE返回当前数据库的key的总数
EXPIRE设置某个key的过期时间（秒）,(EXPIRE bruce 1000：设置bruce这个key1000秒后系统自动删除)注意：如果在还没有过期的时候，对值进行了改变，那么那个值会被清除。
TTL查找某个key还有多长时间过期,返回时间秒
SELECT index 选择数据库
MOVE key dbindex 将指定键从当前数据库移到目标数据库 dbindex。成功返回 1;否则返回0（源数据库不存在key或目标数据库已存在同名key）;
FLUSHDB 清空当前数据库中的所有键
FLUSHALL 清空所有数据库中的所有键

处理字符串的命令
SET key value 给一个键设置字符串值。SET keyname datalength data (SET bruce 10 paitoubing:保存key为burce,字符串长度为10的一个字符串paitoubing到数据库)，data最大不可超过1G。
GET key获取某个key 的value值。如key不存在，则返回字符串“nil”；如key的值不为字符串类型，则返回一个错误。

GETSET key value可以理解成获得的key的值然后SET这个值，更加方便的操作 (SET bruce 10 paitoubing,这个时候需要修改bruce变成1234567890并获取这个以前的数据paitoubing,GETSET bruce 10 1234567890)
MGET key1 key2 … keyN 一次性返回多个键的值

SETNX key value SETNX与SET的区别是SET可以创建与更新key的value，而SETNX是如果key不存在，则创建key与value数据
MSET key1 value1 key2 value2 … keyN valueN 在一次原子操作下一次性设置多个键和值
MSETNX key1 value1 key2 value2 … keyN valueN 在一次原子操作下一次性设置多个键和值（目标键不存在情况下，如果有一个以上的key已存在，则失败）
INCR key 自增键值
INCRBY key integer 令键值自增指定数值
DECR key 自减键值
DECRBY key integer 令键值自减指定数值

处理 lists 的命令
RPUSH key value 从 List 尾部添加一个元素（如序列不存在，则先创建，如已存在同名Key而非序列，则返回错误）
LPUSH key value 从 List 头部添加一个元素
LLEN key 返回一个 List 的长度
LRANGE key start end从自定的范围内返回序列的元素 (LRANGE testlist 0 2;返回序列testlist前0 1 2元素)
LTRIM key start end修剪某个范围之外的数据 (LTRIM testlist 0 2;保留0 1 2元素，其余的删除)
LINDEX key index返回某个位置的序列值(LINDEX testlist 0;返回序列testlist位置为0的元素)
LSET key index value更新某个位置元素的值
LREM key count value 从 List 的头部（count正数）或尾部（count负数）删除一定数量（count）匹配value的元素，返回删除的元素数量。
LPOP key 弹出 List 的第一个元素
RPOP key 弹出 List 的最后一个元素
RPOPLPUSH srckey dstkey 弹出 _srckey_ 中最后一个元素并将其压入 _dstkey_头部，key不存在或序列为空则返回“nil”

处理集合(sets)的命令（有索引无序序列）
SADD key member增加元素到SETS序列,如果元素（membe）不存在则添加成功 1，否则失败 0;(SADD testlist 3 /n one)
SREM key member 删除SETS序列的某个元素，如果元素不存在则失败0，否则成功 1(SREM testlist 3 /N one)
SPOP key 从集合中随机弹出一个成员
SMOVE srckey dstkey member 把一个SETS序列的某个元素 移动到 另外一个SETS序列 (SMOVE testlist test 3/n two;从序列testlist移动元素two到 test中，testlist中将不存在two元素)
SCARD key 统计某个SETS的序列的元素数量
SISMEMBER key member 获知指定成员是否存在于集合中
SINTER key1 key2 … keyN 返回 key1, key2, …, keyN 中的交集
SINTERSTORE dstkey key1 key2 … keyN 将 key1, key2, …, keyN 中的交集存入 dstkey
SUNION key1 key2 … keyN 返回 key1, key2, …, keyN 的并集
SUNIONSTORE dstkey key1 key2 … keyN 将 key1, key2, …, keyN 的并集存入 dstkey
SDIFF key1 key2 … keyN 依据 key2, …, keyN 求 key1 的差集。官方例子：
key1 = x,a,b,c
key2 = c
key3 = a,d
SDIFF key1,key2,key3 => x,b
SDIFFSTORE dstkey key1 key2 … keyN 依据 key2, …, keyN 求 key1 的差集并存入 dstkey
SMEMBERS key 返回某个序列的所有元素
SRANDMEMBER key 随机返回某个序列的元素

处理有序集合(sorted sets)的命令 (zsets)
ZADD key score member 添加指定成员到有序集合中，如果目标存在则更新score（分值，排序用）
ZREM key member 从有序集合删除指定成员
ZINCRBY key increment member 如果成员存在则将其增加_increment_，否则将设置一个score为_increment_的成员
ZRANGE key start end 返回升序排序后的指定范围的成员
ZREVRANGE key start end 返回降序排序后的指定范围的成员
ZRANGEBYSCORE key min max 返回所有符合score >= min和score <= max的成员 ZCARD key 返回有序集合的元素数量 ZSCORE key element 返回指定成员的SCORE值 ZREMRANGEBYSCORE key min max 删除符合 score >= min 和 score <= max 条件的所有成员。

使用体会：
个人在觉得redis速度是不用说了（很快的），但是很消耗物理内存，算是redis的一个弊端吧，redis适合数据量比较小速度更新快的类型的网站，比如社区，不适合数据比较庞大的网站，比如论坛。以前用redis应用的一个论坛帖子上，但是因为数据量太大，消耗物理内存惊人而放弃了用 redis！

再说说TTSERVER
Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。当做为Hash表数据库使用时，每个key必须是不同的,因此无法存储两个key相同的值。提供了以下访问方法:提供key,value参数来存储，按 key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM 等等是相同的，但是比它们的性能要好得多（因此可以替代它们) 当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。对于定长的数组，记录按自然数来标记存储。不能存储key相同的两条或更多记录。另外，每条记录的长度受到限 制。读取方法和hash表的一样。 Tokyo Cabinet是用C写的，同时提供c,perl,ruby,java的API。Tokyo Cabinet在提供了POSIX和C99的平台上都可用，它以GNU Lesser Public License协议发布。

tokyocabinet :一个key-value的DBM数据库，但是没有提供网络接口，以下称TC。
tokyotyrant :是为TC写的网络接口，他支持memcache协议，也可以通过HTTP操作，以下称TT。

性能:
Tokyo Cabinet 是日本人 平林幹雄 开发的一款 DBM 数据库，Tokyo Cabinet基于GNU Lesser General Public License协议发布，采用C语言开发，它可以运行在任何支持C99和POSIX平台上使用。相比一般的DBM数据库有以下几个特点：空间小，效率高，性能高，可靠性高，多种开发语言的支持（现已提供C，Perl，Ruby，Java，Lua的API），支持64位操作系统。该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。

Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。这一点，跟新浪的Memcachedb性质一样。

ttserver和memcache比较：
ttserver是数据库，memcached是缓存。两者都是保存<key，value>形式的数据，通过key进行任何操作。ttserver可以将数据持久化保存，memcached全部是保存在内存中，memcached会自动删除过期数据，最长不超过30天。memcached在和一些api配合时，能自动进行数据的出入序列化，读取反序列化。ttserver有主从复制的功能，操作日志等，这完全是数据库才有的东西。据说memcached正在对整体架构做调整，到时候支持plugin机制.会把网络，事件处理，内存存储剥离开来.以后要做基于磁盘的key-value存储就可以写一个存储引擎就成了。memcached的二次开发又步入一个小高潮。