分布式网站架构设计

1、求完整版的 《大型分布式网站架构设计与实践》pdf 电子书

《大型分布式网站架构设计与实践》主要介绍了大型分布式网站架构所涉及的一些技术细节，包括SOA架构的实现、互联网安全架构、构建分布式网站所依赖的基础设施、系统稳定性保障和海量数据分析等内容；深入地讲述了大型分布式网站架构设计的核心原理，并通过一些架构设计的典型案例，帮助读者了解大型分布式网站设计的一些常见场景及遇到的问题。

2、lamp的网站架构方案

LAMP（Linux- Apache-MySQL-PHP）网站架构是目前国际流行的Web框架，该框架包括：Linux操作系统，Apache网络服务器，MySQL数据 库，Perl、PHP或者Python编程语言，所有组成产品均是开源软件，是国际上成熟的架构框架，很多流行的商业应用都是采取这个架构，和 Java/J2EE架构相比，LAMP具有Web资源丰富、轻量、快速开发等特点，微软的.NET架构相比，LAMP具有通用、跨平台、高性能、低价格的 优势，因此LAMP无论是性能、质量还是价格都是企业搭建网站的首选平台。
对于大流量、大并发量的网站系统架构来说，除了硬件上使用高 性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能的操作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Database）、高效率的编程语言等。下面我将从这几点对其一一讨论。
操作系统
Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprise、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性 和性能的考虑，操作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。
CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。
Web服务器、缓存和PHP加速
Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web 服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。
Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的HTTP和反向代理服 务器，Nginx以它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx不支持PHP和CGI等动态语言，但支持负载均衡和容 错，可和Apache配合使用，是轻量级的HTTP服务器的首选。
Web服务器的缓存也有多种方案，Apache提供了自己的缓存模 块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。Squid Cache是一个Web缓存服务器，支持高效的缓存，可以作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，把Squid放在 Apache的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。如访问量巨大则可考虑使用memcache作 为分布式缓存。
PHP的加速使用eAccelerator加速器，eAccelerator是一个自由开放源码PHP加速器，优化和动 态内容缓存，提高了性能PHP脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。 使PHP程序代码执效率能提高1-10倍。
具体的解决方案有以下几种：
1、squid + Apache + PHP + eAccelerator
使用Apache负载PHP，使用squid进行缓存，html或图片的请求可以直接由squid返回给用户。很多大型网站都采用这种架构。
2、nginx/Apache + PHP（fastcgi） + eAccelerator
使用nginx或Apache负载PHP，PHP使用fastcgi方式运行，效率较高。
3、nginx + Apache + PHP + eAccelerator
此方案综合了nginx和Apache的优点，使用Apache负载PHP，nginx负责解析其他Web请求，使用nginx的rewrite模块，Apache端口不对外开放。
数据库
开源的数据库中，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储，网站初期可以将MySQL和Web服务器放在一起，但是当访问 量达到一定规模后，应该将MySQL数据库从Web Server上独立出来，在单独的服务器上运行，同时保持Web Server和MySQL服务器的稳定连接。
当数据库访问量达到更大的级别，可以考虑使用MySQL Cluster等数据库集群或者库表散列等解决方案。
总的来说，LAMP架构的网站性能会远远优于Windows IIS + ASP + Access（例如月光博客）这样的网站，可以负载的访问量也非常大，国内的大量个人网站如果想要支撑大访问量，采用LAMP架构是一个不错的方案。
综上所述，基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点，是Web网络应用和环境的优秀组合。

3、什么是分布式集群？

分布式与集群是不一样的，简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行改任务需10小时。

采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。

而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，10小后，10个任务同时完成，这样，整体来看，还是1小时内完成一个任务。

(3)分布式网站架构设计扩展资料

分布式系统可以分为机体内系统、建筑物内系统、建筑物间系统和不同地理范围的区域系统等，它们的耦合度依次由高到低按应用领域的性质决定耦合度，可以分成三类：

