集群、分布式你想好怎么用了吗?

标签: 集群 分布 | 发表时间:2014-01-07 17:36 | 作者:xiushan
出处:http://www.iteye.com

集群、分布式你想好怎么用了吗?

       做互联网、做电子商务,我们都盼望着用户数和访问量不断的攀升,这意味着我们将有更多的业务,将有更多的订单,将会有更多的盈利。欣喜之余,我们开始有更多的担忧,我们的应用能不能抗得住啊,当一个个的问题在高访问量的时候一个个的暴露出来时,我们的压力也就接踵而来,我们忙前忙后焦头烂额。这样的景象不知道大家有没有经历过,不好意思我还没有。俗话说,未雨绸缪,早做准备永远都是好事。在设计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、一个建议,尽量不要让一个业务型的项目经理来做架构设计的工作,他们的关注点是截然不同的,他只会关注进度,这对架构设计没有任何好处。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [集群 分布] 推荐:

BDRP分布式redis集群

- - 百度运维团队技术博客
BDRP(baidu distributed redis platform)是包含 twemproxy, redis,redis-sentinel等多个模块开发的分布式redis平台. bdrp已经在github上进行了开源, bdrp的github项目点这里. 目前redis集群架构主要有以下几个组件: twemproxy:redis的代理系统,可以选择多种数据分片算法 redis:集群的redis存储节点 sentinel:redis官方的集群高可用组件,可以监控redis主节点故障,并进行主备切换.

Nutch1.8+Hadoop1.2+Solr4.3分布式集群配置

- - 开源软件 - ITeye博客
Nutch 是一个开源Java 实现的搜索引擎. 它提供了我们运行自己的搜索引擎所需的全部工具. 当然在百度百科上这种方法在Nutch1.2之后,已经不再适合这样描述Nutch了,因为在1.2版本之后,Nutch专注的只是爬取数据,而全文检索的部分彻底的交给Lucene和Solr,ES来做了,当然因为他们都是近亲关系,所以Nutch抓取完后的数据,非常easy的就能生成全文索引.

Hadoop2.1全分布式集群安装

- - CSDN博客云计算推荐文章
每台机器上用于安装和启动hadoop的用户名都是xc. 节点的hostname、安装的服务和ip如下:. 每个节点上的jdk已经装好了. 还需要设置ssh无密钥登录. 我设置了h1-1和h1-2到所有节点的ssh无密钥登录,必须使得h1-1和h1-2这两个master都能够无密钥ssh登陆其他所有节点,包括自己.

分布式与集群的区别

- - 博客园_知识库
  简单说,分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数来提升效率.   如果一个任务由10个子任务组成,每个子任务单独执行需1小时,则在一台服务器上执行改任务需10小时.   采用分布式方案,提供10台服务器,每台服务器只负责处理一个子任务,不考虑子任务间的依赖关系,执行完这个任务只需一个小时.

分布式和集群区别

- - 开源软件 - ITeye博客
分布式:一个业务分拆多个子业务,部署在不同的服务器上. 集群:同一个业务,部署在多个服务器上. 集群是解决高可用的,而分布式是解决高性能、高并发的. 1:分布式是指将不同的业务分布在不同的地方. 而集群指的是将几台服务器集中在一起,实现同一业务. 分布式中的每一个节点,都可以做集群. 举例:就比如新浪网,访问的人多了,他可以做一个群集,前面放一个响应服务器,后面几台服务器完成同一业务,如果有业务访问的时候,响应服务器看哪台服务器的负载不是很重,就将给哪一台去完成.

分布式集群环境hadoop、hbase、zookeeper搭建(全)

- - CSDN博客云计算推荐文章
集群环境至少需要3个节点(也就是3台服务器设备):1个Master,2个Slave,节点之间局域网连接,可以相互ping通,下面举例说明,配置节点IP分配如下:. 三个节点均使用centos 6.3系统,为了便于维护,集群环境配置项最好使用相同用户名、用户密码、相同hadoop、hbase、zookeeper目录结构.

亿级Web系统搭建——单机到分布式集群

- - 博客园_知识库
  当一个Web系统从日访问量10万逐步增长到1000万,甚至超过1亿的过程中,Web系统承受的压力会越来越大,在这个过程中,我们会遇到很多的问题. 为了解决这些性能压力带来问题,我们需要在Web系统架构层面搭建多个层次的缓存机制. 在不同的压力阶段,我们会遇到不同的问题,通过搭建不同的服务和架构来解决.

集群、分布式你想好怎么用了吗?

- - 互联网 - ITeye博客
集群、分布式你想好怎么用了吗.        做互联网、做电子商务,我们都盼望着用户数和访问量不断的攀升,这意味着我们将有更多的业务,将有更多的订单,将会有更多的盈利. 欣喜之余,我们开始有更多的担忧,我们的应用能不能抗得住啊,当一个个的问题在高访问量的时候一个个的暴露出来时,我们的压力也就接踵而来,我们忙前忙后焦头烂额.

quartz集群分布式(并发)部署解决方案-Spring

- - 企业架构 - ITeye博客
项目中使用分布式并发部署定时任务,多台跨JVM,按照常理逻辑每个JVM的定时任务会各自运行,这样就会存在问题,多台分布式JVM机器的应用服务同时干活,一个是加重服务负担,另外一个是存在严重的逻辑问题,. 比如需要回滚的数据,就回滚了多次,刚好quartz提供很好的解决方案. 集群分布式并发环境中使用QUARTZ定时任务调度,会在各个节点会上报任务,存到数据库中,执行时会从数据库中取出触发器来执行,如果触发器的名称和执行时间相同,则只有一个节点去执行此任务.

HBase入门笔记(四)--完全分布式HBase集群安装配置

- - 学着站在巨人的肩膀上
HBase 是一个开源的非关系(NoSQL)的可伸缩性分布式数据库. 它是面向列的,并适合于存储超大型松散数据. HBase适合于实时,随机对Big数据进行读写操作的业务环境. 关于HBase的更多介绍请参见 HBase项目官网.     本文环境与上一讲-- 完全分布式Hadoop集群配置一致.