- 浏览: 212089 次
- 性别:
- 来自: 广州
-
文章分类
最新评论
-
brenda:
...
技术选型(转) -
JavaScriptOMG:
写的真好,不知道如果是java.sql.date的话,怎么写呢 ...
Java得到下一天明天,明天时间 -
少女杀手:
和他的一摸一样,一个字都不差
http://anysky131 ...
弹出窗口代码大全 -
shipping:
字体好小啊,都没兴趣看下去了
测试网站性能的30款免费在线工具 -
ddd:
其实一切人活着的意义就在于他死前的心情是什么。
活着是多么美好
间过得很快,来新公司已经两个月了,在这两个月的时间里,自己也感受颇深。下面就说说自己的一些理解。
一 应用无状态
俗话说,一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢?咱们试想一下,假如我们在session中保存了大量与客户端的状态信息的话,那么当保存状态信息的server宕机的时候,我们怎么办?通常来说,我们都是通过集群来解决这个问题,而通常所说的集群,不仅有负载均衡,更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制,jboss采用的配对复制等session状态复制策略,但是集群中的状态恢复也有其缺点,那就是严重影响了系统的伸缩性,系统不能通过增加更多的机器来达到良好的水平伸缩,因为集群节点间session的通信会随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,我们需要保证应用的无状态性,这样集群中的各个节点来说都是相同的,从而是的系统更好的水平伸缩。
OK,上面说了无状态的重要性,那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。一般通过cookie来实现,或者也可以采用集中式session管理来完成,说具体点就是多个无状态的应用节点连接一个session 服务器,session服务器将session保存到缓存中,session服务器后端再配有底层持久性数据源,比如数据库,文件系统等等。
二 有效使用缓存
做互联网应用的兄弟应该都清楚,缓存对于一个互联网应用是多么的重要,从浏览器缓存,反向代理缓存,页面缓存,局部页面缓存,对象缓存等等都是缓存应用的场景。
一般来说缓存根据与应用程序的远近程度不同可以分为:local cache 和 remote cache。一般系统中要么采用local cache,要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦.
在大部分情况下,我们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对于一些读写比不高,同时对数据安全性需求不高的数据,我们可以将其缓存起来从而减少对底层数据库的访问,比如统计商品的访问次数,统计API的调用量等等,可以采用先写内存缓存然后延迟持久化到数据库,这样可以大大减少对数据库的写压力。
三 应用拆分
首先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。
系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统,不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整体系统的可用性也大大增强了。
因此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦.
上面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了,系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前公司正在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。
从上面可以看出,一个大型系统要想变得可维护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题。
四 数据库拆分
在前面“应用拆分”主题中,我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅仅说了”应用级别”的拆分,其实我们的互联网应用除了应用级别的拆分以外,还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统,通常就是所说的RDBMS进行拆分。
好了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的重要性。
系统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据库读取压力太大了,此时咱们都清楚是到了读写分离的时候,这个时候我们会配置一个server为master节点,然后配几个salve节点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还可以针对商品信息的库采用master,salve模式,OK,通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO,不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).
OK,上面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查询数据,如何平衡各个shards的负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。
五 异步通信
在”远程调用框架”的介绍中,我们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是拆分了以后,子系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节中,我们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既然说到了异步通信,那么”消息中间件”就要登场了,采用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.
说到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。
OK,那么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个子系统构成,假如A和B是同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同步调用B,如果A可用,那么B可用,逆否命题就是如果B不可用,那么A也不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。
最后,关于异步方面的讨论,我可以推荐大家一些资源:
1 . J2EE meets web2.0
2. Ebay架构特点(HPTS 2009)
六 非结构化数据存储
在一个大型的互联网应用当中,我们会发现并不是所有的数据都是结构化的,比如一些配置文件,一个用户对应的动态,以及一次交易的快照等信息,这些信息一般不适合保存到RDBMS中,它们更符合一种Key-value的结构,另外还有一类数据,数据量非常的大,但是实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储,另外一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,从而影响到其它的数据读取性能,因此这些信息也需要和其它信息分开存储,而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中。
随着互联网的发展,业界从08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性3者不能同时满足,最多只能同时满足两个,我们传统的关系数据采用了ACID的事务策略,而ACID的事务策略更加讲究的是一种高一致性而降低了可用性的需求,但是互联网应用往往对可用性的要求要略高于一致性的需求,这个时候我们就需要避免采用数据的ACID事务策略,转而采用BASE事务策略,BASE事务策略是基本可用性,事务软状态以及最终一致性的缩写,通过BASE事务策略,我们可以通过最终一致性来提升系统的可用性,这也是目前很多NOSQL产品所采用的策略,包括facebook 的cassandra,apache hbase,google bigtable等,这些产品非常适合一些非结构化的数据,比如key-value形式的数据存储,并且这些产品有个很好的优点就是水平伸缩性。目前公司也在研究和使用一些成熟的NOSQL产品。
七 监控、预警系统
对于大型的系统来说,唯一可靠的就是系统的各个部分是不可靠。
因为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的访问量是多,每个页面的PV是多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。
前面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题,提高系统的稳定性和可用性。
八 配置统一管理
一个大型的分布式应用,一般都是有很多节点构成的,如果每次一个新的节点加入都要更改其它节点的配置,或者每次删除一个节点也要更改配置的话,这样不仅不利于系统的维护和管理,同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的,如果不进行统一的配置管理,就需要再所有的系统上维护一份配置,这样会造成配置的管理维护很麻烦,而通过一个统一的配置管理可以使得这些问题得到很好的解决,当有新的节点加入或者删除的时候,配置管理系统可以通知各个节点更新配置,从而达到所有节点的配置一致性,这样既方便也不会出错。
原文地址:http://yuquan-nana.iteye.com/blog/710302
一 应用无状态
俗话说,一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢?咱们试想一下,假如我们在session中保存了大量与客户端的状态信息的话,那么当保存状态信息的server宕机的时候,我们怎么办?通常来说,我们都是通过集群来解决这个问题,而通常所说的集群,不仅有负载均衡,更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制,jboss采用的配对复制等session状态复制策略,但是集群中的状态恢复也有其缺点,那就是严重影响了系统的伸缩性,系统不能通过增加更多的机器来达到良好的水平伸缩,因为集群节点间session的通信会随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,我们需要保证应用的无状态性,这样集群中的各个节点来说都是相同的,从而是的系统更好的水平伸缩。
OK,上面说了无状态的重要性,那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。一般通过cookie来实现,或者也可以采用集中式session管理来完成,说具体点就是多个无状态的应用节点连接一个session 服务器,session服务器将session保存到缓存中,session服务器后端再配有底层持久性数据源,比如数据库,文件系统等等。
二 有效使用缓存
做互联网应用的兄弟应该都清楚,缓存对于一个互联网应用是多么的重要,从浏览器缓存,反向代理缓存,页面缓存,局部页面缓存,对象缓存等等都是缓存应用的场景。
一般来说缓存根据与应用程序的远近程度不同可以分为:local cache 和 remote cache。一般系统中要么采用local cache,要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦.
在大部分情况下,我们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对于一些读写比不高,同时对数据安全性需求不高的数据,我们可以将其缓存起来从而减少对底层数据库的访问,比如统计商品的访问次数,统计API的调用量等等,可以采用先写内存缓存然后延迟持久化到数据库,这样可以大大减少对数据库的写压力。
三 应用拆分
首先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。
系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统,不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整体系统的可用性也大大增强了。
因此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦.
上面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了,系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前公司正在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。
从上面可以看出,一个大型系统要想变得可维护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题。
四 数据库拆分
在前面“应用拆分”主题中,我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅仅说了”应用级别”的拆分,其实我们的互联网应用除了应用级别的拆分以外,还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统,通常就是所说的RDBMS进行拆分。
好了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的重要性。
系统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据库读取压力太大了,此时咱们都清楚是到了读写分离的时候,这个时候我们会配置一个server为master节点,然后配几个salve节点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还可以针对商品信息的库采用master,salve模式,OK,通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO,不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).
OK,上面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查询数据,如何平衡各个shards的负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。
五 异步通信
在”远程调用框架”的介绍中,我们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是拆分了以后,子系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节中,我们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既然说到了异步通信,那么”消息中间件”就要登场了,采用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.
说到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。
OK,那么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个子系统构成,假如A和B是同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同步调用B,如果A可用,那么B可用,逆否命题就是如果B不可用,那么A也不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。
最后,关于异步方面的讨论,我可以推荐大家一些资源:
1 . J2EE meets web2.0
2. Ebay架构特点(HPTS 2009)
六 非结构化数据存储
在一个大型的互联网应用当中,我们会发现并不是所有的数据都是结构化的,比如一些配置文件,一个用户对应的动态,以及一次交易的快照等信息,这些信息一般不适合保存到RDBMS中,它们更符合一种Key-value的结构,另外还有一类数据,数据量非常的大,但是实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储,另外一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,从而影响到其它的数据读取性能,因此这些信息也需要和其它信息分开存储,而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中。
随着互联网的发展,业界从08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性3者不能同时满足,最多只能同时满足两个,我们传统的关系数据采用了ACID的事务策略,而ACID的事务策略更加讲究的是一种高一致性而降低了可用性的需求,但是互联网应用往往对可用性的要求要略高于一致性的需求,这个时候我们就需要避免采用数据的ACID事务策略,转而采用BASE事务策略,BASE事务策略是基本可用性,事务软状态以及最终一致性的缩写,通过BASE事务策略,我们可以通过最终一致性来提升系统的可用性,这也是目前很多NOSQL产品所采用的策略,包括facebook 的cassandra,apache hbase,google bigtable等,这些产品非常适合一些非结构化的数据,比如key-value形式的数据存储,并且这些产品有个很好的优点就是水平伸缩性。目前公司也在研究和使用一些成熟的NOSQL产品。
七 监控、预警系统
对于大型的系统来说,唯一可靠的就是系统的各个部分是不可靠。
因为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的访问量是多,每个页面的PV是多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。
前面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题,提高系统的稳定性和可用性。
八 配置统一管理
一个大型的分布式应用,一般都是有很多节点构成的,如果每次一个新的节点加入都要更改其它节点的配置,或者每次删除一个节点也要更改配置的话,这样不仅不利于系统的维护和管理,同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的,如果不进行统一的配置管理,就需要再所有的系统上维护一份配置,这样会造成配置的管理维护很麻烦,而通过一个统一的配置管理可以使得这些问题得到很好的解决,当有新的节点加入或者删除的时候,配置管理系统可以通知各个节点更新配置,从而达到所有节点的配置一致性,这样既方便也不会出错。
原文地址:http://yuquan-nana.iteye.com/blog/710302
发表评论
-
技术选型(转)
2011-05-17 15:05 11992.1. 基础架构 ... -
分布式Java 应用(转)
2011-05-17 14:43 1419网络通信:协议TCP/IP,UDP/Ip,Multicas ... -
跨域访问session(转)
2011-04-22 16:14 2699大一些的网站,通常都 ... -
(转)分享一下,我常去的中文技术网站
2011-04-18 13:31 900先说一下大多数人都知 ... -
(转) request.getPathInfo() 方法的作用
2011-04-14 11:58 963request.getPathInfo(); 这个方法返回请 ... -
找到一篇性能测试的好文,简单实用,收藏之。
2011-04-10 21:59 899Java程序性能测试 1 概述 在 ... -
需要牢记的java编程规则(收藏)
2011-04-10 20:52 781(1) 类名首字母应该 ... -
一个计算机专业学生几年的编程经验汇总之二(收藏)
2011-04-10 19:48 939############################### ... -
一个计算机专业学生几年的编程经验汇总之一(收藏)
2011-04-10 18:05 948来学习Java也有两个年头了,永远不敢说多么精通,但也想谈谈自 ... -
(转)各种架构图汇总
2011-04-06 22:27 1473转载请保留出处,刘晓涛汇总!!! http://bl ... -
(转)java并发编程实践笔记
2011-04-05 22:23 8531, 保证线程安全的三种方法 : a, 不要跨线程访问共享变量 ... -
(转)百万级访问量网站的技术准备工作
2011-04-05 22:20 944当今从纯网站技术上来说,因为开源模式的发展,现在建一个小网站已 ... -
测试数据库连接状态
2011-03-25 08:45 1458while (true) { long star ... -
(转)什么是Java里的OO思想?
2011-03-24 14:12 945OO就是面向对象 面向对象(Object Oriented,O ... -
(转)JAVA 检测网络是否为连通状态 ping
2011-03-23 14:34 2586要用java检测网络资源是否可用,我们可以采用以下两种方法: ... -
中文乱码问题的解决方法
2011-01-21 17:33 1223tomcat下中文的彻底解决[转] http://blo ... -
nginx 映射80端口
2009-08-04 09:13 3953配置一个resin, 为不用输入端 ... -
调整 Java 虚拟机
2009-07-09 23:43 1123尽管 JVM 调整操作随 JVM 提供程序的不同而有所变化,但 ... -
测试网站性能的30款免费在线工具
2009-06-28 02:12 2086你是否肯定你的网站完全兼容各大浏览器?是否知道多少秒可以打开你 ... -
Memcached-----memcached实现内存缓存
2009-06-27 15:38 2747Memcached是danga.com(运营LiveJourn ...
相关推荐
拟阵约束下最大化子模函数的模型及其算法的一种熵聚类方法.pdf
内容概要:本文探讨了在两级电力市场环境中,针对省间交易商的最优购电模型的研究。文中提出了一个双层非线性优化模型,用于处理省内电力市场和省间电力交易的出清问题。该模型采用CVaR(条件风险价值)方法来评估和管理由新能源和负荷不确定性带来的风险。通过KKT条件和对偶理论,将复杂的双层非线性问题转化为更易求解的线性单层问题。此外,还通过实际案例验证了模型的有效性,展示了不同风险偏好设置对购电策略的影响。 适合人群:从事电力系统规划、运营以及风险管理的专业人士,尤其是对电力市场机制感兴趣的学者和技术专家。 使用场景及目标:适用于希望深入了解电力市场运作机制及其风险控制手段的研究人员和技术开发者。主要目标是为省间交易商提供一种科学有效的购电策略,以降低风险并提高经济效益。 其他说明:文章不仅介绍了理论模型的构建过程,还包括具体的数学公式推导和Python代码示例,便于读者理解和实践。同时强调了模型在实际应用中存在的挑战,如数据精度等问题,并指出了未来改进的方向。
内容概要:本文探讨了在MATLAB/Simulink平台上针对四机两区系统的风储联合调频技术。首先介绍了四机两区系统作为经典的电力系统模型,在风电渗透率增加的情况下,传统一次调频方式面临挑战。接着阐述了风储联合调频技术的应用,通过引入虚拟惯性控制和下垂控制策略,提高了系统的频率稳定性。文章展示了具体的MATLAB/Simulink仿真模型,包括系统参数设置、控制算法实现以及仿真加速方法。最终结果显示,在风电渗透率为25%的情况下,通过风储联合调频,系统频率特性得到显著提升,仿真时间缩短至5秒以内。 适合人群:从事电力系统研究、仿真建模的技术人员,特别是关注风电接入电网稳定性的研究人员。 使用场景及目标:适用于希望深入了解风储联合调频机制及其仿真实现的研究人员和技术开发者。目标是掌握如何利用MATLAB/Simulink进行高效的电力系统仿真,尤其是针对含有高比例风电接入的复杂场景。 其他说明:文中提供的具体参数配置和控制算法有助于读者快速搭建类似的仿真环境,并进行相关研究。同时强调了参考文献对于理论基础建立的重要性。
内容概要:本文介绍了永磁同步电机(PMSM)无感控制技术,特别是高频方波注入与滑膜观测器相结合的方法。首先解释了高频方波注入法的工作原理,即通过向电机注入高频方波电压信号,利用电机的凸极效应获取转子位置信息。接着讨论了滑膜观测器的作用,它能够根据电机的电压和电流估计转速和位置,具有较强的鲁棒性。两者结合可以提高无传感器控制系统的稳定性和精度。文中还提供了具体的Python、C语言和Matlab代码示例,展示了如何实现这两种技术。此外,简要提及了正弦波注入的相关论文资料,强调了其在不同工况下的优势。 适合人群:从事电机控制系统设计的研发工程师和技术爱好者,尤其是对永磁同步电机无感控制感兴趣的读者。 使用场景及目标:适用于需要减少传感器依赖、降低成本并提高系统可靠性的情况,如工业自动化设备、电动汽车等领域的电机控制。目标是掌握高频方波注入与滑膜观测器结合的具体实现方法,应用于实际工程项目中。 其他说明:文中提到的高频方波注入和滑膜观测器的结合方式,不仅提高了系统的性能,还在某些特殊情况下表现出更好的适应性。同时,附带提供的代码片段有助于读者更好地理解和实践这一技术。
内容概要:本文深入探讨了MATLAB中扩展卡尔曼滤波(EKF)和双扩展卡尔曼滤波(DEKF)在电池参数辨识中的应用。首先介绍了EKF的基本原理和代码实现,包括状态预测和更新步骤。接着讨论了DEKF的工作机制,即同时估计系统状态和参数,解决了参数和状态耦合估计的问题。文章还详细描述了电池参数辨识的具体应用场景,特别是针对电池管理系统中的荷电状态(SOC)估计。此外,提到了一些实用技巧,如雅可比矩阵的计算、参数初始值的选择、数据预处理方法等,并引用了几篇重要文献作为参考。 适合人群:从事电池管理系统开发的研究人员和技术人员,尤其是对状态估计和参数辨识感兴趣的读者。 使用场景及目标:适用于需要精确估计电池参数的实际项目,如电动汽车、储能系统等领域。目标是提高电池管理系统的性能,确保电池的安全性和可靠性。 其他说明:文章强调了实际应用中的注意事项,如数据处理、参数选择和模型优化等方面的经验分享。同时提醒读者关注最新的研究成果和技术进展,以便更好地应用于实际工作中。
内容概要:本文详细介绍了在无电子凸轮功能情况下,利用三菱FX3U系列PLC和威纶通触摸屏实现分切机上下收放卷张力控制的方法。主要内容涵盖硬件连接、程序框架设计、张力检测与读取、PID控制逻辑以及触摸屏交互界面的设计。文中通过具体代码示例展示了如何初始化寄存器、读取张力传感器数据、计算张力偏差并实施PID控制,最终实现稳定的张力控制。此外,还讨论了卷径计算、速度同步控制等关键技术点,并提供了现场调试经验和优化建议。 适合人群:从事自动化生产设备维护和技术支持的专业人士,尤其是熟悉PLC编程和触摸屏应用的技术人员。 使用场景及目标:适用于需要对分切机进行升级改造的企业,旨在提高分切机的张力控制精度,确保材料切割质量,降低生产成本。通过本方案可以实现±3%的张力控制精度,满足基本生产需求。 其他说明:本文不仅提供详细的程序代码和硬件配置指南,还分享了许多实用的调试技巧和经验,帮助技术人员更好地理解和应用相关技术。
内容概要:本文详细介绍了一种基于西门子S7-200和S7-300 PLC以及组态王软件的三泵变频恒压供水系统。主要内容涵盖IO分配、接线图原理图、梯形图程序编写和组态画面设计四个方面。通过合理的硬件配置和精确的编程逻辑,确保系统能够在不同负载情况下保持稳定的供水压力,同时实现节能和延长设备使用寿命的目标。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是熟悉PLC编程和组态软件使用的专业人士。 使用场景及目标:适用于需要稳定供水的各种场合,如住宅小区、工厂等。目标是通过优化控制系统,提升供水效率,减少能源消耗,并确保系统的可靠性和安全性。 其他说明:文中提供了详细的实例代码和调试技巧,帮助读者更好地理解和实施该项目。此外,还分享了一些实用的经验教训,有助于避免常见的错误和陷阱。
内容概要:本文详细介绍了三相三线制静止无功发生器(SVG/STATCOM)在Simulink中的仿真模型设计与实现。主要内容涵盖ip-iq检测法用于无功功率检测、dq坐标系下的电流解耦控制、电压电流双闭环控制系统的设计、SVPWM调制技术的应用以及具体的仿真参数设置。文中不仅提供了理论背景,还展示了具体的Matlab代码片段,帮助读者理解各个控制环节的工作原理和技术细节。此外,文章还讨论了实际调试中遇到的问题及解决方案,强调了参数调整的重要性。 适合人群:从事电力系统自动化、电力电子技术研究的专业人士,特别是对SVG/STATCOM仿真感兴趣的工程师和研究人员。 使用场景及目标:适用于希望深入了解SVG/STATCOM工作原理并掌握其仿真方法的研究人员和工程师。目标是在实践中能够正确搭建和优化SVG/STATCOM的仿真模型,提高无功补偿的效果。 其他说明:文章提供了丰富的实例代码和调试技巧,有助于读者更好地理解和应用所学知识。同时,文中提及的一些经验和注意事项来源于实际项目,具有较高的参考价值。
基于SIMULINK的风力机发电效率建模探究.pdf
内容概要:本文介绍了如何将CarSim的动力学模型与Simulink的智能算法相结合,利用模型预测控制(MPC)实现车辆的智能超车换道。主要内容包括MPC控制器的设计、路径规划算法、联合仿真的配置要点以及实际应用效果。文中提供了详细的代码片段和技术细节,如权重矩阵设置、路径跟踪目标函数、安全超车条件判断等。此外,还强调了仿真过程中需要注意的关键参数配置,如仿真步长、插值设置等,以确保系统的稳定性和准确性。 适合人群:从事自动驾驶研究的技术人员、汽车工程领域的研究人员、对联合仿真感兴趣的开发者。 使用场景及目标:适用于需要进行自动驾驶车辆行为模拟的研究机构和企业,旨在提高超车换道的安全性和效率,为自动驾驶技术研发提供理论支持和技术验证。 其他说明:随包提供的案例文件已调好所有参数,可以直接导入并运行,帮助用户快速上手。文中提到的具体参数和配置方法对于初学者非常友好,能够显著降低入门门槛。
内容概要:本文详细介绍了利用MATLAB进行信号与系统实验的具体步骤和技术要点。首先讲解了常见信号(如方波、sinc函数、正弦波等)的生成方法及其注意事项,强调了时间轴设置和参数调整的重要性。接着探讨了卷积积分的两种实现方式——符号运算和数值积分,指出了各自的特点和应用场景,并特别提醒了数值卷积时的时间轴重构和步长修正问题。随后深入浅出地解释了频域分析的方法,包括傅里叶变换的符号计算和快速傅里叶变换(FFT),并给出了具体的代码实例和常见错误提示。最后阐述了离散时间信号与系统的Z变换分析,展示了如何通过Z变换将差分方程转化为传递函数以及如何绘制零极点图来评估系统的稳定性。 适合人群:正在学习信号与系统课程的学生,尤其是需要完成相关实验任务的人群;对MATLAB有一定基础,希望通过实践加深对该领域理解的学习者。 使用场景及目标:帮助学生掌握MATLAB环境下信号生成、卷积积分、频域分析和Z变换的基本技能;提高学生解决实际问题的能力,避免常见的编程陷阱;培养学生的动手能力和科学思维习惯。 其他说明:文中不仅提供了详细的代码示例,还分享了许多实用的小技巧,如如何正确保存实验结果图、如何撰写高质量的实验报告等。同时,作者以幽默风趣的语言风格贯穿全文,使得原本枯燥的技术内容变得生动有趣。
KUKA机器人相关文档
内容概要:本文详细介绍了无传感器永磁同步电机(PMSM)控制技术,特别是针对低速和中高速的不同控制策略。低速阶段采用I/F控制,通过固定电流幅值和斜坡加速的方式启动电机,确保平稳启动。中高速阶段则引入滑模观测器进行反电动势估算,从而精确控制电机转速。文中还讨论了两者之间的平滑切换逻辑,强调了参数选择和调试技巧的重要性。此外,提供了具体的伪代码示例,帮助读者更好地理解和实现这一控制方案。 适合人群:从事电机控制系统设计的研发工程师和技术爱好者。 使用场景及目标:适用于需要降低成本并提高可靠性的应用场景,如家用电器、工业自动化设备等。主要目标是掌握无传感器PMSM控制的基本原理及其优化方法。 其他说明:文中提到的实际案例和测试数据有助于加深理解,同时提醒开发者注意硬件参数准确性以及调试过程中可能出现的问题。
智能家居与物联网培训材料.ppt
内容概要:本文详细介绍了使用Matlab解决车辆路径规划问题的四种经典算法:TSP(旅行商问题)、CVRP(带容量约束的车辆路径问题)、CDVRP(带容量和距离双重约束的车辆路径问题)和VRPTW(带时间窗约束的车辆路径问题)。针对每个问题,文中提供了具体的算法实现思路和关键代码片段,如遗传算法用于TSP的基础求解,贪心算法和遗传算法结合用于CVRP的路径分割,以及带有惩罚函数的时间窗约束处理方法。此外,还讨论了性能优化技巧,如矩阵运算替代循环、锦标赛选择、2-opt局部优化等。 适合人群:具有一定编程基础,尤其是对物流调度、路径规划感兴趣的开发者和技术爱好者。 使用场景及目标:适用于物流配送系统的路径优化,旨在提高配送效率,降低成本。具体应用场景包括但不限于外卖配送、快递运输等。目标是帮助读者掌握如何利用Matlab实现高效的路径规划算法,解决实际业务中的复杂约束条件。 其他说明:文中不仅提供了详细的代码实现,还分享了许多实践经验,如参数设置、数据预处理、异常检测等。建议读者在实践中不断尝试不同的算法组合和优化策略,以应对更加复杂的实际问题。
软考网络工程师2010-2014真题及答案完整版 全国计算机软考 适合软考中级人群
包括:源程序工程文件、Proteus仿真工程文件、论文材料、配套技术手册等 1、采用51/52单片机作为主控芯片; 2、采用1602液晶显示:测量酒精值、酒驾阈值、醉驾阈值; 3、采用PCF8591进行AD模数转换; 4、LED指示:正常绿灯、酒驾黄灯、醉驾红灯; 5、可通过按键修改酒驾醉驾阈值;
内容概要:本文详细介绍了利用MATLAB实现约束最优化求解的方法,主要分为两大部分:无约束优化和带约束优化。对于无约束优化,作者首先讲解了梯度下降法的基本原理和实现技巧,如步长搜索和Armijo条件的应用。接着深入探讨了带约束优化问题,特别是序列二次规划(SQP)方法的具体实现,包括拉格朗日函数的Hesse矩阵计算、QP子问题的构建以及拉格朗日乘子的更新策略。文中不仅提供了详细的MATLAB代码示例,还分享了许多调参经验和常见错误的解决办法。 适合人群:具备一定数学基础和编程经验的研究人员、工程师或学生,尤其是对最优化理论和应用感兴趣的读者。 使用场景及目标:适用于需要解决各类优化问题的实际工程项目,如机械臂能耗最小化、化工过程优化等。通过学习本文,读者能够掌握如何将复杂的约束优化问题分解为更易处理的二次规划子问题,从而提高求解效率和准确性。 其他说明:文章强调了优化算法选择的重要性,指出不同的问题结构决定了最适合的算法。此外,作者还分享了一些实用的经验教训,如Hesse矩阵的正定性处理和惩罚因子的动态调整,帮助读者少走弯路。
KUKA机器人相关资料
内容概要:本文详细介绍了某制造企业在疫苗车间控制系统中使用西门子200Smart PLC和维纶触摸屏的具体实现方法和技术要点。主要内容涵盖配液罐的模拟量处理、发酵罐的PID控制、USS通讯控制变频器、CIP清洗程序以及触摸屏权限管理等方面。文中不仅展示了具体的代码片段,还分享了许多调试经验和优化技巧,如模拟量处理中避免库指令占用额外存储空间、PID控制中的参数整定、USS通讯中的控制字配置等。 适用人群:从事工业自动化控制领域的工程师和技术人员,尤其是对中小型PLC和触摸屏编程感兴趣的从业者。 使用场景及目标:适用于疫苗车间及其他类似生物制药生产线的自动化控制系统设计和实施。目标是帮助读者掌握中小型PLC在复杂生产工艺中的应用技巧,提高系统的可靠性和效率。 其他说明:文章强调了模块化设计的重要性,提供了许多实用的操作建议和调试经验,有助于读者更好地理解和应用相关技术。此外,还提到了一些常见的错误及其解决方案,使读者能够避免类似的陷阱。