一、是面向计算任务的分布并行计算机系统和分布式多用户计算机系统，它们要求尽可能高的耦合度，以便发展成为能分担大型计算机和分时计算机系统所完成的工作。

二、是面向管理信息的分布式数据处理系统。耦合度可以适当降低。

三、是面向过程控制的分布式计算机控制系统。耦合度要求适中，当然对于某些实时应用，其耦合度的要求可能很高。

4、何谓分布式服务器，怎么理解分布式服务框架

分布式是架构部署模式的一种。分布式多用于描述架构设计上，当然现在有各种新用法。
集群是硬件部署模式的一种，是集中部署在一个机房里的计算机群体的集中称谓。
分布式网站集群系统是一种多网站架构模式，支持生成独立网站、多个网站,完成各个网站横向一体化和纵向一体化网站群的构建，主站、子站、网站间的信息可共享和信息互联。
简单的说：　就是一个企业/个人可以像申请博客那样自助建站，维护，更新，而分布式，就是把问题分开解决的意思，即系统分布在几个不同服务器上。

5、大型分布式网站架构设计与实践 怎么样

大型分布式网站架构设计与实践 这本书 的点评如下：
书中提到了很多大型分布式网站设计所必须的知识点，如soa、分布式系统的基础设施，
系统稳定性设计，数据分析，系统稳定设计的章节写的很有实践性，
自检脚本的编写、日志分析命令的妙用，互联网安全方面之前讲类似知识点的，
书中介绍的比较详细，不错
还有疑问请追问没有疑问请采纳。

6、大型网站架构模式有哪些

1.分布式
对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
2.分层
分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
分层结构在计算机世界中无处不在，网络的7层通信协议是一种分层结构；计算机硬件、操作系统、应用软件也可以看作是一种分层结构。在大型网站架构中也采用分层结构，将网站软件系统分为应用层、服务层、数据层。
3.分割
如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
4.集群
使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块（比如网站的首页），还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
5.缓存
缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。
6.异步
计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前面提到的分层、分割、分布等，还有一个重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

7、求 《大型分布式网站架构设计与实践》陈康贤 全章 PDF

我帮你下好了共享的我的网络云盘里面了请去下载记得好评哦~哈哈

8、分布式系统的异步处理流程通常有哪些设计解决方案

