一个可持久化数据的，好处是速度不错，而且大至兼容Memcached的文本协议，客户端可以继续使用SpyMemcached。 坏处是只是大致兼容，像Expired Time，CheckAndSet这些重要的原语都不支持，而且在可扩展性上没什么想象空间，和传统数据库一样的Active-Active replication。

Anyway看了一圈最后还是选了它。

2. In SpringSide3

2.1 客户端

在modules/extension项目封装了基于SpyMemcached客户端，屏蔽了一些TT不支持的特性如Binary协议，Expired Time，CheckAndSet语句，而且实现了一个spy client池--对Memcached，一个spy client单线程已足够，而对TT则必须使用池。

2.2 服务器配置

1.在servers/tokyotyrant中，演示了生产环境active-active HA模式与测试环境单机版本两种启动脚本。

生产环境脚本在原有ttservctrl的基础上作了如下修改:

打开了ulogdir，ulimsiz，sid(两台server 必须不一样)，mhost(直接填写对方的IP或用相同的host名字然后在/etc/hosts中设定对方的IP)，mport ，rtsfile 这几个HA 同步复制相关的选项。 在cmd中添加-thnum 64 (32线程，默认为8, 和memcached不一样，此处加大线程数能明显提高性能)，-uas(异步写日志) -le(日志只记录错误信息)的参数 在dbname中设置参数：xmsiz=2147483648 (用mmap映射2G文件内容到内存)，bnum=1000000(桶数量从1M增加到10M，假设TT中有大约10M数据) 在dbname中设置参数: opts=ld,使用64位地址存储大于2G的数据,使用Deflate encoding以Page为单位进行压缩(如果page内的数据内容长得有点像就会得到较高的压缩率) 在dbname中设置参数:dfunit=8, 记录被删除后会回收硬盘空间, 否则硬盘空间会哗哗的不停往上涨, 直到你手工执行tcrmgr optimized localhost为止. 测试环境脚本等于原来的ttservctrl.

2.一般采用默认的casket.tch, hash database, 如果需要进行较多的forward match操作,且主键的分布有一定规律性而不是完全随机，可考虑使用casket.tcb -- btree database, 但在大数据量下读取单条数据的性能会下降，Hash与BTree算法的天然差异决定了。

3.在双机复制环境下，产生的ulog文件非常巨大，需要定期进行清理。

4.如果数据被频繁增删，casket.tch文件会越来越大，需要执行tcrmgr optimize localhost来减肥。

5.看数据文件的大小不能用 du -sh *，用ls -lh 吧,那才是真实的.

2.3 HQ监控

在servers/hq中，增加了tokyotyrant -plugin.jar，在原有memcached-plugin.jar的基础上，对tokyotyrant实际支持的输出值进行了微调。

原理都是telnet 1978端口，执行status命令。

2.4 后续 演示

在下个版本，将会演示TT的一个很重要的私有协议--PrefixMatch，找出超时对象就靠它了，而且会扩展JMemcached支持该原语以方便测试用例编写与Windows上的开发。

<!---->