请注意Tokyo Tyrant (ttserver)在大数据量下的不稳定

[文章作者：孙立 链接：http://www.cnblogs.com/sunli/ 更新时间：2010-06-20]

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进行替换掉。