开源软件已经成为许多大型网站的基本组成部分，随着这些网站的逐步壮大，他们的网站架构和一些指导原则也出现在开发者们的面前，给予切实有用的指导和帮助。本文旨在介绍一些核心问题以及通过构建模块来制作大型网站，实现最终目标。 这篇文章主要侧重于Web系统，并且也适用于其他分布式系统。 Web分布式系统设计的原则 构建并运营一个可伸缩的Web站点或应用程序到底指的是什么?在最初，仅是通过互联网连接用户和访问远程资源。 和大多数事情一样，当构建一个Web服务时，需要提前抽出时间进行规划。了解大型网站创建背后的注意事项以及权衡可能会给你带来更加明智的决策，当你在创建小网站时。下面是设计大型Web系统时，需要注意的一些核心原则： 1.可用性 2.性能 3.可靠性 4.可扩展 5.易管理 6.成本 上面的这些原则给设计分布式Web架构提供了一定的基础和理论指导。然而，它们也可能彼此相左，例如实现这个目标的代价是牺牲成本。一个简单的例子：选择地址容量，仅通过添加更多的服务器(可伸缩性)，这个可能以易管理(你不得不操作额外的服务器)和成本作为代价(服务器价格)。 无论你想设计哪种类型的Web应用程序，这些原则都是非常重要的，甚至这些原则之间也会互相羁绊，做好它们之间的权衡也非常重要。 基础 当涉及到系统架构问题时，这几件事情是必须要考虑清楚的：什么样的模块比较合适?如何把它们组合在一起?如何进行恰当地权衡?在扩大投资之前，它通常需要的并不是一个精明的商业命题，然而，一些深谋远虑的设计可以帮你在未来节省大量的时间和资源。 讨论的重点几乎是构建所有大型Web应用程序的核心：服务、冗余、分区和故障处理能力。这里的每个因素都会涉及到选择和妥协，特别是前面所讨论的那些原则。解释这些核心的最佳办法就是举例子。 图片托管应用程序 有时，你会在线上传图片，而一些大型网站需要托管和传送大量的图片，这对于构建一个具有成本效益、高可用性并具有低延时(快速检索)的架构是一项挑战。 在一个图片系统中，用户可以上传图片到一个中央服务器里，通过网络连接或API对这些图片进行请求，就像Flickr或者Picasa。简单点，我们就假设这个应用程序只包含两个核心部分：上传(写)图片和检索图片。图片上传时最好能够做到高效，传输速度也是我们最关心的，当有人向图片发出请求时(例如是一个Web页面或其他应用程序)。这是非常相似的功能，提供Web服务或内容分发网络(一个CDN服务器可以在许多地方存储内容，所以无论是在地理上还是物理上都更加接近用户，从而导致更快的性能)边缘服务器。 该系统需要考虑的其他重要方面： 1.图片存储的数量是没有限制的，所以存储应具备可伸缩，另外图片计算也需要考虑 2.下载/请求需要做到低延迟 3.用户上传一张图片，那么图片就应该始终在那里(图片数据的可靠性) 4.系统应该易于维护(易管理) 5.由于图片托管不会有太高的利润空间，所以系统需要具备成本效益 图1是个简化的功能图 图1 图片托管系统的简化结构图 在这个例子中，系统必须具备快速、数据存储必须做到可靠和高度可扩展。构建一个小型的应用程序就微不足道了，一台服务器即可实现托管。如果这样，这篇文章就毫无兴趣和吸引力了。假设我们要做的应用程序会逐渐成长成Flickr那么大。 服务 当我们考虑构建可伸缩的系统时，它应有助于解耦功能，系统的每个部分都可以作为自己的服务并且拥有清晰的接口定义。在实践中，这种系统设计被称作面向服务的体系结构(SOA)。对于此类系统，每个服务都有它自己的独特功能，通过一个抽象接口可以与外面的任何内容进行互动，通常是面向公众的另一个服务 API。 把系统分解成一组互补性的服务，在互相解耦这些操作块。这种抽象有助于在服务、基本环境和消费者服务之间建立非常清晰的关系。这种分解可以有效地隔离问题，每个块也可以互相伸缩。这种面向服务的系统设计与面向对象设计非常相似。 在我们的例子中，所有上传和检索请求都在同一台服务器上处理。然而，因为系统需要具备可伸缩性，所以把这两个功能打破并集成到自己的服务中是有意义的。 快进并假设服务正在大量使用;在这种情况下，很容易看到写图片的时间对读图片时间有多大影响(他们两个功能在彼此竞争共享资源)。根据各自体系，这种影响会是巨大的。即使上传和下载速度相同(这是不可能的，对于大多数的IP网络来说，下载速度：上传速度至少是3:1)，通常，文件可以从缓存中读取，而写入，最终是写到磁盘中(也许在最终一致的情况下，可以被多写几次)。即使是从缓存或者磁盘(类似SSD)中读取，数据写入都会比读慢(Pole Position，一个开源DB基准的开源工具和结果)。 这种设计的另一个潜在问题是像Apache或者Lighttpd这些Web服务器通常都会有一个并发连接数上限(默认是500，但也可以更多)，这可能会花费高流量，写可能会迅速消掉所有。既然读可以异步或利用其他性能优化，比如gzip压缩或分块传输代码，Web服务可以快速切换读取和客户端来服务于更多的请求，超过每秒的最大连接数(Apache的最大连接数设置为500，这种情况并不常见，每秒可以服务几千个读取请求)。另一方面，写通常倾向于保持一个开放的链接进行持续上传，所以，使用家庭网络上传一个1 MB的文件花费的时间可能会超过1秒，所以，这样的服务器只能同时满足500个写请求。 图2：读取分离 规划这种瓶颈的一个非常好的做法是把读和写进行分离，如图2所示。这样我们就可以对它们单独进行扩展(一直以来读都比写多)但也有助于弄明白每个点的意思。这种分离更易于排除故障和解决规模方面问题，如慢读。 这种方法的优点就是我们能够彼此独立解决问题——在同种情况下，无需写入和检索操作。这两种服务仍然利用全球语料库的图像，但是他们可以自由地优化性能和服务方法(例如排队请求或者缓存流行图片——下面会介绍更多)。从维护和成本角度来看，每一个服务都可以根据需要独立进行扩展，但如果把它们进行合并或交织在一起，那么有可能无意中就会对另一个性能产生影响，如上面讨论的情景。 当然，如果你有两个不同的端点，上面的例子可能会运行的很好(事实上，这非常类似于几个云存储供应商之间的实现和内容分发网络)。虽然有很多种方法可以解决这些瓶颈，但每个人都会有不同的权衡，所以采用适合你的方法才是最重要的。 例如，Flickr解决这个读/写问题是通过分发用户跨越不同的碎片，每个碎片只能处理一组用户，但是随着用户数的增加，更多的碎片也会相应的添加到群集里(请参阅Flickr的扩展介绍)。在第一个例子中，它更容易基于硬件的实际用量进行扩展(在整个系统中的读/写数量)，而Flickr是基于其用户群进行扩展(but forces the assumption of equal usage across users so there can be extra capacity)。而前面的那个例子，任何一个中断或者问题都会降低整个系统功能(例如任何人都没办法执行写操作)，而Flickr的一个中断只会影响到其所在碎片的用户数。在第一个例子中，它更容易通过整个数据集进行操作——例如，更新写服务，包括新的元数据或者通过所有的图片元数据进行搜索——而 Flickr架构的每个碎片都需要被更新或搜索(或者需要创建一个搜索服务来收集元数据——事实上，他们就是这样做的)。 当谈到这些系统时，其实并没有非常正确的答案，但有助于我们回到文章开始处的原则上看问题。确定系统需求(大量的读或写或者两个都进行、级别并发、跨数据查询、范围、种类等等)，选择不同的基准、理解系统是如何出错的并且对以后的故障发生情况做些扎实的计划。 冗余 为了可以正确处理错误，一个Web架构的服务和数据必须具备适当的冗余。例如，如果只有一个副本文件存储在这台单独的服务器上，那么如果这台服务器出现问题或丢失，那么该文件也随即一起丢失。丢失数据并不是什么好事情，避免数据丢失的常用方法就是多创建几个文件或副本或冗余。 同样也适用于服务器。如果一个应用程序有个核心功能，应确保有多个副本或版本在同时运行，这样可以避免单节点失败。 在系统中创建冗余，当系统发生危机时，如果需要，可以消除单点故障并提供备份或备用功能。例如，这里有两个相同的服务示例在生产环境中运行，如果其中一个发生故障或者降低，那么该系统容错转移至那个健康的副本上。容错转移可以自动发生也可以手动干预。 服务冗余的另一重要组成部分是创建一个无共享架构。在这种体系结构中，每个节点都能相互独立运行，并且没有所谓的中央“大脑”管理状态或协调活动其他节点。这对系统的可扩展帮助很大，因为新节点在没有特殊要求或知识的前提下被添加。然而，最重要的是，这些系统是没有单点故障的，所以失败的弹性就更大。 例如在我们的图片服务器应用程序中，所有的图片在另一个硬件上都有冗余副本(理想情况下是在不同的地理位置，避免在数据中心发生一些火灾、地震等自然事故)，服务去访问图片将被冗余，所有潜在的服务请求。(参见图3：采用负载均衡是实现这点的最好方法，在下面还会介绍更多方法) 图3 图片托管应用程序冗余 分区 数据集有可能非常大，无法安装在一台服务器上。也有可能这样，某操作需要太多的计算资源、性能降低并且有必要增加容量。在这两种情况下，你有两种选择：纵向扩展或横向扩展。 纵向扩展意味着在单个服务器上添加更多的资源。所以，对于一个非常大的数据集来说，这可能意味着添加更多(或更大)的硬件设备，来使一台服务器能容下整个数据集。在计算操作下，这可能意味着移动计算到一个更大的服务器上，拥有更快的CPU或更大的内存。在各种情况下，纵向扩展可以通过提升单个资源的处理能力来完成。 横向扩展在另一方面是添加更多的节点，在大数据集下，这可能会使用第二服务器来存储部分数据集，对于计算资源来说，这意味着分割操作或跨节点加载。为了充分利用横向扩展，它应作为一种内在的系统架构设计原则，否则修改或拆分操作将会非常麻烦。 当谈到横向扩展时，最常见的做法是把服务进行分区或碎片。分区可以被派发，这样每个逻辑组的功能就是独立的。可以通过地理界限或其他标准，如非付费与付费用户来完成分区。这些方案的优点是他们会随着容量的增加提供一个服务或数据存储。 在我们的图片服务器案例中，用来存储图片的单个文件服务器可能被多个文件服务器取代，每个里面都会包含一套自己独特的图像。(见图4)这种架构将允许系统来填充每一个文件/图片服务器，当磁盘填满时会添加额外的服务器。这样的设计需要一个命名方案，用来捆绑图片文件名到其相应的服务器上。图像名字可以形成一个一致的哈希方案并映射到整个服务器上;或者给每张图片分配一个增量ID，当客户端对图片发出请求时，图片检索服务只需要检索映射到每个服务器上(例如索引)的ID。 图4 图片托管应用程序冗余和分区 当然，跨越多个服务器对数据或功能进行分区还是有许多挑战的。其中的关键问题是数据本地化。在分布式系统中，数据操作或计算点越接近，系统性能就会越好。因此，它也可能是个潜在问题，当数据分散在多个服务器上时。有时数据不是在本地，那么就要迫使服务器通过网络来获取所需的信息，这个获取的过程就会设计到成本。 另一潜在问题是不一致。当这里有多个服务对一个共享资源执行读写操作时，潜在可能会有另一个服务器或数据存储参与进来，作为竞选条件——一些数据需要更新，但是读的优先级高于更新——在这种情况下，数据就是不一致的。例如在图片托管方案中，有可能出现的不一致是：如果一个客户端发送更新“狗”图片请求，进行重新命名，把“Dog”改成“Gizmo”，但同时，另一个客户端正在读这张图片。在这种情况下，标题就是不清楚的。“Dog”或“Gizmo” 应该被第二个客户端接收。 当然，在进行数据分区时会产生一些障碍，但是分区允许把每个问题拆分到管理群里——通过数据、负载、使用模式等。这样对可扩展和易管理都是有帮助的，但也不是没有风险的。这里有很多方式来降低风险和故障处理;然而，为了简便起见，并未在本文中详细说明，如果你有兴趣，可以访问我的博客。 总结 以上介绍的都是设计分布式系统需要考虑的核心要素。可用性、性能、可靠性、可扩展、易管理、成本这几个原则非常重要，但在实际应用中可能会以牺牲某个原则来实现另外一个原则，在这个过程中就要做好权衡工作，做到因时制宜。 在下面的构建分布式系统实战中，我们将会深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、全局缓存、分布式缓存等。 英文地址：Dr.Dobb's 文：CSDN