集群分布式

做互联网、做电子商务，我们都盼望着用户数和访问量不断的攀升，这意味着我们将有更多的业务，将有更多的订单，将会有更多的盈利。欣喜之余，我们开始有更多的担忧，我们的应用能不能抗得住啊，当一个个的问题在高访问量的时候一个个的暴露出来时，我们的压力也就接踵而来，我们忙前忙后焦头烂额。这样的景象不知道大家有没有经历过，不好意思我还没有。俗话说，未雨绸缪，早做准备永远都是好事。在设计OECP社区的时候，我早早的设计了OECP社区未来的运行环境，负载均衡，分布式集群，反向代理，缓存，文件系统，并在程序的架构上分离了平台层和应用层，正当我暗自得意的时候，一盆冷水让我从骄傲中苏醒过来。我平时一再吹嘘的通过可无限扩展的服务器集群方式解决系统压力的方案一下子出了问题。我一再提倡要将传统的将压力嫁祸于数据库的做法前置到应用服务器，通过应用服务器可扩展集群的能力来解决系统性能问题，这种思路我始终认为是对的，那又是什么问题让我坐立不安呢？

       独立应用可以透明的迁移到集群结构中，这种认识是错误的。尽管一些供应商宣称他们的J2EE产品有这样的灵活性。不要相信他们！事实你要在开始系统设计时就要准备集群，而这将影响开发和测试的所有阶段。

        1、Http Session

       在集群环境中，使用HTTP Session有很多限制，这取决于你的应用程序服务器采用了哪种会话失效转移的机制。如果负载集群采用的一个会话始终是连接的一个应用服务器，那么带来的影响还是可以容忍的。只是当这个应用服务器断开的时候，用户的此次请求也将断掉无法访问，而不能切换到其他服务器。如果你采取了会话失效转移，或者直接根据压力轮询路由应用服务器，虽然可以保持用户的请求不会断掉，但是其他的问题来了。你必须做的处理的就是session的复制或者同步，虽然很多应用服务器有这方面的能力，但是一个重要的限制就是所有保存的HTTP Session中的对象必须是可序列化的，这将限制设计和应用程序结构。我们可以问一下自己，我们session中放置的都是可序列化的吗？如果不是，你完了。即使我们都是放置的可序列话的对象，对象的序列的反序列化对性能的影响很大，如果你的集群节点很多，session的对象又放了很多，session的同步将会出现形成服务器间的IO阻塞。所以不要什么东西都往session中放。

        2、缓存

        我们采用缓存来提升系统的性能，降低数据库的压力，这种思路绝对是正确的，对于单应用服务器来说也是绝对没有问题的。但是在集群环境下，问题又来了。在集群环境，每个JVM实例都要维护一份缓存的拷贝，这些拷贝必须同步以维持所有服务器实例状态的一致性。有时这种类型的同步会比没有缓存带来更糟的性能。而更可怕的是我们根本就没考虑到同步缓存，造成数据的不一致。集群环境下，我们需要考虑使用的缓存产品支不支持分布式，我们自己写的缓存实现在集群下有没有同步的功能。

        3、单例和静态变量

        当我们设计J2EE应用程序时，在架构上经常会使用一些设计模式。这些如“Singleton”的设计模式会用到静态变量来在多对象之间共享状态。这种方式在单服务中工作得很好，但在集群环境将失效。一个使用静态变量的例子就是用它来保持在线用户数。用静态变量来保存在线用户数是一个很简单的办法，当用户进入或离开时就增加和减少它。这种方式在单服务器中绝对是好的，但在集群环境将失效。在集群中更好的方式是将所有状态保存到数据库，或者全局的缓存中。

       4、文件操作和外部资源

       一些应用会使用文件系统来保存用户上传的文件，或是创建一个动态配置的XML文件。在集群环境是没有办法来在其他实例之间来复制这些文件的。为了在集群中工作，办法是用数据库作为外部文件的存放点，另外也可以使用SAN（存储区域网，Storage Area Network）作为存放点。对于文件上传下载，我们最常用的做法就是采用文件服务器统一存取。

       5、一些特殊服务

       一些特殊的服务只在独立的环境中才有意义，定时服务就一个很好例子，这种服务可以在一个固定的间隔时间有规律的触发。定时服务常用于执行一些自动化管理任务。如日志文件滚动，系统数据备份，数据库一致性检查和冗余数据清理等。对于这些服务，他们大部分不是由请求触发的，负载均衡是没有任何用处的，如果迁移到集群中，有些服务也是固定在某台应用服务器上的，而不是每个服务器上都要开启这些服务。

        看了上面总结的这些问题，你还敢拍着胸脯说，我的系统可以迁移到集群中，我们的系统在压力大了之后可以做负载均衡啊？有些问题是可以在系统的演变升级中逐渐完善的，但是有些问题就需要我们在设计和开发阶段就要去思考，并做出相应的解决方案的。WHY总是先于HOW的，先去分析然后再做，多动脑子总比光动手要好得多。从上面的一些问题引申出的一些思考：

       1、一个好的架构师是多么的重要，不要以为他们没有像牛一样的工作就遭到鄙夷，他们在用脑子工作，他们的能力就是分析问题，防患于未然。我们每个人都应该向着能防范问题的方向去思考和发展。

       2、是自我吹嘘也罢，我依然认为我做了一个正确的决定，将系统抽象出了平台层和应用层。以上出现的大部分问题，我们都可以在平台层上去做正确的实现方案，然后将API暴露给应用层。比如我们统一封装支持分布式的缓存，对于静态变量的处理，我们在平台层上可以采用全局分布式缓存或者KEY-VALUE数据库这样的方案来进行替代，并公布API。平台层的建立，有效的降低了应用层的开发难度，让他们更关注业务，而不是太多的技术细节。平台层可以制定相应的技术标准和规范，可以持续不断的积累完善，可以被更多系统复用，对于一个团队发展都是有好处的。

        3、一个建议，尽量不要让一个业务型的项目经理来做架构设计的工作，他们的关注点是截然不同的，他只会关注进度，这对架构设计没有任何好处。

 

集群部署需要注意的问题

1、往session里边放的东东要实现序列化的接口（session复制用）

2、因为session要复制，所以session里边的东西要尽可能的少，否则可能集群性能还不如单机

3、集群下没有真正单例的实现，所以不要用单态模式来保存集群内所有服务器都需要的状态，比如程序的某个全局变量，可以考虑用jndi来实 现。不过相信好的程序这么做的并不多。

4、同步问题也要注意~比如不要试图用加同步来实现取得最大id这样的操作，可以通过保存到数据库的手段来解决这个问题

5.特别要注意缓存的情况，大部分开源的缓存实现是不支持集群的。这时候要全面考虑你需要的缓存情况再定夺。比较省事的办法是不用缓存 缓存的作用不是任何时候都很大，比如客户查询话费祥单记录，越加缓存越坏事）。如果对数据实时性要求不算高那也好说，定期的重建缓 存就是了。如果都不行，只有使用jboss cache等支持集群的cache实现。或者采用某些商业性的实现。