关于系统性能的思考

原始讨论贴：

[url]http://www.iteye.com/post/992758[/url]

1.确实是有系统如你所说，几乎每步操做都需要极其严格的事务要求（严格序列化，说的通俗点叫做先后顺序必须要保证），单单说到这其实还是比较好实现的，一般的消息队列都能做到这个效果（脑子里先去除关系数据库的桎梏）。但是有些系统除了严格的序列化，还需要有非常高的实时性要求，假设包括外部因素总延时在5秒之内吧，上交所的股票交易系统就是这样的一个典型例子。

这样的系统不是不能做，但是代价太大，而且做法和通常的做法完全不一样，基本没有什么普遍性可言。他们的做法，说的简单点就是全内存操作，巨大的内存几乎加载了所有必要的实时数据。。。

2.第一个例子过于极端，说说第二种情况，绝大多数的银行吧，为了保证核心系统（实际是记账中心）的交易无差错，基本上所有的操作最终都集中在一台大型机上，跑数据库的（你不要幻想数据库集群能有效的提高性能，那是骗人的）。

3.从第二个例子中的数据库集群骗人事件，引出，如果你仔细看过 J2EE Without EJB的话，我记得好像有这么一句话，最好的分布式就是不要做分布式，感觉有点故弄玄虚，主要意思是这样的，一个通常的分布式集群的系统，其各个节点间的通讯（包括各种同步等的开销）代价往往会把集群带来的性能提升完全抵消掉，而且这样的集群基本没有线性的扩展性，集群的机器数量越多，集群中节点间的通讯的代价就越发恐怖。SNA的思想就是尽可能避免这种依赖于一种集中式集群的瓶颈。我个人还认为，节点间互相关系密切的集群系统的集成测试和运维、升级的复杂度是惊人的高的，成本巨大。

4.我再从另一个角度来说，第一点提到消息队列，恩，当你把一个消息队列的功能做得非常完善，或者说当你把一个缓存系统做得非常完善，例如加上一些类似于数据库的事务控制，那你可能就是在自己造一个分布式数据库了。Memcached DB算是一个这样的典型例子吧。这种缓存系统作为产品拿来用用还是比较靠谱的，自己造，而且要没有什么bug，这代价好像大了点吧。

5.如第四点所说，应该把缓存结构独立出来，单独考虑，例如你要用Memcached服务做缓存服务器，先和原本的J2EE的架构分离出来，JVM本身就是大小限制的，真要用Java做大的缓存框架，其实限制是很多的。所以不要迷信各级缓存，缓存结构不是你想像的那么简单的，不仅仅是开发和设计、调试和部署的成本都非常高。

6.做项目好像人生，不如意十有八九，预算成本和时间成本都是有限的，又要结构简单，又要效果好，往往得从业务出发，简单的例子我前面讲过，例如某些实时性要求不高的查询完全可以放弃实时性，可以用来获取简单的结构，和避开性能瓶颈。而复杂的例子，例如寻找外星人的项目，或者是Google的Map/Reduce，或者是林登实验室的Second Life的分布式计算结构，都是针对特殊的业务设计的。这些都不是传统的编程手段或技术能直接实现的。

7.拓展一下思路吧，第六点提到的简单例子“例如某些实时性要求不高的查询完全可以放弃实时性，可以用来获取简单的结构”，这个例子貌似简单，如果对查询的实时性要求不高，但是查询速度要求很高的话，楼主可以看看数据仓库的概念，不是要楼主学习数据仓库，而是拓展一下思路，思维不要局限在Java或者说JVM上，不要局限在事务型关系数据库存储上。

8.再做个引申，大量的事务型操作其实是很容易造成瓶颈的，但是有时候适当的一些假设，就能够部分的不使用事务，例如假设某张表中没有update和delete操作，只有insert操作，整个业务模块按照这个假设设计就能够很简单的实现，实际上现实世界中的财务流水帐在业务模型上就是这么设计的。。。

9.你有一定的项目经验，一般能根据需求估算出一个系统的各方面的负载有多大，然后再根据以往项目实施的经验，就能比较靠谱的掌握一个性能、成本的平衡点了。