2013年3月25日星期一

IIS6.0 ,网站上的html可以正常访问,aspx提示找不到页面 错误 ?????



答案:
后台没有开启允许aspx运行!你可以在IIS里面找到web扩展,然后里面有ASPx
允许就行了

可扩展Web架构与分布式系统


英文原文:Scalable Web Architecture and Distributed Systems
开放源代码已经成为一些大型网站的基本原则。而在这些网站成长的过程中,一些优秀的实践经验和规则也出现在他们的结构中。本文旨在介绍一些在大型网站结构设计的过程中需要注意的关键问题以及实现目标的基础工作。
本文侧重于介绍网络系统,尽管一些准则在其他分布式系统中也是适用的。
1.1. web分布式系统的设计原则

搭建和运营一个可伸缩的web站点或者应用程序意味着什么?在原始层面上这仅仅是用户通过互联网连接到远程资源-使系统变得可伸缩的部分是将资源、或者访问的资源,分布于多个服务器上。
像生活中大多数事情一样,当构建一个web服务时花时间提前做好计划从长远看来还是很有帮助的;了解一些注意事项和大网站背后的权衡原则可以在创建小型网站时做出更明智的决定。以下是一些影响大规模web系统设计的关键原则:
可用性:对于很多公司来说一个网站的正常运行时间是非常关键的声誉和功能,像一些大型的在线零售系统,即使一分钟的宕机都有可能导致数千或者数百万美元的损失,因此设计系统的时时可用性和弹性的错误处理机制既是一个基本业务也是一个技术要求。 高可用分布式系统需要仔细考虑关键组件的冗余,分系统失败后能快速修复,并且当问题出现时优雅型降级。
性能:网站的性能正在变成大多数站点考虑的一个重要的方面,网站的速度影响正常使用和用户的满意度,同样影响搜索的排名,这也是影响网站收益和保留用户的一个因素。因此,创建一个快速响应和低延迟的系统是非常关键的。
可靠性:一个系统需要具备可靠性,比如同一个数据的请求始终返回同样的数据响应 。如果数据改变或者被更新,那么同样的数据将返回一个新的数据。用户需要知道一些东西被写入系统或者被存储到系统后,系统会保持不变并且可以在以后恢复到合适的位置。
可伸缩性:当谈到任何大型的分布式系统时,规模大小只是考虑的其中一个方面,同样重要的是增强处理较大规模的负载性能所做的努力,这通常称为系统的可伸缩性。可伸缩性可以代表系统很多不同的参数:额外流量的处理量,添加存储容量的便意性,甚至事务的处理量。
可管理性: 设计一个系统可以方便操作是另一个重要的考虑方面,系统的可管理性等同于操作的可伸缩性:维护和升级。可管理性需要考虑的事情是当问题发生时方便诊断和了解问题,易于升级和修改,以及系统能简单性的操作(即,例行的操作有没有失败和异常?)
成本: 成本是一个重要的因素。很明显这包含硬件和软件成本,但同样重要需要考虑的其他方面是部署和维护系统的成本。开发者构建系统花费的大量时间,运维部署时间,甚至培训时间都需要考虑,成本是总体成本。
以上每个原则都为设计分布式web架构提供了基础决策。然而,他们也能彼此互斥,例如要实现某个目标就要以另外的作为代价。一个基本的例子:选择通过单纯增加更多的服务器(可扩展性)来增加地址容量,是以可管理性(你必须操作增加的服务器)和成本(服务器的价格)为代价的。
当设计任何的web应用程序时,考虑这些关键原则都是很重要的,即使得承认一个设计可能要牺牲它们之中的一个或者多个。
1.2. 基础

当设计一个系统架构时,有一些东西是要考虑的:正确的部分是什么,怎样让这些部分很好地融合在一起,以及好的折中方法是什么。通常在系统架构需要之前就为它的可扩展性投资不是一个聪明的商业抉择;然而,在设计上的深谋远虑能在未来节省大量的时间和资源。
这部分关注点是几乎所有大型web应用程序中心的一些核心因素:服务、冗余、划分和错误处理。每一个因素都包含了选择和妥协,特别是上部分提到的设计原则。为了详细的解析这些,最好是用一个例子来开始。
实例:图片托管应用

有时候你可能会在线上传一张图片。对于那些托管并负责分发大量图片的网站来说,要搭建一个既节省成本又高效还能具备较低的延迟性(你能快速的获图片)的网站架构确实是一种挑战。
我们来假设一个系统,用户可以上传他们的图片到中心服务器,这些图片又能够让一些web链接或者API获取这些图片,就如同现在的Flickr或者Picasa。为了简化的需要,我们假设应用程序分为两个主要的部分:一个是上传图片到服务器的能力(通常说的写操作),另一个是查询一个图片的能力。然而,我们当然想上传功能很高效,但是我们更关心的是能够快速分发能力,也就是说当某个人请求一个图片的时候(比如,一个web页面或者其它应用程序请求图片)能够快速的满足。这种分发能力很像web服务器或者CDN连接服务器(CDN服务器一般用来在多个位置存储内容一边这些内容能够从地理位置或者物理上更靠近访问它的用户,已达到高效访问的目的)气的作用。
系统其他重要方面:
对图片存储的数量没有限制,所以存储需要可扩展,在图像数量方面需要考虑。
图片的下载和请求不需要低延迟。
如果用户上传一个图片,图片应该都在那里(图片数据的可靠性)。
系统应该容易管理(可管理性)。
由于图片主机不会有高利润的空间,所以系统需要具有成本效益。
Figure 1.1是一个简化的功能图。
 Figure 1.1: 图片主机应用的简化架构图
在这个图片主机的例子里,可遇见系统必需快速,它的数据存储要可靠以及这些所有的属性都应该高度的可扩展。建立这个应用程序的一个小版本不是很重要而且很容易部署在单一的服务器上;然而,这不是这节里的感兴趣部分。假设下我们想建一个会增长到和Flickr痛让规模的东西。
服务

