这里有几个概念需要搞清楚：吞吐量和延迟，如果部署到多台APP，按道理，是吞吐量增长，就象原来小港口现在变成大港口，货物吞吐量上去了，但是每个货物的装卸速度和兵马俑无关，也就是你所说的性能。

你所说的性能是每个页面的加载速度或每个交易的处理时间。

以上指标需要定性，可参考jivejdon的Jmeter测试结果，其中averge min max是你要的性能，而througout是吞吐量，和分布式系统有关，也就是说，你使用了集群 分布式系统是扩展了吞吐量，无法提高单机性能的。

对于你这个案例，非常类似LMAX架构，使用单线程每秒可处理600万订单，这才是你要的性能。

提高性能，向非堵塞NoBlocking方面发展，你使用的LinkedBlockingQueue是一种堵塞队列，性能肯定不高，推荐使用Disruptor替代，见这个帖子。

恩，十分感谢你的回复，你给的参考我马上去看，这里先再补充一个问题。

就是，我如果不适用TC，单台服务的性能会比多台使用TC的性能要好，如果是因为用LBQ造成的，那后来我又使用TC自己提供的那个tim-masterworker的Moudle拿去测试，貌似还是存在处理速度不行，照这样说来，应该使我们本身的应用在处理单的时候，性能不够理想，对吗？

使用TC分布式集群系统肯定影响性能，因为其有锁机制，你原来有锁，再加把锁，当然越来越慢。

锁作用是保证业务交易的事务性和安全性，但是又是性能的克星。

这时你就需要好好分析你的业务应用，分清楚哪些需要锁，哪些不需要锁，可以用不变性等其他方式替代的。

兵马俑属于一种数据网格，和一般无锁的分布式缓存如memcache和Redis区别就是其有一套锁机制，见这个案例，分析了数据网格和分布式缓存区别。

如果你的订单是将买卖双方撮合，那么使用LMAX架构非常合适，那也是一个撮合交易系统，如果类似售票系统，那么不是一种撮合，而是一种连续ID分配问题。

所以，根据你的业务特点选择合适架构。因为我无法深入了解你的系统，只能说到这里，针对性不是很强，希望对你有帮助。