场景是这样的：我们现在的应用就是使用多线程技术实现多任务分布式计算，通过Terracotta DSO特性，来实现集群。在我们的项目中会涉及到Buyside 和 SellSide。Buysides会发大量的信息（订单）到我们的应用，SellSide会发处理结果到我们的应用 我们的应用就类似于一个转换器。我们的应用是用一个LinkedBlockingQueue当做接受任务的容器，然后再由处理程序去处理LBQ里面的任务如果结合TC 把LBQ作为DSO ROOT 那么把我们应用部署到到多台APP SERVER(TC CLIENT)后处理程序就会增多,按照原理，处理速度应该会增快。但事实上，经过我们测试后，发现性能并没有多大的提高，是不是有些地方我忽视了，或者说terracotta不适合我们的这种业务场景？
2012年03月14日 09:41 "@MichelleAnn"的内容
那么把我们应用部署到到多台APP SERVER(TC CLIENT)后处理程序就会增多,按照原理，处理速度应该会增快。但事实上，经过我们测试后，发现性能并没有多大的提高 ...
这里有几个概念需要搞清楚：吞吐量和延迟，如果部署到多台APP，按道理，是吞吐量增长，就象原来小港口现在变成大港口，货物吞吐量上去了，但是每个货物的装卸速度和兵马俑无关，也就是你所说的性能。
你所说的性能是每个页面的加载速度或每个交易的处理时间。
以上指标需要定性，可参考jivejdon的Jmeter测试结果，其中averge min max是你要的性能，而througout是吞吐量，和分布式系统有关，也就是说，你使用了集群 分布式系统是扩展了吞吐量，无法提高单机性能的。
对于你这个案例，非常类似LMAX架构，使用单线程每秒可处理600万订单，这才是你要的性能。
提高性能，向非堵塞NoBlocking方面发展，你使用的LinkedBlockingQueue是一种堵塞队列，性能肯定不高，推荐使用Disruptor替代，见这个帖子。
就是，我如果不适用TC，单台服务的性能会比多台使用TC的性能要好，如果是因为用LBQ造成的，那后来我又使用TC自己提供的那个tim-masterworker的Moudle拿去测试，貌似还是存在处理速度不行，照这样说来，应该使我们本身的应用在处理单的时候，性能不够理想，对吗？
2012年03月14日 10:12 "@MichelleAnn"的内容
照这样说来，应该使我们本身的应用在处理单的时候，性能不够理想 ...
使用TC分布式集群系统肯定影响性能，因为其有锁机制，你原来有锁，再加把锁，当然越来越慢。
锁作用是保证业务交易的事务性和安全性，但是又是性能的克星。
这时你就需要好好分析你的业务应用，分清楚哪些需要锁，哪些不需要锁，可以用不变性等其他方式替代的。
兵马俑属于一种数据网格，和一般无锁的分布式缓存如memcache和Redis区别就是其有一套锁机制，见这个案例，分析了数据网格和分布式缓存区别。
如果你的订单是将买卖双方撮合，那么使用LMAX架构非常合适，那也是一个撮合交易系统，如果类似售票系统，那么不是一种撮合，而是一种连续ID分配问题。
所以，根据你的业务特点选择合适架构。因为我无法深入了解你的系统，只能说到这里，针对性不是很强，希望对你有帮助。