ttserver不稳定案例

　　1. CMS a系统的文章采用了ttserver存储。在数据达到30多G的时候，经常出现写入失败，还出现了几次意外崩溃，无法重启成功，只得从slave恢复数据。

　　2.CMS b系统的图片使用ttserver存储，在数据导到65G的时候出现无法写入的情况，重启后问题依旧，只得从slave重新恢复数据重启。

　　3.BBS系统采用ttserver做缓存，设计上采用如果没有更新，那么缓存永久存在的策略。在数据达到65GB，数据条数在700多万条的时候，出现大量写入失败的情况，系统负载开始上升，日志出现大量do_mc_set: operation failed。当然这里作为缓存比较好处理，删掉，重新建个新的就OK。(注：启动参数data.tch#bnum=10000000#xmsiz=434217728#rcnum=20000)

　　测试中ttserver写入表现不稳定

　　1.#bum=10000000

　　插入940多万数据(一条7.2k)时出现崩溃(测了两次都一样，看起来好像内部出现了死锁，连上后，无法进行任何响应，没有任何操作时，也占了大量CPU)。越到后面插入的qps(每秒响应数)越小。而且波动比较大。

　　#bum=100000000

　　可以顺利插入上千万的数据，但是越到后面qps越小。越到后面插入的qps(每秒响应数)越小。而且波动比较大。

　　2.跟其他的nosql(mongodb,bdb je,cassandra)对比测试，在写入上，ttserver是表现最不稳定的，其他的nosql都非常好。

　　总结和注意

　　1.经过对Tokyo Cabinet的测试，同样跟ttserver一样，所以应该是Tokyo Cabinet 导致的不稳定。在选择btree方式存储时，随着数据量的增加一样不稳定。在优化参数上也做了各种尝试。

　　2.ttserver在性能的表现上非常不俗，特别是内存占用和cpu占用都很低，能同时响应上万的并发。但是你应该注意，他一般在数据导到20G以上就会出现不稳定情况。

　　所以用ttserver来存储单条比较小的数据非常好，存储大文本或者大的二进制文件，由于空间占用上升很快，很快就会变得不稳定。

　　3.注意备份，使用master-slave是个非常好的主意，在ttserver崩溃导致文件损坏或者其他什么原因无法启动时，你可以从slave 拷贝数据文件来进行恢复。

　　4.如果你一定要使用ttserver，建议对数据进行分片(sharding)存储，或者你自己使用一个网络接口，底层使用Tokyo Cabinet 来进行分片存储。

　　5.以上只是个人在使用中遇到的情况，本人正在尝试在存储大文本的ttserver进行替换掉。

　　注：Tokyo Cabinet 是日本人 Mikio Hirabayashi(平林干雄)のページ 开发的一款DBM数据库(注：大名鼎鼎的DBM数据库qdbm就是他开发的)，该数据库读写非常快。insert:0.4sec/1000000 recordes(2500000qps)，写入100万数据只需要0.4秒。search:0.33sec/1000000 recordes (3000000 qps)，读取100万数据只需要0.33秒。下图为各种key-value数据库读写数据的性能测试，可以看出Tokyo Cabinet的速度是非常快的。

　　Tokyo Tyrant 提供dbm数据库Tokyo Cabinet的网络接口。它使用简单的基于TCP/IP的简单二进制协议进行通信。同时它拥有Memcached兼容协议并且可以用HTTP/1.1协议进行数据交换。所以实现了跨平台，跨语言使用Tokyo Tyrant。采用热备份，更新日志记录，复制(replication)来实现高可用性和高可靠性。到目前为止，Tokyo Tyrant只能运行在linux, FreeBSD, Mac OS X, Solaris。