复制方式比较

　　tt server 和 redis 都支持 master-slave 方式的通信复制。

　　tt server 使用了 ulog，并且 slaver 使用了 rts(replication time-stamp) 文件，对上一次的复制时间戳进行保存，实现了复制的续传。

　　而 redis 则是每次 slave 重新连接到 master 时，master 会将数据进行全量的复制给 slave，而不是增量式的。redis 复制的方式与使用 RDB 持久化方式原理基本相同，也是使用子进程进行内存的dump，在此期间，父进程收集改变数据库的命令，等把子进程收集的数据传输给 slave 之后，再将此期间收集到的数据也传输给 slave。

　　如果从 slave 数据重建的角度来看，tt server 支持断点复制的实现，应该说是比 redis 先进了一步。

　　性能方面比较

　　新浪的 Tim Yang 做了 memcacheDB、Redis、tt server 的性能测试。这是比较早期的测试，相信随着版本的升级，两者的性能都会有所提升。不过按照这个测试的结果来看，redis 在数据量不多(500W)并且value 较小的时候，性能表现是很优越的;而对于稍大一些的 value ，tt 则在写方面表现很出色，但读的性能，相对较差。相比之下，redis的读写性能，倒是比较平衡。

　　但觉得随着时间的迁移，这个测试的参考性可能会打折扣，如果有可能的话，希望能看到更多的测试结果。

　　总结

　　1. 从服务器模型来说，tt server 使用 acceptor + workers 的方式提供服务，能够利用多核的性能，但随着而来的是一些同步、加锁的复杂和开销;而 redis 使用了单线程提供服务，利用不了多核，但如果能够将每次服务的速度控制下来，对单个CPU的利用率，反而可以提高。如果想利用机器的多核性能，也可以在一台机器上搭建多个 redis 实例，但可能更要考虑到机器的内存限制。

　　2. 从数据存储的方式来说，尽管 tt server 和 redis 都是将数据存储在内存中，但我认为两个产品对“数据是如何存储”的观点是有所不同的。tt server 认为数据是存储在文件中的，只是通过内存映射，将对文件的操作转化成对内存的操作;而 redis 是直接将数据存储到内存中，之后再通过持久化等机制，将数据备份到磁盘中。虽然之前 redis 自己实现了 vm 功能，但redis 后续会取消掉自己实现的 vm 功能，按照“内存是最新的磁盘”这种思路，也就不难理解了：除了增加复杂度之外，还有一个因素，那就是 redis 不需要 vm，能存的数据大小，只能限制在物理内存的范围以内。

　　从这个方面来将，redis 后续的版本可能就会限制用户使用的数据库大小是要小于物理内存的，而如果使用 tt server ，则用户须让使用数据文件小于物理内存，否则，发生内存交换，是非常损性能的。

　　总而言之，在使用内存数据库的时候，应该有意识的对数据进行容量规划，避免出现物理内存不够而引起的内存交换。

　　3. tt server 和 redis 的策略都是从 slaver 配置 master ，而不是从 master 配置 slaver 关系，这样就减轻了 master 的负担，同时，master 不必知道自己有多少个 slaver ，就可以横向的扩增 slaver 。但 tt server 支持所谓的断点复制。需要考虑到的是 redis 在做 replication 的时候，是 fork 一个子进程工作的，如果有多个 replicate 的请求，redis 依然还是一个子进程在工作。这样也会对多个 slaver 产生一定的复制延时。

　　4. redis 在工作方式上，会 fork 子进程，因此 redis 在容量规划上，需要考虑到 redis fork 出子进程所需要的内存和 CPU，在最差的情况下：bgsave时候，父子两个进程虽然可以使用 copy on write 的好处，但如果在此期间整个表记录都被修改了，那就足足需要一倍的内存，否则，此时父进程会进行 copy ，父进程很可能没有内存可用，就需要进行内存交换，由此所带来的性能代价也是非常高的;与此同时，子进程子在 bgsave 的时候，需要对数据进行压缩，压缩是计算密集型的，因此最好不要和父进程使用同一个CPU，因为父进程使用了单线程事件处理的模型，这种模型的优点是充分利用CPU的资源，如果出现子进程与父进程抢CPU，那就得不偿失了。

　　5. redis 支持较多的数据结构，但在使用 sort 等时间复杂性较多的命令时，也会稍微的降低 redis 的性能，应该对这些耗时的命令进行一定的监控。