集群、分布式、性能

性能是一个多方面综合的结果，遵循短板理论。系统中任何一个部分成为性能瓶颈，都会影响整个系统的性能表现

对于WEB应用，首先第一步是响应HTTP请求，即使后端的性能再好，如果在这里出现瓶颈，整个系统的性能也会很差，类似于一个很大的水瓶，但是入水口很小。在这个环节，可以通过DNS分流，负载均衡等方式改善。另外，现在高性能的HTTP服务器（Nginx、node.js等）本身，由于采用了事件通知等设计方式，单个线程可以响应多个HTTP请求，减少了线程创建和切换的开销（CPU与内存），也可以显著提升响应HTTP请求的性能

接受请求之后，则进入系统后端进行业务逻辑处理，在这里也会产生性能瓶颈。通过集群的方式，可以有效改善。因为单台服务器的硬件总是有限的，受限于CPU和内存，单台机器能够处理的负载终究是有限的，这时可以采用集群方案，将请求分摊到不同的服务器上处理。这对应用的实现本身是有要求的，基本上要求应用是“无状态”的。比如如果应用的业务逻辑依赖session，那么集群就无法简单地实现，还需要加入session同步的策略等。另外应用本身的代码也会有影响，比如在关键路径上使用了synchronized，那么就只能串行处理，对性能肯定有影响

集群不等于分布式。当应用的规模大到一定程度，简单的集群也无法支撑，这时候往往还需要考虑分布式，对系统进行拆分，充分利用硬件的性能，达到最大的扩展性。此外，即使不考虑性能，将系统拆分，实现“服务化”，对于功能的扩展也是很有帮助的。比如说，只有单个系统时，用户管理可以和业务系统放在一起；但是当应用规模不断增大，有100个系统，那么把用户管理拆分出来，就可以在100个系统中实现这部分功能的共享

最后到了持久层，这里往往会涉及到大量的IO读写，这是最容易产生性能瓶颈的地方。传统的RDBMS本质上是一个单机系统，并且需要遵循ACID的约束。所以传统的关系数据库的扩展性是很差的。比如说，我们用到了数据库集群，这可以解决服务可用性的问题（主备倒换），容灾的问题（数据冗余），对性能也有一定的帮助（同时响应更多的数据库连接请求）。但是仅仅这样还不够，因为前面说过RDBMS本质上是单机系统，即使用了集群亦然。什么意思呢？集群仅仅解决了多连接并发的问题，但是数据库本身插入、查询，涉及到大量的IO，就已经成为了瓶颈，尤其在数据量很大的情况就更加明显。所以仅仅是集群还不够，这时候就需要分表（水平拆分），这对系统的代码就有要求，什么样的数据，要到哪个表里查询，都需要遵循一定的规则。有一个办法是，将数据库路由的功能放在JDBC之下，数据库之上，这样应用就只需要连接到这个数据库路由层，不用关心表的实际位置。随着数据库复杂度的上升，本来很好用的ORM，也就越来越捉襟见肘了

数据规模越来越大，遇到即使拆表也无法解决问题的时候，就需要考虑RDBMS之外的方案。比如键值数据库（Redis、Tair）、文档数据库（MongoDB）等NOSQL技术，甚至还有文件系统（GFS、TFS），当然缓存也是很常见的重要方案

总的来说，性能是一个很大的话题。为了实现高性能，系统的架构是随着业务的发展，逐步演化的，从一开始就设计一个大规模的架构，绝非明智之举。“先实现功能，再按需优化”，才是比较好的策略。在这个过程中，既需要前瞻的眼光，也需要推倒重来的勇气

如同DOTA的路人和CW是2个不同的游戏一样；同样的应用，在小规模场景，和大规模场景（高并发、海量数据）下，也是完全不同的两回事，为了实现同样的功能，架构和实现上可能是千差万别的

集群、分布式、性能

总结的很好，面试的时候可以吹吹了

“先实现功能，再按需优化”，难啊！领导都是想一步到位。

纸上谈兵　　

大方向都好理解，到具体的实施时就会有各种各样的问题要解决了。