当要考虑设计一个可扩展的系统时,为功能解耦和考虑下系统每部分的服务都定义一个清晰的接口都是很有帮助的。在实际中,在这种方式下的系统设计被成为面向服务架构(SOA)。对于这类型的系统,每个服务有自己独立的方法上下文,以及使用抽象接口与上下文的外部任何东西进行交互,典型的是别的服务的公共API。
把一个系统解构为一些列互补的服务,能够为这些部分从别的部分的操作解耦。这样的抽象帮助在这些服务服、它的基础环境和服务的消费者之间建立清晰的关系。建立这种清晰的轮廓能帮助隔离问题,但也允许各模块相对其它部分独立扩展。这类面向服务设计系统是非常类似面向对象设计编程的。
在我们的例子中,上传和检索图像的请求都是由同一个服务器处理的;然而,因为系统需要具有伸缩性,有理由要将这两个功能分解为各由自己的服务进行处理。
快速转发(Fast-forward)假定服务处于大量使用中;在这种情况下就很容易看到,读取图像所花的时间中有多少是由于受到了写入操作的影响(因为这两个功能将竞争使用它们共享的资源)。取决于所采用的体系结构,这种影响可能是巨大的。即使上传和下载的速度完全相同(在绝大多数IP网络中都不是这样的情况,大部分下载速度和上传速度之比都至少设计为3:1),文件读取操作一般都是从高速缓存中进行的,而写操作却不得不进行最终的磁盘操作(而且可能要写几次才能达成最后的一致状态)。即使所有内容都已在内存中,或者从磁盘(比如SSD磁盘)中进行读取,数据库写入操作几乎往往都要慢于读取操作。(Pole Position是一个开源的DB基准测试工具,http://polepos.org/,测试结果参见 http://polepos.sourceforge.net/results/PolePositionClientServer.pdf)
这种设计另一个潜在的问题出在web服务器上,像Apache或者lighttpd通常都有一个能够维持的并发连接数上限(默认情况下在500左右,不过可以更高)和最高流量数,它们会很快被写操作消耗掉。因为读操作可以异步进行,或者采用其它一些像gizp压缩的性能优化或者块传输编码方式,web服务器可以通过在多个请求服务之间切换来满足比最大连接数更多的请求(一台Apache的最大连接数设置为500,它每秒钟提供近千次读请求服务也是正常的)。写操作则不同,它需要在上传过程中保持连接,所以大多数家庭网络环境下,上传一个1MB的文件可能需要超过1秒的时间,所以web服务器只能处理500个这样并发写操作请求。

对于这种瓶颈,一个好的规划案例是将读取和写入图片分离为两个独立的服务,如图Figure 1.2.所示。这让我们可以单独的扩展其中任意一个(因为有可能我们读操作比写操作要频繁很多),同时也有助于我们理清每个节点在做什么。最后,这也避免了未来的忧虑,这使得故障诊断和查找问题更简单,像慢读问题。
这种方法的优点是我们能够单独的解决各个模块的问题-我们不用担心写入和检索新图片在同一个上下文环境中。这两种服务仍然使用全球资料库的图片,但是它们可通过适当的服务接口自由优化它们自己的性能(比如,请求队列,或者缓存热点图片-在这之上的优化)。从维护和成本角度来看,每个服务按需进行独立规模的规划,这点非常有用,试想如果它们都组合混杂在一起,其中一个无意间影响到了性能,另外的也会受影响。
当然,上面的例子在你使用两个不同端点时可以很好的工作(事实上,这非常类似于云存储和内容分发网络)。虽然有很多方式来解决这样的瓶颈,但每个都有各自的取舍。
比如,Flickr通过分配用户访问不同的分片解决这类读/写问题,每一个分片只可以处理一定数量的用户,随着用户的增加更多的分片被添加到集群上(参看“Flickr缩影”的描述http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html)。在第一个例子中,可以根据实际用途更简单的规划硬件资源(在整个系统中读和写的比例),然而,Flickr规划是根据用户基数(假定每个用户拥有相同的资源空间)。在前者中一个故障或者问题会导致整个系统功能的下降(比如,全部不能写入文件了),然而Flickr一个分片的故障只会影响到相关的那部分用户。在第一个例子中,更容易操作整个数据集-比如,在所有的图像元数据上更新写入服务用来包含新的元数据或者检索-然而在Flickr架构上每一个分片都需要执行更新或者检索(或者需要创建个索引服务来核对元数据-找出哪一个才是实际结果)。
冗余(Redundancy)

为了优雅的处理故障,web架构必须冗余它的服务和数据。例如,单服务器只拥有单文件的话,文件丢失就意味这永远丢失了。丢失数据是个很糟糕的事情,常见的方法是创建多个或者冗余备份。
同样的原则也适用于服务。如果应用有一个核心功能,确保它同时运行多个备份或者版本可以安全的应对单点故障。
在系统中创建冗余可以消除单点故障,可以在紧急时刻提供备用功能。例如,如果在一个产品中同时运行服务的两个实例,当其中一个发生故障或者降级(degrade),系统可以转移(failover)到好的那个备份上。故障转移(Failover)可以自动执行或者人工手动干预。
服务冗余的另一个关键部分是创建无共享(shared-nothing)架构。采用这种架构,每个接点都可以独立的运作,没有中心"大脑"管理状态或者协调活动。这可以大大提高可伸缩性(scalability)因为新的接点可以随时加入而不需要特殊的条件或者知识。而且更重要的是,系统没有单点故障。所以可以更好的应对故障。
例如,在我们的图片服务应用,所有的图片应该都冗余备份在另外的一个硬件上(理想的情况下,在不同的地理位置,以防数据中心发生大灾难,例如地震,火灾),而且访问图片的服务(见Figure 1.3.)-包括所有潜在的服务请求-也应该冗余。(负载均衡器是个很好的方法冗余服务,但是下面的方法不仅仅是负载均衡)
 Figure 1.3: 使用冗余的图片存储
分区

我们可能遇见单一服务器无法存放的庞大数据集。也可能遇到一个需要过多计算资源的操作,导致性能下降,急需增添容量。这些情况下,你都有两种选择:横向或纵向扩展。
纵向扩展意味着对单一服务器增添更多资源。对于一个非常庞大的数据集,这可能意味着为单一服务器增加更多(或更大)的硬盘以存放整个数据集。而对于计算操作,这可能意味着将操作移到一个拥有更快的 CPU 或 更大的内存的服务器中。无论哪种情况,纵向扩展都是为了使单个服务器能够自己处理更多的方法。
另一方面,对于横向扩展,则是增加更多的节点。例如庞大的数据集,你可以用第二个服务器来存放部分数据;而对于计算操作,你可以切割计算,或是通过额外的节点加载。想要充分的利用横向扩展的优势,你应该以内在的系统构架设计原则来实现,否则的话,实现的方法将会变成繁琐的修改和切分操作。
说道横向分区,更常见的技术是将你的服务分区,或分片。分区可以通过对每个功能逻辑集的分割分配而来;可以通过地域划分,也可以通过类似付费 vs. 未付费用户来区分。这种方式的优势是可以通过增添容量来运行服务或实现数据存储。
以我们的图像服务器为例,将曾经储存在单一的文件服务器的图片重新保存到多个文件服务器中是可以实现的,每个文件服务器都有自己惟一的图片集。(见图表1.4。)这种构架允许系统将图片保存到某个文件服务器中,在服务器都即将存满时,像增加硬盘一样增加额外的服务器。这种设计需要一种能够将文件名和存放服务器绑定的命名规则。一个图像的名称可能是映射全部服务器的完整散列方案的形式。或者可选的,每个图像都被分配给一个递增的 ID,当用户请求图像时,图像检索服务只需要保存映射到每个服务器的 ID 范围(类似索引)就可以了。

图表 1.4: 使用冗余和分区实现的图片存储服务
当然,为多个服务器分配数据或功能是充满挑战的。一个关键的问题就是数据局部性;对于分布式系统,计算或操作的数据越相近,系统的性能越佳。因此,一个潜在的问题就是数据的存放遍布多个服务器,当需要一个数据时,它们并不在一起,迫使服务器不得不为从网络中获取数据而付出提交翻译昂贵的性能代价。
另一个潜在的问题是不一致性。当多个不同的服务读取和写入同一共享资源时,有可能会遭遇竞争状态——某些数据应当被更新,但读取操作恰好发生在更新之前——这种情形下,数据就是不一致的。例如图像托管方案中可能出现的竞争状态,一个客户端发送请求,将其某标题为“狗"的图像改名为”小家伙“。而同时另一个客户端发送读取此图像的请求。第二个客户端中显示的标题是“狗”还是“小家伙”是不能明确的。
当然,对于分区还有一些障碍存在,但分区允许将问题——数据、负载、使用模式等——切割成可以管理的数据块。这将极大的提高可扩展性和可管理性,但并非没有风险。有很多可以降低风险,处理故障的方法;不过篇幅有限,不再赘述。若有兴趣,可见于此文,获取更多容错和检测的信息。
1.3. 构建高效和可伸缩的数据访问模块

在设计分布式系统时一些核心问题已经考虑到,现在让我们来讨论下比较困难的一部分:可伸缩的数据访问。
对于大多数简单的web应用程序,比如LAMP系统,类似于图 Figure 1.5.
 Figure 1.5: 简单web应用程序
随着它们的成长,主要发生了两方面的变化:应用服务器和数据库的扩展。在一个高度可伸缩的应用程序中,应用服务器通常最小化并且一般是shared-nothing架构(译注:shared nothing architecture是一 种分布式计算架构,这种架构中不存在集中存储的状态,整个系统中没有资源竞争,这种架构具有非常强的扩张性,在web应用中广泛使用)方式的体现,这使得系统的应用服务器层水平可伸缩。由于这种设计,数据库服务器可以支持更多的负载和服务;在这一层真正的扩展和性能改变开始发挥作用了。
剩下的章节主要集中于通过一些更常用的策略和方法提供快速的数据访问来使这些类型服务变得更加迅捷。

Figure 1.6: Oversimplified web application
大多数系统简化为如图 Figure 1.6所示,这是一个良好的开始。如果你有大量的数据,你想快捷的访问,就像一堆糖果摆放在你办公室抽屉的最上方。虽然过于简化,前面的声明暗示了两个困难的问题:存储的可伸缩性和数据的快速访问。
为了这一节内容,我们假设你有很大的数据存储空间(TB),并且你想让用户随机访问一小部分数据(查看Figure 1.7)。这类似于在图像应用的例子里在文件服务器定位一个图片文件。
 Figure 1.7: Accessing specific data
这非常具有挑战性,因为它需要把数TB的数据加载到内存中;并且直接转化为磁盘的IO。要知道从磁盘读取比从内存读取慢很多倍-内存的访问速度如同敏捷的查克·诺里斯(译注:空手道冠军),而磁盘的访问速度就像笨重的卡车一样。这个速度差异在大数据集上会增加更多;在实数顺序读取上内存访问速度至少是磁盘的6倍,随机读取速度比磁盘快100,000倍(参考“大数据之殇”http://queue.acm.org/detail.cfm?id=1563874)。另外,即使使用唯一的ID,解决获取少量数据存放位置的问题也是个艰巨的任务。这就如同不用眼睛看在你的糖果存放点取出最后一块Jolly Rancher口味的糖果一样。
谢天谢地,有很多方式你可以让这样的操作更简单些;其中四个比较重要的是缓存,代理,索引和负载均衡。本章的剩余部分将讨论下如何使用每一个概念来使数据访问加快。
缓存

缓存利用局部访问原则:最近请求的数据可能会再次被请求。它们几乎被用于计算机的每一层:硬件,操作系统,web浏览器,web应用程序等等。缓存就像短期存储的内存:它有空间的限制,但是通常访问速度比源数据源快并且包含了大多数最近访问的条目。缓存可以在架构的各个层级存在,但是常常在前端比较常见,在这里通常需要在没有下游层级的负担下快速返回数据。
在我们的API例子中如何使用缓存来快速访问数据?在这种情况下,有两个地方你可以插入缓存。一个操作是在你的请求层节点添加一个缓存,如图 Figure 1.8.
 Figure 1.8: Inserting a cache on your request layer node

直接在一个请求层节点配置一个缓存可以在本地存储相应数据。每次发送一个请求到服务,如果数据存在节点会快速的返回本地缓存的数据。如果数据不在缓存中,请求节点将在磁盘查找数据。请求层节点缓存可以存放在内存和节点本地磁盘中(比网络存储快些)。

Figure 1.9: Multiple caches
当你扩展这些节点后会发生什么呢?如图Figure 1.9所示,如果请求层扩展为多个节点,每个主机仍然可能有自己的缓存。然而,如果你的负载均衡器随机分配请求到节点,同样的请求将指向不同的节点,从而增加了缓存的命中缺失率。有两种选择可以解决这个问题:全局缓存和分布式缓存。
全局缓存

全局缓存顾名思义:所有的节点使用同一个缓存空间,这涉及到添加一个服务器,或者某种文件存储系统,速度比访问源存储和通过所有节点访问要快些。每个请求节点以同样的方式查询本地的一个缓存,这种缓存方案可能有点复杂,因为在客户端和请求数量增加时它很容易被压倒,但是在有些架构里它还是很有用的(尤其是那些专门的硬件来使全局缓存变得非常快,或者是固定数据集需要被缓存的)。
在描述图中有两种常见形式的缓存。在图Figure 1.10中,当一个缓存响应没有在缓存中找到时,缓存自身从底层存储中查找出数据。在 Figure 1.11中,当在缓存中招不到数据时,请求节点会向底层去检索数据。
 Figure 1.10: Global cache where cache is responsible for retrieval Figure 1.11: Global cache where request nodes are responsible for retrieval
大多数使用全局缓存的应用程序趋向于第一类,这类缓存可以管理数据的读取,防止客户端大量的请求同样的数据。然而,一些情况下,第二类实现方式似乎更有意义。比如,如果一个缓存被用于非常大的文件,一个低命中比的缓存将会导致缓冲区来填满未命中的缓存;在这种情况下,将使缓存中有一个大比例的总数据集。另一个例子是架构设计中文件在缓存中存储是静态的并且不会被排除。(这可能是因为应用程序要求周围数据的延迟-某些片段的数据可能需要在大数据集中非常快-在有些地方应用程序逻辑理清排除策略或者热点 比缓存方案好使些)
分布式缓存

在分布式缓存(图1.12)中,每个节点都会缓存一部分数据。如果把冰箱看作食杂店的缓存的话,那么分布式缓存就象是把你的食物分别放到多个地方 —— 你的冰箱、柜橱以及便当盒 ——放到这些便于随时取用的地方就无需一趟趟跑去食杂店了。缓存一般使用一个具有一致性的哈希函数进行分割,如此便可在某请求节点寻找某数据时,能够迅速知道要到分布式缓存中的哪个地方去找它,以确定改数据是否从缓存中可得。在这种情况下,每个节点都有一个小型缓存,在直接到原数据所作处找数据之前就可以向别的节点发出寻找数据的请求。由此可得,分布式缓存的一个优势就是,仅仅通过向请求池中添加新的节点便可以拥有更多的缓存空间。
分布式缓存的一个缺点是修复缺失的节点。一些分布式缓存系统通过在不同节点做多个备份绕过了这个问题;然而,你可以想象这个逻辑迅速变复杂了,尤其是当你在请求层添加或者删除节点时。即便是一个节点消失和部分缓存数据丢失了,我们还可以在源数据存储地址获取-因此这不一定是灾难性的!
 Figure 1.12: Distributed cache
缓存的伟大之处在于它们使我们的访问速度更快了(当然前提是正确使用),你选择的方法要在更多请求下更快才行。然而,所有这些缓存的代价是必须有额外的存储空间,通常在放在昂贵的内存中;从来没有嗟来之食。缓存让事情处理起来更快,而且在高负载情况下提供系统功能,否则将会使服务器出现降级。
有一个很流行的开源缓存项目Memcached (http://memcached.org/)(它可以当做一个本地缓存,也可以用作分布式缓存);当然,还有一些其他操作的支持(包括语言包和框架的一些特有设置)。
Memcached 被用作很多大型的web站点,尽管他很强大,但也只是简单的内存key-value存储方式,它优化了任意数据存储和快速检索(o(1))。
Facebook使用了多种不同的缓存来提高他们站点的性能(查看"Facebook caching and performance")。在语言层面上(使用PHP内置函数调用)他们使用$GLOBALSand APC缓存,这有助于使中间函数调用和结果返回更快(大多数语言都有这样的类库用来提高web页面的性能)。Facebook使用的全局缓存分布在多个服务器上(查看 "Scaling memcached at Facebook"),这样一个访问缓存的函数调用可以使用很多并行的请求在不同的Memcached 服务器上获取存储的数据。这使得他们在为用户分配数据空间时有了更高的性能和吞吐量,同时有一个中央服务器做更新(这非常重要,因为当你运行上千服务器时,缓存失效和一致性将是一个大挑战)。
现在让我们讨论下当数据不在缓存中时该如何处理···
代理

简单来说,代理服务器是一种处于客户端和服务器中间的硬件或软件,它从客户端接收请求,并将它们转交给服务器。代理一般用于过滤请求、记录日志或对请求进行转换(增加/删除头部、加密/解密、压缩,等等)。

图1.13: 代理服务器
当需要协调来自多个服务器的请求时,代理服务器也十分有用,它允许我们从整个系统的角度出发、对请求流量执行优化。压缩转发(collapsed forwarding)是利用代理加快访问的其中一种方法,将多个相同或相似的请求压缩在同一个请求中,然后将单个结果发送给各个客户端。
假设,有几个节点都希望请求同一份数据,而且它并不在缓存中。在这些请求经过代理时,代理可以通过压缩转发技术将它们合并成为一个请求,这样一来,数据只需要从磁盘上读取一次即可(见图1.14)。这种技术也有一些缺点,由于每个请求都会有一些时延,有些请求会由于等待与其它请求合并而有所延迟。不管怎么样,这种技术在高负载环境中是可以帮助提升性能的,特别是在同一份数据被反复访问的情况下。压缩转发有点类似缓存技术,只不过它并不对数据进行存储,而是充当客户端的代理人,对它们的请求进行某种程度的优化。
在一个LAN代理服务器中,客户端不需要通过自己的IP连接到Internet,而代理会将请求相同内容的请求合并起来。这里比较容易搞混,因为许多代理同时也充当缓存(这里也确实是一个很适合放缓存的地方),但缓存却不一定能当代理。
 Fi
图1.14: 通过代理来合并请求
另一个使用代理的方式不只是合并相同数据的请求,同时也可以用来合并靠近存储源(一般是磁盘)的数据请求。采用这种策略可以让请求最大化使用本地数据,这样可以减少请求的数据延迟。比如,一群节点请求B部分信息:partB1,partB2等,我们可以设置代理来识别各个请求的空间区域,然后把它们合并为一个请求并返回一个bigB,大大减少了读取的数据来源(查看图Figure 1.15)。当你随机访问上TB数据时这个请求时间上的差异就非常明显了!代理在高负载情况下,或者限制使用缓存时特别有用,因为它基本上可以批量的把多个请求合并为一个。
 Figure 1.15: Using a proxy to collapse requests for data that is spatially close together
值得注意的是,代理和缓存可以放到一起使用,但通常最好把缓存放到代理的前面,放到前面的原因和在参加者众多的马拉松比赛中最好让跑得较快的选手在队首起跑一样。因为缓存从内存中提取数据,速度飞快,它并不介意存在对同一结果的多个请求。但是如果缓存位于代理服务器的另一边,那么在每个请求到达cache之前都会增加一段额外的时延,这就会影响性能。
如果你正想在系统中添加代理,那你可以考虑的选项有很多;Squid和Varnish都经过了实践检验,广泛用于很多实际的web站点中。这些代理解决方案针对大部分client-server通信提供了大量的优化措施。将二者之中的某一个安装为web服务器层的反向代理(reverse proxy,下面负载均衡器一节中解释)可以大大提高web服务器的性能,减少处理来自客户端的请求所需的工作量。
索引

使用索引快速访问数据是个优化数据访问性能公认的策略;可能我们大多数人都是从数据库了解到的索引。索引用增长的存储空间占用和更慢的写(因为你必须写和更新索引)来换取更快的读取。
你可以把这个概念应用到大数据集中就像应用在传统的关系数据存储。索引要关注的技巧是你必须仔细考虑用户会怎样访问你的数据。如果数据集有很多TBs,但是每个数据包(payload)很小(可能只有1KB),这时就必须用索引来优化数据访问。在这么大的数据集找到小的数据包是个很有挑战性的工作因为你不可能在合理的时间內遍历所有数据。甚至,更有可能的是这么大的数据集分布在几个(甚至很多个)物理设备上-这意味着你要用些方法找到期望数据的正确物理位置。索引是最适合的方法做这种事情。
 Figure 1.16: Indexes
索引可以作为内容的一个表格-表格的每一项指明你的数据存储的位置。例如,如果你正在查找B的第二部分数据-你如何知道去哪里找?如果你有个根据数据类型(数据A,B,C)排序的索引,索引会告诉你数据B的起点位置。然后你就可以跳转(seek)到那个位置,读取你想要的数据B的第二部分。 (See Figure 1.16.)
这些索引常常存储在内存中,或者存储在对于客户端请求来说非常快速的本地位置(somewhere very local)。Berkeley DBs (BDBs)和树状数据结构常常按顺序存储数据,非常理想用来存储索引。
常常索引有很多层,当作数据地图,把你从一个地方指向另外一个地方,一直到你的得到你想要的那块数据。(See Figure 1.17.)
 Figure 1.17: Many layers of indexes
索引也可以用来创建同样数据的多个不同视图(views)。对于大数据集来说,这是个很棒的方法来定义不同的过滤器(filter)和类别(sort),而不用创建多个额外的数据拷贝。
例如,想象一下,图片存储系统开始实际上存储的是书的每一页的图像,而且服务允许客户查询这些图片中的文字,搜索每个主题的所有书的内容,就像搜索引擎允许你搜索HTML内容一样。在这种情况下,所有的书的图片占用了很多很多服务器存储,查找其中的一页给用户显示有点难度。首先,用来查询任意词或者词数组(tuples)的倒排索引(inverse indexes)需要很容易的访问到;然后,导航到那本书的确切页面和位置并获取准确的图片作为返回结果,也有点挑战性。所以,这种境况下,倒排索引应该映射到每个位置(例如书B),然后B要包含一个索引每个部分所有单词,位置和出现次数的索引。
可以表示上图Index1的一个倒排索引,可能看起来像下面的样子-每个词或者词数组对应一个包含他们的书。
Word(s)
Book(s)
being awesome
Book B, Book C, Book D
always
Book C, Book F
believe
Book B
这个中间索引可能看起来像上面的样子,但是可能只包含词,位置和书B的信息。这种嵌套的索引架构要使每个子索引占用足够小的空间,以防所有的这些信息必须保存在一个大的倒排索引中。
这是大型系统的关键点,因为即使压缩,这些索引也太大,太昂贵(expensive)而难以存储。在这个系统,如果我们假设我们世界上的很多书-100,000,000 (see Inside Google Books blog post)-每个书只有10页(只是为了下面好计算),每页有250个词,那就是2500亿(250 billion)个词。如果我们假设每个词有5个字符,每个字符占用8位(或者1个字节,即使某些字符要用2个字节),所以每个词占用5个字节,那么每个词即使只包含一次,这个索引也要占用超过1000GB存储空间。那么,你可以明白创建包含很多其他信息-词组,数据位置和出现次数-的索引,存储空间增长多快了吧。
创建这些中间索引和用更小分段表示数据,使的大数据问题可以得到解决。数据可以分散到多个服务器,访问仍然很快。索引是信息检索(information retrieval)的奠基石,是现代搜索引擎的基础。当然,我们这段只是浅显的介绍,还有其他很多深入研究没有涉及-例如如何使索引更快,更小,包含更多信息(例如关联(relevancy)),和无缝的更新(在竞争条件下(race conditions),有一些管理性难题;在海量添加或者修改数据的更新中,尤其还涉及到关联(relevancy)和得分(scoring),也有一些难题)。
快速简便的查找到数据是很重要的;索引是可以达到这个目的有效简单工具。
负载均衡器

最后还要讲讲所有分布式系统中另一个比较关键的部分,负载均衡器。负载均衡器是各种体系结构中一个不可或缺的部分,因为它们担负着将负载在处理服务请求的一组节点中进行分配的任务。这样就可以让系统中的多个节点透明地服务于同一个功能(参见图1.18)。它的主要目的就是要处理大量并发的连接并将这些连接分配给某个请求处理节点,从而可使系统具有伸缩性,仅仅通过添加新节点便能处理更多的请求。

图1.18: 负载均衡器
用于处理这些请求的算法有很多种,包括随机选取节点、循环式选取,甚至可以按照内存或CPU的利用率等等这样特定的条件进行节点选取。负载均衡器可以用软件或硬件设备来实现。近来得到广泛应用的一个开源的软件负载均衡器叫做 HAProxy)。
在分布式系统中,负载均衡器往往处于系统的最前端,这样所有发来的请求才能进行相应的分发。在一些比较复杂的分布式系统中,将一个请求分发给多个负载均衡器也是常事,如图1.19所示。
 图1.19: 多重负载均衡器
和代理类似,有些负载均衡器还可以基于请求的类型对不同的请求进行不同的处理(技术上讲,这样的叫做反向代理)。
负载均衡器面临的一个难题是怎么管理同用户的session相关的数据。在电子商务网站中,如果你只有一个客户端,那么很容易就可以把用户放入购物车里的东西保存起来,等他下次访问访问时购物车里仍能看到那些东西(这很重要,因为当用户回来发现仍然呆在购物车里的产品时很有可能就会买它)。然而,如果在一个session中将用户分发到了某个节点,但该用户下次访问时却分发到了另外一个节点,这里就有可能产生不一致性,因为新的节点可能就没有保留下用户购物车里的东西。(要是你把6盒子子农夫山泉放到购物车里了,可下次回来一看购物车空了,难道你不会发火吗?) 解决该问题的一个方法是可以使session具有保持性,让同一用户总是分发到同一个节点之上,但这样一来就很难利用类似failover这样的可靠性措施了。如果这样的话,用户的购物车里的东西不会丢,但如果用户保持的那个节点失效,就会出现一种特殊的情况,购物车里的东西不会丢这个假设再也不成立了(虽然但愿不要把这个假设写到程序里)。当然,这个问题还可以用本章中讲到的其它策略和工具来解决,比如服务以及许多并没有讲到的方法(象服务器缓存、cookie以及URL重写)。
如果系统中只有不太多的节点,循环式(round robin)DNS系统这样的方案也许更有意义,因为负载均衡器可能比较贵,而且还额外增加了一层没必要的复杂性。当然,在比较大的系统中会有各种各样的调度以及负载均衡算法,简单点的有随机选取或循环式选取,复杂点的可以考虑上利用率以及处理能力这些因素。所有这些算法都是对浏览和请求进行分发,并能提供很有用的可靠性工具,比如自动failover或者自动提出失效节点(比如节点失去响应)。然而,这些高级特性会让问题诊断难以进行。例如,当系统载荷较大时,负载均衡器可能会移除慢速或者超时的节点(由于节点要处理大量请求),但对其它节点而言,这么做实际上是加剧了情况的恶化程度。在这时进行大量的监测非常重要,因为系统总体流量和吞吐率可能看上去是在下降(因为节点处理的请求变少了),但个别节点却越来越忙得不可开交。
负载均衡器是一种能让你扩展系统能力的简单易行的方式,和本文中所讲的其它技术一样,它在分布式系统架构中起着基础性的作用。负载均衡器还要提供一个比较关键的功能,它必需能够探测出节点的运行状况,比如,如果一个节点失去响应或处于过载状态,负载均衡器可以将其总处理请求的节点池中移除出去,还接着使用系统中冗余的其它不同节点。
队列

目前为止我们已经介绍了许多更快读取数据的方法,但另一个使数据层具伸缩性的重要部分是对写的有效管理。当系统简单的时候,只有最小的处理负载和很小的数据库,写的有多快可以预知;然而,在更复杂的系统,写可能需要几乎无法决定的长久时间。例如,数据可能必须写到不同数据库或索引中的几个地方,或者系统可能正好处于高负载。这些情况下,写或者任何那一类任务,有可能需要很长的时间,追求性能和可用性需要在系统中创建异步;一个通常的做到那一点的办法是通过队列。
 Figure 1.20: Synchronous request
设想一个系统,每个客户端都在发起一个远程服务的任务请求。每一个客户端都向服务器发送它们的请求,服务器尽可能快的完成这些任务,并分别返回结果给各个客户端。在一个小型系统,一个服务器(或逻辑服务)可以给传入的客户端请求提供迅速服务,就像它们来的一样快,这种情形应该工作的很好。然而,当服务器收到了超过它所能处理数量的请求时,每个客户端在产生一个响应前,将被迫等待其他客户端的请求结束。这是一个同步请求的例子,示意在图1.20。
这种同步的行为会严重的降低客户端性能;客户端被迫等待,有效的执行零工作,直到它的请求被应答。添加额外的服务器承担系统负载也不会解决这个问题;即使是有效的负载均衡,为了最大化客户端性能,保证平等的公平的分发工作也是极其困难的。而且,如果服务器处理请求不可及,或者失败了,客户端上行也会失败。有效解决这个问题在于,需要在客户端请求与实际的提供服务的被执行工作之间建立抽象。 图 1.21:用队列管理请求
进入队列。一个队列就像它听起来那么简单:一个任务进入,被加入队列然后工人们只要有能力去处理就会拿起下一个任务。(看图1.21)这些任务可能是代表了简单的写数据库,或者一些复杂的事情,像为一个文档生成一个缩略预览图一类的。当一个客户端提交一个任务请求到一个队列,它们再也不会被迫等待结果;它们只需要确认请求被正确的接收了。这个确认之后可能在客户端请求的时候,作为一个工作结果的参考。

队列使客户端能以异步的方式工作,提供了一个客户端请求与其响应的战略抽象。换句话说,在一个同步系统,没有请求与响应的区别,因此它们不能被单独的管理。在一个异步的系统,客户端请求一个任务,服务端响应一个任务已收到的确认,然后客户端可以周期性的检查任务的状态,一旦它结束就请求结果。当客户端等待一个异步的请求完成,它可以自由执行其它工作,甚至异步请求其它的服务。后者是队列与消息在分布式系统如何成为杠杆的例子。
队列也对服务中断和失败提供了防护。例如,创建一个高度强健的队列,这个队列能够重新尝试由于瞬间服务器故障而失败的服务请求,是非常容易的事。相比直接暴露客户端于间歇性服务中断,需要复杂的而且经常矛盾的客户端错误处理程序,用一个队列去加强服务质量的担保更为可取。
队列对管理任何大规模分布式系统不同部分之间的分布式通信,是一个基础,而且实现它们有许多的方法。有不少开源的队列如 RabbitMQ, ActiveMQ, BeanstalkD,但是有些也用像 Zookeeper的服务,或者甚至像Redis的数据存储。
1.4. 结论

设计有效的系统来进行快速的大数据访问是有趣的,同时有大量的好工具来帮助各种各样的应用程序进行设计。 这文章只覆盖了一些例子,仅仅是一些表面的东西,但将会越来越多--同时在这个领域里一定会继续有更多创新东西。


转载自{http://www.oschina.net/translate/scalable-web-architecture-and-distributed-systems}

硬链接和软连接的区别:


要说明这个问题,先说明下liunx下文件和目录的本质。
事实上,在liunx上,目录也是文件的一种,它是储存了一张表的文件。例如有一个叫程序的文件夹,里面有两个文件1和2.在那张目录表内。它的内容是这样的
名称 节点
1 338
2 228
那么什么是节点呢?c语言我们都学过,我们简单地把节点号理解成一个数组的下标,把内存看成一个大数组,每个文件都可以看成一个数组中的一个元素,而知道了节点号,就可以找到了实质的文件内容。

有了以上的认识,就可以进一步地解释硬链接:
硬链接的书写格式是:ln 目标文件名 链接名
那么它的过程是怎么样的呢?
例如我们输入:ln 3 2
那么,在同个目录表下增加一项
名称 节点
1 338
2 228
3 228
这时候,文件3也指向了跟2一样的内存块,也就是说跟2的内容是完全一样的。
而软连接又是怎么回事呢?
这里得说明,软连接和硬链接也是特殊的文件,在liunx中的所有都是以文件表示的,软连接可以看成一个文本文件,它的内容是保存目标文件名的路径地址。
软连接的格式是ln -s 目标文件名 链接名
例如输入 ln -s 4 2
它的执行过程是这样的,先把2文件的路径名复制到4,执行4时,先从中读到2的路径名,找到2这个文件,然后执行2.所以对4文件的操作都是对2文件的操作。

上面说明了具体的原理。如果要通俗点理解。可以把硬链接当成源文件的副本,它显示跟源文件一样的大小但事实上却不占任何空间。(够神奇吧)而软连接大可以理解出windows的快捷方式。

至于更深入的区别,欢迎一起来讨论

linux软连接与硬链接




存在两种不同类型的链接,软链接和硬链接。硬连接指向的是节点(inode),而软连接指向的是路径(path)

软链接文件

软链接又叫符号链接,这个文件包含了另一个文件的路径名。可以是任意文件或目录,可以链接不同文件系统的文件。和win下的快捷 方式差不多。 链接文件甚至可以链接不存在的文件,这就产生一般称之为"断链"的问题(或曰“现象"),链接文件甚至可以循环链接自己。类似于编程语言中的递归。
命令格式:
代码: ln [-s] source_path target_path

硬链接文件

info ln 命令告诉您,硬链接是已存在文件的另一个名字,硬连接的命令是:
代码: ln -d existfile newfile //如果不加任何参数,默认情况下是硬链接.
硬链接文件有两个限制:
1、不允许给目录创建硬链接;
2、只有在同一文件系统中的文件之间才能创建链接。
对硬链接文件进行读写和删除操作时候,结果和软链接相同。但如果我们删除硬链接文件的源文件,硬链接文件仍然存在,而且保留了原有的内容。这时,系统就“忘记”了它曾经是硬链接文件。而把他当成一个普通文件。修改其中一个,与其连接的文件同时被修
改.
代码:
$ cp /etc/httpd/conf/httpd.conf /usr/sam
$ ln httpd.conf httpd1.conf
$ ln -s httpd.conf httpd2.conf
第一条为硬链接,第二条为软链接
代码:
$ ls -li //查看一个文件或目录的inode,要通过ls 命令的的 -i参数,inode值相同的文件,他们的关系是互为硬链接的关系
代码:
总用量 80
1077669 -rw-r--r-- 2 sam adm 34890 10月 31 00:57 httpd1.conf
1077668 lrwxrwxrwx 1 sam adm 10 10月 31 00:58 httpd2.conf ->; httpd.conf
1077669 -rw-r--r-- 2 sam adm 34890 10月 31 00:57 httpd.conf
可以看到,使用ls -li,软连接只产生了10字节的快捷而已,硬连接却实实在在的的拷贝。最前面的inode硬链接和源文件是一样的
,而软链接不一样.对http1.conf进行编辑,可以发现httpd.conf也发生了一样的变化.
代码:
$ rm httpd.conf
现在删除链接的源文件,来比较不同之处
代码:
$ ls -l
总用量 44
drw-r--r-- 2 sam adm 4096 10月 30 20:14 file6
-rw-r--r-- 1 sam adm 34890 10月 31 00:57 httpd1.conf
lrwxrwxrwx 1 sam adm 10 10月 31 00:58 httpd2.conf ->; httpd.conf
发现,httpd2.conf实际已经不存在了,是断链,而httpd1.conf变也了普通文件

盛宣怀

   “江山不管兴亡事,一任斜阳伴客愁”。盛宣怀家族从晚清中下层官僚一跃到大清豪门,前后花了近百年时间。盛宣怀运气好,赶上了历史潮流,他27岁时经友人推荐走入了李鸿章的幕府,并很快获得器重。盛宣怀精明过人,在李鸿章操办洋务的背景下,他既是官场中的商人,又是商人中的官吏,集官商于一身。在辛亥革命之前,盛宣怀家族的财富也达到了顶点。不过盛极而衰,作为清朝末代铁道部长,盛宣怀国有化铁路的政策激起的反抗最终淹没了大清朝。而他自己也成了大清的掘墓人,家族也很快衰落。
三代权势显赫 掌控大清实业

盛宣怀家族是如何发达起来的

  盛氏家族本来也只是地方中下层官僚阶层,由于抓住了机遇,家族迅速发达起来。盛宣怀跟随李鸿章一步步从军营文书做到一品尚书,从典当掌柜变为掌握大清十几家垄断企业的实业家。他办洋务40年,一生亦官亦商,亦中亦洋,势倾朝野,富可敌国。

死心塌地跟着李鸿章 从地方大户一跃到大清豪门

  从常州大户到大清豪门,这一跨跃是由盛宣怀来完成的。盛宣怀只中过秀才,参加三次乡试考举人都名落孙山,后来干脆管起了典当钱庄生意。1870年,李鸿章率军前往陕西征剿回民起义军。经朋友介绍,盛宣怀进了李鸿章幕府当文书,从此跟随李鸿章一步步从军营文书做到一品尚书,从典当掌柜变为掌握大清十几家垄断企业的实业家。
  李鸿章为何那么器重一个连举人也没有考上的幕僚?李鸿章所以器重盛宣怀,是因为盛宣怀的“经世致用”思想符合他的洋务强国宏图,盛宣怀的务实和精干也符合他的用人要求。作为洋务派领袖,李鸿章当时正在酝酿创办一批企业,却缺少精明的实干人才。他发现盛宣怀是个可塑之才,就有意识地给盛宣怀提供机会。1872年,李鸿章发起创办中国近代第一家大型民用企业轮船招商局时,让盛宣怀与上海的航运世家朱其昂、广东的怡和洋行买办唐廷枢等共同参与起草轮船招商局章程。盛宣怀起草的章程思路前瞻,条理清晰,见解独到,受到李鸿章的赏识。由此,盛宣怀被委任为会办(副总经理),走上了洋务之路。
  盛宣怀认准了这是一条可以“做大事、成大业”的路,要死心塌地跟着李鸿章。他写信表忠心:“百年之后,或可以姓名附列于中堂传策之后,吾愿足矣!”就是说,将来李鸿章传记里能把他盛宣怀的名字列上,他就心满意足了。1886年,盛宣怀在山东做官时,还给李鸿章写信,表示自己追随李鸿章20多年,“近年办事稍有把握,俱由亲炙而来。”意思是“我的所有成功都是您手把手教出来的”,流露出感恩戴德之心。

当官时摸透市场行情 在位时儿女下海经商

  盛氏家族自明代永乐年间就从南京迁居到常州,至晚清已在常州生活了400多年。在乾隆之前,虽然盛宣怀的祖父盛隆在浙江做过几任知县,盛家也只不过称得上地方乡绅而已。
  盛宣怀出生于1844年11月,据说那年春天,盛隆梦见常州老宅庭院中的杏花开得灿烂如锦,觉得是个吉兆。结果,儿子盛康这年不但中举,又喜得贵子。盛隆就给孙子取了个字号“杏荪”。说也奇怪,此后盛家果然发达起来。
  当然“吉兆”只是传说而已,盛氏家族的发达是靠抓住机遇。盛康在湖北当过两任道台,先当督粮道,后做盐法道。督粮道负责监管督运漕粮,盐法道则负责食盐生产、定价、收购、运输。盛康在做督粮道时,对粮价十分熟悉,就让女儿、女婿在常州开米行赚钱。

李鸿章出金点子助其发大财 典当钱庄赚得盆满钵满

  不过,这样赚点小钱的生意发不了财。1867年盛隆去世,按清代官制,盛康要回原籍居丧27个月,称为“丁忧”。盛康辞官扶送盛隆的灵柩回到常州。那时太平天国战争结束不久,常州一带难民纷纷返回重建家业,却缺乏资金。
  时任江苏巡抚的李鸿章是盛康的同年,建议盛康回常州后开几家典当行,定可赚钱。盛康本来也就闲着,听了李鸿章的意见,一回常州就积极筹办此事。次年7月,盛家第一家典当“济大典”就在吴县(今属苏州)开张了,没想到生意好得出奇。盛康看出这是一生财之道,接下来在常州、南京、江阴、无锡、宜兴、常熟大张旗鼓地开起典当来。不到10年,盛氏旗下的典当有了20多家,盛氏私有账号“愚记”的资产高达数百万两白银。
  办典当要融资,典当业的经营与钱庄是分不开的。盛氏家族于是又集资开起了钱庄。本钱和利润从钱庄流到典当,又从典当流回钱庄。发家以后,盛康在苏州石路置办了房产,还把私人花园刘园买了下来,改名“留园”。到光绪初年,常州盛氏成为远近闻名的大户人家。


BRIEF 2

若问古今兴废事 请君只看盛宣怀

百年豪门十年衰

  俗话说:富不过三代。盛宣怀去世后,他的家族人吵着分家的、争名分打官司的、要求继承遗产的、搞风流韵事的、闹诉讼案件的,一度成为上海滩的街头新闻,不久,连盛宣怀用来保存部分财产的愚斋义庄也关闭了,真是百年豪门十年衰。

“盛”到了极致 贪污受贿的骂名接踵而来

   盛宣怀参与创办和掌控的我国近代史上第一批实业,有轮船招商局、汉冶萍煤铁总公司、上海华盛纺织厂、中国电报局、中国铁路总公司、中国通商银行,都是晚清政府参股的大型企业。这反映出盛宣怀在实业界的显赫地位。
   盛氏家族的富有,自然引起不少人的议论,他是否贪污受贿、中饱私囊,当时就是一个引人关注的话题。1876年,轮船招商局欲并购美资旗昌轮船公司,盛宣怀从两江总督沈葆桢那里借了100万两白银官款,以总价222万两白银的价格买下了旗昌在华所有资产,消灭了一个竞争对手。但这件事受到不少非议。御史王先谦上奏弹劾盛宣怀,说旗昌轮船公司不值这个价,盛宣怀拿了人家回扣。虽有李鸿章竭力袒护,盛宣怀还是受到降职处分,被排挤出招商局。
   这是盛宣怀第一次遭到贪污指责。他究竟有没有拿回扣?当时没有证据,他也竭力表明自己的清白。李鸿章一直认为这是反对派对洋务企业的故意捣乱,后来找机会帮盛宣怀洗刷了罪名。

一个都不能少:护官符 潜规则 上面要有人

  盛宣怀交往的人很多,面也很广,他很重视与同乡的联系。《红楼梦》中有所谓“护官符”,道出了封建社会官场官官相护的“潜规则”。盛宣怀要做高官,成大事,也跳不出“潜规则”。
  年节送礼是一种习俗,但是对那些需要求助的大人物,紧要关头不送些贵重礼品肯定是不行的。他的第二个夫人庄畹玉出身常州望族,是个精明的女人。1899年,盛宣怀被慈禧太后召进宫中“垂询”,在北京待了一段时间。庄夫人给他写信说:“你在北京要多找门路,听说皮小连虽是太监,荣宠非凡,若要升迁,要走他门路,你要舍得花些小钱去巴结巴结,让人家高兴,不说你的坏话。”这个“皮小连”是指大太监李莲英。
  当然,有时候别人送给盛宣怀的礼物也是价值不菲的。曾经和盛宣怀一起在轮船招商局共事的朱其昂和他的关系比较好,一次送了他4件礼物:翡翠烟壶、白玉翎管、黄玉扳指、红牙珠顶。朱家是清代上海著名的沙船世家,长期经营水上运输,送得起这样贵重的礼品,怕盛宣怀不肯收,特意写信说这是家中旧存的小玩意儿,不是特意买来的。

妻妾成群想必是极好的? 财富再多也敌不过三代

  盛宣怀前后娶了两个夫人,5个妾,生有8个儿子,8个女儿,盛公馆中吃闲饭的不下百十来人。妻妾成群,免不了争宠斗艳,儿孙不知生活艰辛,赌马的赌马,嫖娼的嫖娼,抽大烟的抽大烟,虽说盛宣怀年轻时管过典当钱庄,却也没有精力管住家里那么多号人。他规定每个月给姨太太60元大洋生活费,由账房按月付给,他在苏州的姨太太秦氏看中了银楼一副头面,没钱就赊账买了回来,然后给盛宣怀写信,说欠了银楼218两银子,请老爷派人去付清。盛宣怀心中恼火,却碍于面子只好另掏腰包。他的大儿子盛昌颐整天在外花天酒地,娶了6个女人还到处寻花问柳,40岁就死了,比盛宣怀去世还早十多年。
  俗话说:富不过三代。怎样才能长期保持家族的凝聚和财富?盛宣怀曾在日本呆过一年,从一个日本家族的管理模式得到启发。逝世前,他立下遗嘱,成立愚斋义庄基金会,遗产的一半分给各房子孙,另一半580万两银子放在愚斋义庄,本金不许动用,利息用于慈善事业,想用这个办法长期保住盛氏家族的一部分财产。1916年盛宣怀去世,基金会由庄夫人掌管,别人也没有异议。不过盛家的子辈大手大脚惯了,挥霍无度,没有多久,各房分到手的财产已消耗大半。
  国民党政府也对愚斋基金会这笔财产垂涎三尺,经常发公函要求愚斋义庄捐款赈灾,认购国债。国债还本付息的时间很长,买了几次,账面上财产没有减少,实际可动用的资金少了,变成了纸上财富。1927年庄夫人去世,再也没人能约束盛家的公子小姐姨太太,于是吵着分家的、争名分打官司的、要求继承遗产的、搞风流韵事的、闹诉讼案件的,盛家的很多事情,一度成为上海滩的街头新闻。愚斋义庄在盛宣怀去世后12年就寿终正寝,恐怕是盛宣怀难以预料的。

要识人间盛衰理 岸沙君看去年痕

盛宣怀是一面好镜子

   陆游《夜登白帝城楼怀少陵先生》有两句诗:要识人间盛衰理,岸沙君看去年痕。意思是人间之事盛衰因循,你且看那岸沙边,春去秋来花肥瘦,今年的模样仍有着去年的痕迹。盛宣怀既是官场中的商人,又是商人中的官吏,集官商于一身。经过几十年的经营,他敛财之巨,达到了富可敌国的程度。但富不过三代,他个人与家族命运转折的历史或许能给后人以启示。

赶上历史潮流思想不保守 因修铁路发大财

  当时,西学东渐已成为一种历史的潮流。盛宣怀的思想并不保守,而且相当“开放”,史学家庄练先生说盛宣怀“以招商局起家,以铁路致富,以电报而享大名,以投资矿冶事业得以结交政要”(《中国近代史上的关键人物》下卷第265页)。上述概括相当准确。
  在当时,比电报投资更多,购物更多,吃回扣自然也更多的是修筑铁路。盛宣怀作为铁路督办大臣干了9年。据《盛宣怀与中国铁路》一书中统计,从光绪二十二年至三十二年,盛宣怀共修筑铁路2200公里。其间,从英国借了1065万英镑,盛宣怀吃回扣5%,折合中国的白银440万两。

他给大清代言 他为大清掘墓

  历史有时充满了戏剧性。盛宣怀对大清王朝是忠诚不贰的,因为有了这个政权,他才能为官而贪,但清王朝土崩瓦解的导火线也正是盛宣怀点燃的。宣统三年四月,邮传部大臣盛宣怀突然下令,把“官督商办”的铁路收归国有。
  这样一来,投资粤汉、川汉铁路的股东们,一下子被剥夺得两手空空,由此引发了四川剧烈的铁路风潮。这一年农历八月十九日武昌发生兵变,辛亥革命爆发。盛宣怀无意中点燃了辛亥革命的导火线,他成了大清王朝的第一个掘墓人。贪官危及政权,这是一个生动的历史证明。

权力与资本结合的制度产生有毒物

  平心而论,盛宣怀做过不少好事。比如:1895年他创办了“北洋西学学堂”,1903年升格为北洋大学,即现在的天津大学;1896年他在上海创办了“南洋公学”,后来发展为上海交通大学;中国的红十字会也是盛宣怀创办的。他兴办的多种实业,对中国民族工商业的发展也有重大的贡献。
  当年的盛宣怀过着锦衣玉食的生活,他的正当收入已可满足个人和家庭的一切物质需求,为何还要无休止地敛财呢?虚幻的占有欲是主因。而他的巨额财产如今早已灰飞烟灭。把钱留给子孙可能是唯一实在的目的,但富不过三代,在奢侈生活中长大的子孙,多半是败家子。除了虚幻心理作祟,“官督商办”的制度成就了贪腐。权力和资本如果各自运转,本来无害,但一旦结合,就像化学反应,无毒之物就变成了有毒的化合物。(资料来源:《环球人物》2009年第15期、《学习时报》、中国共产党新闻网、人民网等等)

信阳一小学生上学途中激怒流浪汉 被用砖头砸死



大河报:【信阳一小学生被流浪汉用砖头砸死】3月22日凌晨,被流浪男子袭击的信阳市东双河镇第一小学五年级学生杨鑫明因头骨受伤,颅内出血,救治无效死亡。13日,杨鑫和其几名同伴在上学途中激怒一名被疑患精神病的流浪男子,被流浪男子追至东双河镇第一小学的校园内后,用砖块砸成重伤。大河报首席记者何正权