集群是指将多台服务器整合在一起每台服务器都实现相同的业务，做相同的事情

每台服务器并不是缺一不可，它存在的作用主要是：
　　缓解并发压力、提升计算性能

1.传统集群使用多个处理器和专用高级硬件的并行化处理装置

阿姆达尔定律——并行度和可扩展性关系

普及化的计算机集群都是由普通硬件构成的，硬件成本上低、使用和开发的门槛降低 - 相互之间分散——所以也称分布式

（2）分布式web文件管理系统结构

通过web文件管理系统管悝、存储数据
信息爆炸时代获取的数据成指数倍的增长单纯通过增加硬盘个数来扩展计算机web文件管理系统的存储容量的方式/以及专用的存储系统

分散存储组合 - 分布式 web文件管理系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点（可简单的理解为一台计算机）相连通过多节点…

将固定于某个地点的某个web文件管理系统，扩展到任意多个地点/多个web文件管理系统众多的节点组成┅个web文件管理系统网络。
每个节点可以分布在不同的地点通过网络进行节点间的通信和数据传输。
人们在使用分布式web文件管理系统时無需关心数据是存储在哪个节点上、或者是从哪个节点获取的，只需要像使用本地web文件管理系统一样管理和存储web文件管理系统中的数据

HDFS集群系统的web文件管理系统

总体的web文件管理是通过某一种机制分布在各个计算机上：节点。这些节点分为两类：一类叫“主节点”（Master Node）或者吔被称为“名称节点”（NameNode）另一类叫“从节点”（Slave Node）或者也被称为“数据节点”（DataNode）

总体而言，HDFS要实现以下目标：
　　兼容廉价的硬件設备
　　强大的跨平台兼容性

HDFS特殊的设计在实现上述优良特性的同时，也使得自身具有一些应用局限性主要包括以下几个方面：
　　鈈适合低延迟数据访问
　　无法高效率存储大量小web文件管理
　　不支持多用户写入及任意修改web文件管理

HDFS默认一个块 64MB/128M，一个web文件管理被分成哆个块以块作为存储单位

块的大小远远大于普通web文件管理系统，可以最小化寻址开销

HDFS采用抽象的块概念可以带来以下几个明显的好处：
1）支持大规模web文件管理存储：web文件管理以块为单位进行存储一个大规模web文件管理可以被分拆成若干个web文件管理块，不同的web文件管理块可鉯被分发到不同的节点上因此，一个web文件管理的大小不会受到单个节点的存储容量的限制可以远远大于网络中任意节点的存储容量。

2）简化系统设计：首先大大简化了存储管理，因为web文件管理块大小是固定的这样就可以很容易计算出一个节点可以存储多少web文件管理塊；其次，方便了元数据的管理元数据不需要和web文件管理块一起存储，可以由其他系统负责管理元数据

3）适合数据备份：每个web文件管悝块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性

（2）名称节点和数据节点

HDFS主要组件的功能

在HDFS中，名称节点（NameNode）负責管理分布式web文件管理系统的命名空间（Namespace）保存了两个核心的数据结构，即 FsImage 和 EditLog
　　FsImage 用于维护web文件管理系统树以及web文件管理树中所有的web文件管理和web文件管理夹的元数据
　　操作日志web文件管理 EditLog 中记录了所有针对web文件管理的创建、删除、重命名等操作

名称节点记录了每个web文件管悝中各个块所在的数据节点的位置信息

FsImage web文件管理没有记录web文件管理包含哪些块以及每个块存储在哪个数据节点。而是由名称节点把这些映射信息保留在内存中当数据节点加入 HDFS 集群时，数据节点会把自己所包含的块列表告知给名称节点此后会定期执行这种告知操作，以确保名稱节点的块映射是最新的

在名称节点启动的时候，它会将 FsImage web文件管理中的内容加载到内存中之后再执行 EditLog web文件管理中的各项操作，使得内存中的元数据和实际的同步存在内存中的元数据支持客户端的读操作。

一旦在内存中成功建立web文件管理系统元数据的映射则创建一个噺的 FsImage web文件管理和一个空的 EditLog web文件管理

名称节点起来之后，HDFS 中的更新操作会重新写到 EditLog web文件管理中因为 FsImage web文件管理一般都很大（GB 级别的很常见），如果所有的更新操作都往 FsImage web文件管理中添加这样会导致系统运行的十分缓慢，但是如果往 EditLog web文件管理里面写就不会这样，因为 EditLog 要小很多每次执行操作之后，且在向客户端发送成功代码之前edits web文件管理都需要同步更新。

名称节点运行期间 EditLog 不断变大的问题
在名称节点运行期間HDFS 的所有更新操作都是直接写到 EditLog 中，久而久之EditLog web文件管理将会变得很大

虽然这对名称节点运行时候是没有什么明显影响的，但是当名稱节点重启的时候，名称节点需要先将 FsImage 里面的所有内容映像到内存中然后再一条一条地执行 EditLog 中的记录，当 EditLog web文件管理非常大的时候会导致名称节点启动操作非常慢，而在这段时间内 HDFS 系统处于安全模式一直无法对外提供写操作，影响了用户的使用

第二名称节点 是 HDFS 架构中的┅个组成部分它是用来保存名称节点中对 HDFS 元数据信息的备份，并减少名称节点重启的时间SecondaryNameNode 一般是单独运行在一台机器上

数据节点是分咘式web文件管理系统 HDFS 的工作节点，负责数据的存储和读取会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点萣期发送自己所存储的块的列表

每个数据节点中的数据会被保存在各自节点的本地 Linux web文件管理系统中。

（1）HDFS 体系结构概述

集群包括一个名稱节点（NameNode）和若干个数据节点（DataNode）名称节点作为中心服务器，负责管理web文件管理系统的命名空间及客户端对web文件管理的访问集群中的數据节点一般是一个节点运行一个数据节点进程，负责处理web文件管理系统客户端的读/写请求在名称节点的统一调度下进行数据库块的创建、删除和复制等操作。每个数据节点的数据实际上是保存在本地 Linux web文件管理系统中的

（2）HDFS 命名空间管理

HDFS 的命名空间包含 目录、web文件管理囷块

在 HDFS1.0体系结构中，在整个 HDFS 集群中只有一个命名空间并且只有唯一一个名称节点，该节点负责对这个命名空间进行管理

HDFS 使用的是传统的 汾级web文件管理体系因此，用户可以 像使用普通web文件管理系统一样创建、删除目录和web文件管理，在目录间转移web文件管理重命名web文件管悝等。

HDFS 是一个部署在集群上的分布式web文件管理系统因此，很多数据需要通过网络进行传输

所有的 HDFS 通信协议都是构建在 TCP/IP 协议基础之上的

客戶端通过一个可配置的端口向名称节点主动发起 TCP 连接并使用客户端协议与名称节点进行交互

名称节点和数据节点之间则使用数据节点协議进行交互

客户端与数据节点的交互是通过 RPC（Remote Procedure Call）来实现的。在设计上名称节点不会主动发起 RPC，而是响应来自客户端和数据节点的 RPC 请求

愙户端是用户操作 HDFS 最常用的方式，HDFS 在部署时都提供了客户端

HDFS客户端是一个库暴露了 HDFS web文件管理系统接口，这些接口隐藏了 HDFS 实现中的大部分複杂性

严格来说客户端并不算是 HDFS 的一部分

客户端可以支持打开、读取、写入等常见的操作，并且提供了类似 Shell 的命令行方式来访问 HDFS 中的数據

此外HDFS 也提供了 Java API，作为应用程序访问web文件管理系统的客户端编程接口

（5）HDFS 体系结构的局限性

HDFS 只设置唯一一个名称节点这样做虽然大大簡化了系统设计，但也带来了一些明显的局限性具体如下：
1）**命名空间的限制：**名称节点是保存在内存中的，因此名称节点能够容纳嘚对象（web文件管理、块）的个数会受到内存空间大小的限制。
2）**性能的瓶颈：**整个分布式web文件管理系统的吞吐量受限于单个名称节点的吞吐量。
3）**隔离问题：**由于集群中只有一个名称节点只有一个命名空间，因此无法对不同应用程序进行隔离。
4）**集群的可用性：**一旦這个唯一的名称节点发生故障会导致整个集群变得不可用。

作为一个分布式web文件管理系统为了保证系统的容错性和可用性，HDFS 采用了多副本方式对数据进行冗余存储通常一个数据块的多个副本会被分布到不同的数据节点上，如图所示数据块 1 被分别存放到数据节点 A 和 C 上，数据块 2 被存放在数据节点 A 和 B 上这种多副本方式具有以下几个优点：

第一个副本，放置在上传web文件管理的数据节点；如果是集群外提交则随机挑选一台磁盘不太满、CPU不太忙的节点
第二个副本：放置在与第一个副本不同的机架的节点上
第三个副本：与第一个副本相同机架嘚其他节点上

HDFS 提供了一个 API 可以确定一个数据节点所属的机架 ID，客户端也可以调用 API 获取自己所属的机架 ID

当客户端读取数据时从名称节点获嘚数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点可以调用 API 来确定客户端和这些数据节点所属的机架 ID，当发现某个數据块副本对应的机架 ID 和客户端对应的机架 ID 相同时就优先选择该副本读取数据，如果没有发现就随机选择一个副本读取数据

HDFS 具有较高嘚容错性，可以兼容廉价的硬件它把硬件出错看作一种常态，而不是异常并设计了相应的机制检测数据错误和进行自动恢复，主要包括了一下几种情形：名称节点出错、数据节点出错和数据出错

名称节点保存了所有的元数据信息，其中最核心的两大数据结构是 FsImage 和 Editlog，洳果这两个web文件管理发生损坏那么整个 HDFS 实例将失效。因此HDFS 设置了备份机制，把这些核心web文件管理同步复制到备份服务器 SecondaryNameNode 上当名称节點出错时，就可以根据备份服务器 SecondaryNameNode 中的 FsImage 和 Editlog

每个数据节点会定期向名称节点发送“心跳”信息向名称节点报告自己的状态
当数据节点发生故障，或者网络发生断网时名称节点就无法收到来自一些数据节点的心跳信息，这时这些数据节点就会被标记为“宕机”，节点上面嘚所有数据都会被标记为“不可读”名称节点不会再给它们发送任何 I/O 请求
这时，有可能出现一种情况即由于一些数据节点的不可用，會导致一些数据块的副本数量小于冗余因子
名称节点会定期检查这种情况一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制为它生成新的副本
HDFS 和其他分布式web文件管理系统的最大区别就是可以调整冗余数据的位置

网络传输和磁盘错误等因素，都会造成數据错误
客户端在读取到数据后会采用 md5 和 sha1 对数据块进行校验，以确定读取到正确的数据
在web文件管理被创建时客户端就会对每一个web文件管理块进行信息摘录，并把这些信息写入到同一个路径的隐藏web文件管理里面
当客户端读取web文件管理的时候会先读取该信息web文件管理，然後利用该信息web文件管理对每个读取的数据块进行校验，如果校验出错客户端就会请求到另外一个数据节点读取该web文件管理块，并且向洺称节点报告这个web文件管理块有错误名称节点会定期检查并且重新复制这个块

备注：Hadoop 安装成功后，已经包含 HDFS 和 MapReduce不需要额外安装。而 HBase 等其他组件则需要另外下载安装。

在学习 HDFS 编程实践前我们需要启动 Hadoop 。执行如下命令：

java处理高并发高负载类网站中数据庫的设计方法（java教程,java处理大量数据java高负载数据） 

一：高并发高负载类网站关注点之数据库 

网站架构包括：前端架构+应用层架构+服务层架构+存储层架构+后台架构+数据中心机房架构+安全架构+数据采集与监控

并不是优化浏览器，而是通过优囮响应页面加快浏览器页面的加载和显示，常用的有页面缓存、合并HTTP 减少请求次数、使用页面压缩等 内容分发网络，部署在网络运营商机房通过将静态页面内容分发到离用户最近的CDN 服务器，使用户可以通过最短路径获取内容
• 动静分离，静态资源独立部署
  静态资源洳JS,CSS 等web文件管理部署在专门的服务器集群上，和Web 应用动态内容服务分离并使用专门的（二级）域名。
图片不是指网站Logo 按钮图标等这些web文件管理属于上面提到的静态资源，应该和JS CSS 部署在一起这里的图片指用户上传的图片，如产品图片、用户头像等图片服务同样使用独立蔀署的图片服务器集群，并使用独立（二级）域名 部署在网站机房，在应用服务器、静态资源服务器、图片服务器之前提供页面缓存垺务。 域名服务将域名解析成IP 地址，利用DNS 可以实现DNS 负载均衡配置CDN也需要修改DNS使域名解析后指向CDN 服务器。

应用层是处理网站主要业务逻辑的地方

将分别开发维护的动态内容和静态页面模板集成起来，组合成最终显示给用户的完整页面 将多台应用服务器组成┅个集群，通过负载均衡技术将用户请求分发到不同的服务器上以应对大量用户同时访问时产生的高并发负载压力。 为了实现高可用的應用服务器集群应用服务器通常设计为无状态，不保存用户请求上下文信息但是网站业务通常需要保持用户会话信息，需要专门的.机淛管理Session
使集群内甚至跨集群的应用服务器可以共享Session 对于访问量特别大而更新又不很频繁的动态页面可以将其静态化，即生成一个静态页媔利用静态页面的优化手段加速用户访问，如反向代理、CDN、 浏览器缓存等 将复杂而又庞大的业务拆分开来，形成多个规模较小的产品独立开发、部署、维护，除了降低系统耦合度也便于数据库业务分库。按业务对关系数据库进行拆分技术难度相对较小，而效果又楿对较好 将一台物理服务器虚拟化成多台虚拟服务器，对于并发访问较低的业务更容易用较少的资源构建高可用的应用服务器集群。

提供基础服务供应用层调用，完成网站业务

利用消息队列机制，实现业务和业务、业务和服务之间的异步消息发送及低耦匼的业务关系 提供高性能、低耦合、易复用、易管理的分布式服务，在网站实现面向服务架构SOA 通过可伸缩的服务器集群提供大规模热点數据的缓存服务是网站性能优化的重要手段。 系统运行需要配置许多参数如果这些参数需要修改，比如分布式缓存集群加入新的缓存垺务器需要修改应用程序客户端的缓存服务器列表配置，并重启应用程序服务器分布式配置在系统运行期提供配置动态推送服务，将配置修改实时推送到应用系统,无需重启服务器

• 网站在线业务需要存储的web文件管理大部分都是图片、网页、视频等比较小的web文件管理，但是这些web文件管理的数量非常庞大而且通常都在持续增加，需要伸缩性设计比较好的分布式web文件管理系统

• 大部分网站的主要業务是基于关系数据库开发的，但是关系数据库对集群伸缩性的支持比较差通过在应用程序的数据访问层增加数据库访问路由功能，根據业务配置将数据库访问路由到不同的物理数据库上可实现关系数据库的分布式访问

目前各种NoSQL 数据库层出不穷，在内存管理、数据模型、集群分布式管理等方面各有优势不过从社区活跃性角度看，HBase 无疑是目前最好的 在支持全球范围内数据共享的分布式数据库技术成熟の前，拥有多个数据中心的网站必须在多个数据中心之间进行数据同步以保证每个数据中心都拥有完整的数据。在实践中为了减轻数據库压力，将数据库的事务日志（或者NoSQL 的写操作Log) 同步到其他数据中心根据Log 进行数据重演，实现数据同步

网站应用中，除了要處理用户的实时访问请求外还有一些后台非实时数据分析要处理。

即使是网站内部的搜索引擎也需要进行数据增量更新及全量更新、構建索引等。
这些操作通过后台系统定时执行 根据离线数据，提供数据分析与数据挖掘服务 社交网站及购物网站通过挖掘人和人之间嘚关系，人和商品之间的关系发掘潜在的人际关系和购物兴趣，为用户提供个性化推荐服务

监控网站访问情况与系统運行情况，为网站运营决策和运维管理提供支持保障

通过在网站页面中嵌入JS 脚本釆集用户浏览器环境与操作记录，分析用户行为 服务器业务数据包括两种，一种是采集在服务器端记录的用户请求操作日志；一种是釆集应用程序运行期业务数据比如待处理消息数目等。 采集服务器性能数据如系统负载、内存使用率、网卡流量等。 将前述采集的数据以图表的方式展示以便运营和运维人员监控网站运行狀况，做
到这一步仅仅是系统监视更先进的做法是根据釆集的数据进行自动化运维，自动处理
系统异常状况实现自动化控制。 如果采集来的数据超过预设的正常情况的阈值比如系统负载过高，就通过邮件、
短信、语音电话等方式发出报警信号等待工程师干预。

保护网站免遭攻击及敏感信息泄露

以HTTP 请求的方式发起的攻击，危害最大的就是XSS 和SQL 注入攻击但是只要
措施得当，这两种攻击都是比較容易防范的 敏感信息加密传输与存储，保护网站和用户资产

山寨与创新的最大区别不在于是否抄袭、是否模仿，洏在于对问题和需求是否真正理解与把握

在解决问题之前能够认真思考自己面对的真正问题究竟是什么，有哪些技术方案可以选择其基本原理是什么。

网站架构其实并不难真正能解决问题的技术一定是简单的。

高并发、大流量；高可用；海量数据；用户分布广泛且网絡环境复杂；安全环境恶劣；需求快速变更发布频繁；渐进式发展。

1. 使用缓存减少数据库压力
   网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%
   
利用的是数据库的主从热备写主读从。
2. 加速网站访问速度：CDN和反向代理
   CDN 和反向代理的基本原理都是緩存，区别在于CDN 部署在网络提供商的机房使
   用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理
   则部署在网站的中心机房当用户请求到达中心机房后，首先访问的服务器是反向代理
   服务器如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户
3. 分布式数据库和分布式web文件管理系统
   网站更常用的数据库拆分手段是业务分库，将不同业务的数据
   库部署在不哃的物理服务器上
4. 使用NoSQL和搜索引擎

但事物发展到一定阶段，就会拥有自身的发展冲动摆脱其初衷，向着使自己更强
大的方向发展既嘫大型网站架构解决了海量数据的管理和高并发事务的处理，那么就
可以把这些解决方案应用到网站自身以外的业务上去我们看到目前許多大型网站都开
始建设云计算平台，将计算作为一种基础资源出售中小网站不需要再关心技术架构问
题，只需要按需付费就可以使網站随着业务的增长逐渐获得更大的存储空间和更多的

这个世界没有哪个网站从诞生起就是大型网站；也没有哪个网站第一次发布就拥有
龐大的用户，高并发的访问海量的数据；大型网站都是从小型网站发展而来。网站的
价值在于它能为用户提供什么价值在于网站能做什么，而不在于它是怎么做的所以
在网站还很小的时候就去追求网站的架构是舍本逐末，得不偿失的小型网站最需要做
的就是为用户提供好的服务来创造价值，得到用户的认可活下去，野蛮生长

技术是用来解决业务问题的，而业务的问题也可以通过业务的手段去解决。
恩不要妄图用技术解决所有问题。

单一职责上层对下层的依赖关系。 业务纵向分割分布式部署。 分层和分割都是为了便于分布式部署
常用的分布式方案有：分布式应用和服务；分布式静态资源；分布式数据和存储；分布式计算。 缓存是改善軟件性能的第一手段
使用缓存有两个前提条件，一是数据访问热点不均衡某些数据会被更频繁的访问，
这些数据应该放在缓存中；二昰数据在某个时间段内有效不会很快过期，否则缓存的
数据就会因已经失效而产生脏读影响结果的正确性。 将一个业务操作分成多个階段每个阶段之间通过共享数据的方式异步执行进行协作。
在分布式系统中多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署

从性能、可用性、伸缩性、扩展性、安全这五个要素。
所谓伸缩性是指通过不断向集群Φ加入服务器的手段来缓解不断上升的
用户并发访问压力和不断增长的数据存储需求
衡量架构伸缩性的主要标准就是是否可以用多台服務器构建集群，是否容易向集群
中添加新的服务器加入新的服务器后是否可以提供和原来的服务器无差别的服务。集
群中可容纳的总的垺务器数量是否有限制

关系数据库虽然支持数据复制，主从热备等机制但是很难做到大规模集群的可伸
缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现通过路由分区等手段
将部署有多个数据库的服务器组成一个集群
至于大部分NoSQL 数据库产品，由于其先天僦是为海量数据而生因此其对伸缩性
的支持通常都非常好，可以做到在较少运维参与的情况下实现集群规模的线性伸缩

扩展性是指的功能扩展，伸缩是指性能伸缩

System Load 即系统负载，指当前正在被CPU 执行和等待被CPU 执行的进程数目总和是反映系统忙闲程度的重要指标。多核CPU 的情况下完美情况是所有CPU 都在使用，没有进程在等待处理所以Load 的理想值是CPU 的数目。当Load 值低于CPU 数目的时候表示CPU 有空闲，资源存茬浪费；当Load 值高于CPU 数目的时候表示进程在排队等待CPU 调度，表示系统资源不足影响应用程序的执行性能。
在Linux 系统中使用top 命令査看该值昰三个浮点数，表示最近1 分钟10 分钟，15 分钟的运行队列平均进程数

性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试

排査一个网站的性能瓶颈和排査一个程序的性能瓶颈的手法基本相同：检査请求处
理的各个环节的日志，分析哪个环节响應时间不合理、超过预期；然后检査监控数据
分析影响性能的主要因素是内存、磁盘、网络、还是cpu? 是代码问题还是架构设计不
合理，戓者系统资源确实不足

主要优化手段有优化浏览器访问、使用反向代理、CDN 等。
优化浏览器访问的措施：

HTTP 协议是无状态的应鼡层协议意味着每次HTTP 请求都需要建立通信链路、进行数据传输，而在服务器端每个HTTP 都需要启动独立的线程去处理。这些通信和服务的開销都很昂贵减少HTTP 请求的数目可有效提高访问性能。
减少HTTP 的主要手段是合并CSS,合并JavaScript,合并图片将浏览器一次访问需要的JavaScript CSS 合并成一个web文件管悝，这样浏览器就只需要一次请求图片也可以合并，多张图片合并成一张如果每张图片都有不同的超链接，可通过CSS 偏移响应鼠标点击操作构造不同的URL 对一个网站而言，CSS? JavaScript , Logo图标这些静态资源web文件管理更新的频率都比较低而这些web文件管理又几乎是每次HTTP 请求都需要的，如果将这些web文件管理缓存在浏览器中可以极好地改善性能。
器缓存缓存时间可以是数天，甚至是几个月
在某些时候，静态资源web文件管悝变化需要及时应用到客户端浏览器这种情况，可通改变web文件管理名实现即更新JavaScript web文件管理并不是更新JavaScript web文件管理内容，而是生成一个新嘚JS web文件管理并更新HTML web文件管理中的引用
使用浏览器缓存策略的网站在更新静态资源时，应采用批量更新的方法比如需要更新10 个图标web文件管理，不宜把10 个web文件管理一次全部更新而是应一个web文件管理一个web文件管理逐步更
新，并有一定的间隔时间以免用户浏览器突然大量缓存失效，集中更新缓存造成服
务器负载骤增、网络堵塞的情况。 在服务器端对web文件管理进行压缩在浏览器端对web文件管理解压缩，可有效减少通信传输的数
压缩可达到较好的效果但是压缩对服务器和浏览器产生一定的压力，在通信带宽良好
而服务器资源不足的情况下偠权衡考虑。 但如果页面解析时就需要用到JavaScript, 这时放在底部就不合适了

网站性能优化第一定律：优先考虑使用缓存优化性能。
产品在设计之初就需要一个明确的定位：什么是产品要实现的功能什么
不是产品提供的特性。在产品漫长的生命周期中会有形形色色的困难和诱惑
来改变产品的发展方向，左右摇摆、什么都想做的产品最后有可能成为一个
消息队列。需要注意的是由于数据写叺消息队列后立即返回给用户，数据在后续的业务校验、写数据库等操作可能失败因此在使用消息队列进行业务异步处理后，需要适当修改业
任何可以晚点做的事情都应该晚点做 启动线程数= [任务执行时间/ (任务执行时间-10 等待时间）] xCPU 内核数
最佳启动线程数和CPU 内核数量成正比，和IO 阻塞时间成反比
如果是计算型任务，那么线程数最多不超过CPU 内核数因为启动再多线程，CPU 也来不及调度；相反如果是任务需要等待磁盘操作网络响应，那么多启动线程有助于提高任务并
发度提高系统吞吐能力，改善系统性能
1. 对象复用。单例和池技术

B+树，关系型数据库多采用此数据结构
NoSql产品多采用LSM树作为主要数据结构。
在LSM 树上进行一次数据更新不需要磁盘访问在内存即可完成，速度远快于B+
树当数据访问以写操作为主，而读操作则集中在最近写入的数据上时使用LSM树可以极大程度地减少磁盘的访问次数，加快訪问速度

RAID，通过使用RAID 技术实现数据在多块磁盘上的并发读写和数据备份。
RAID 技术在传统关系数据库及web文件管理系统中应用比较广泛但昰在大型网站比
较喜欢使用的NoSQL? 以及分布式web文件管理系统中，RAID 技术却遭到冷落

4个9也就是一年中大约最多53 分钟不可用。

主要掱段是数据和服务的冗余备份及失效转移

CAP 原理认为，一个提供数据服务的存储系统无法同时满足数据一致性
通常我们必须去保证A可用性囷P扩展性某种程度上放弃C一致性。

数据最终一致性这是数据一致性中较弱的一种，数据可能不一致但经过一段时间的自我恢复和修囸，数据达到最终一致

数据备份，冷备和热备热备又分同步热备和异步热备。

失效转移操作由三部分组成：失效确认、访问转移、数據恢复

实现负载均衡的基础技术：

这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成
一次访問性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩
性规模有限；使用HTTP302 响应码重定向有可能使搜索引擎判断為SEO 作弊，降低搜
索排名因此实践中使用这种方案进行负载均衡的案例并不多见。
• DNS 域名解析负载均衡
  事实上大型网站总是部分使用DNS 域名解析，利用域名解析作为第一级负载均衡
  手段即域名解析得到的一组服务器并不是实际提供Web 服务的物理服务器，而是同样
  提供负载均衡垺务的内部服务器这组内部负载均衡服务器再进行负载均衡，将请求分
  发到真实的Web 服务器上
这种数据传输方式又称作三角传输模式，負载均衡数据分发过程中不修改IP 地址
只修改目的mac 地址，通过配置真实物理服务器集群所有机器虚拟IP 和负载均衡服务器
IP 地址一致从而达箌不修改数据包的源地址和目的地址就可以进行数据分发的目的
是目前大型网站使用最广的一种负载均衡手段。在Linux 平台上最好的链路层负載均衡开源产品是LVS ( Linux Virtual Server )

计算机领域有句话：计算机的任何问题都可以通过增加一个虚拟层来解决。
那么在实践中，一台物理服务器虚拟为哆少个虚拟服务器节点合适呢太多会影响
性能，太少又会导致负载不均衡一般说来，经验值是150当然根据集群规模和负载均
衡的精度需求，这个值应该根据具体情况具体对待

使用开源中间件，如Cobar原理是在数据库之上又加了一层。是一个分布式数据库的访问代理
当湔分布式数据库无法解决的问题是，无法跨库Join更无法实现跨库事务。
所以需要从业务上避免分布式数据库的缺点：避免事务或者利用事務补偿机制代替数据库事务分解数据访问逻辑避免Join操作。

还有一类分布式数据库可以支持JOIN 操作执行复杂
的SQL 査询如GreenPlum? 但是这类数据库的訪问延迟比较大（可以想象，JOIN 操作
需要在服务器间传输大量的数据） 因此一般使用在数据仓库等非实时业务中。

NoSQL数据库产品都放弃了关系数据库的两大重要基础：以关系代数为基础的结构化査询语言
( SQL ) 和事务一致性保证（ACID )而强化其他一些大型网站更关注的特性：高可用性

设计网站可扩展架构的核心思想是模块化，并在此基础之上降低模块间的耦合性，

• 利用分布式消息队列降低系统耦合性
• 利鼡分布式服务框架如Dubbo
• 搭建开放平台建设网站生态圈
  API接口，协议转换安全，审计路由，流程

XSS跨站点脚本攻击。恶意脚本执行
防御：消毒（特殊字符转义）

注入攻击，消毒预编译

CSRF，跨站点请求伪造其核心是利用了浏览器Cookie 或服务器Session 策略，盗取用户身份

常用的单向散列算法有MD5? SHA 等。单向散列算法还有一个特点就是输入的任何
微小变化都会导致输出的完全不同这个特性有时也会被用来生成信息摘要、计算具有
高离散程度的随机数等用途。 常用的对称加密算法有DES 算发、RC 算法等 非对称加密的常用算法有RSA 算法

正则表达式的效率一般较差仅适用于短文本及低并发场景。
高并发时使用的公幵的算法有很多基本上都是Trie 树的变种，空間和时间复杂度都比较好
的有双数组Trie 算法等

网站如果为秒杀时的最高并发访问量进行设计部署，就需要比正常运营多得多嘚服务器而这些服务器在绝大部分时候都是用不着的，浪费惊人所以网站的秒杀业务不能使用正常的网站业务流程，也不能和正常的網站交易业务共用服务器必须设计部署专门的秒杀系统，进行专门应对

如果部署在一起，稍有不慎全业务瘫痪
1. 高并发下的應用、数据库负载。
2. 突然增加的网络及服务器带宽
下单页面也是一个普通的URL, 如果得到这个URL 不用等到秒杀开始就可以下单了。

2秒杀产品页面静态化
使其不需要经过web服务器和数据库服务器。

1. 动态生成随机下单页面URL
   为了避免用户直接访问下单页面URL. 需要将该URL 动态化即使秒杀系统的开发
   者也无法在秒杀开始前访问下单页面的URL. 办法是在下单页面URL 加入由服务器端生
   成的随机数作为参数，在秒杀开始的时候才能得到

1. 如何控制秒杀按钮的点亮
   解决办法是使用JavaScript 脚本控制，在秒杀商品静态页面中加入一个JavaScript 文
   件引用该JavaScript web文件管理中加入秒杀昰否开始的标志和下单页面URL 的随机数参数，
   当秒杀开始的时候生成一个新的JavaScript web文件管理并被用户浏览器加载控制秒杀商品页面
   的展示。这個javaScript web文件管理使用随机版本号并且不被浏览器、CDN 和反向代理服务
   2，只允许用户的第一个下单请求到达服务器
   并且服务器接收到的单量超过設定值后其他的请求直接秒杀结束。
   如果服务器出错直接秒杀结束页面。

• 控制业务日志级别warn
• 某些第三方包吔会打太多错误日志要关闭
• 自己的业务日志和第三方的日志要分开配置

原因：首页访问了数据库
- 首页访问频繁，不要直接访问數据库
- 首页最好应该做出静态的

缓存服务器宕机数据库压力陡增引发宕机。

• 缓存服务器也很重要大家普遍不够重視

应用启动不同步引发故障

发JBoss? 在发布时，Apache 和JBoss 同时启动由于JBoss 启动时需要加载很多应用并
初始化，花费时间较长结果JBoss 还没有完全启动，Apache 就已经启动完毕开始接收
用户请求大量请求阻塞在JBoss 进程中，最终导致JBoss 崩溃除了这种Apache 和JBoss
启动不同步的情况，网站还有很多类似的场景都需要后台服务准备好，前台应用才能
启动否则就会导致故障。

有几个web文件管理非常夶有数百兆，读写这些大web文件管理一
次需要几十秒这段时间，磁盘基本被这个web文件管理操作独占导致其他用户的web文件管理操作缓慢。

• 大web文件管理和小web文件管理区分存储区别对待。

架构师作为项目组最资深的专业技术人员是项目组开发测试工程师的前辈。从架
构师的身上工程师可以看到自己的未来，因此架构师在做人做事方面需要严格要求自

一定要坚信：一群优秀的人做┅件他们热爱的事一定能取得成功。不管过程多么
曲折不管外人看来多么不可思议不靠谱。
领导的真谛：寻找一个值得共同奋斗的目標营造一个让大家都能最大限度
发挥自我价值的工作氛围。
没有懒惰的员工只有没被激发出来的激情。所有强迫员工加班的管理者都應该为

是事情成就了人而不是人成就了事。指望优秀的人来帮自己成事不如做成一件
事让自己和参与的人都变得优秀。

架构师要和项目组全体成员共同描绘一个蓝图这个蓝图是整个团队能够认同的，
是团队共同奋斗的目标
蓝图应该是表述清楚的：产品要做什么、不做什么、要达到什么业务目标，都需要
蓝图应该是形象的：产品能为用户创造什么价值、能实现什么样的市场目标、产品
最终会长什么样都需要形象地想象出来。
蓝图应该是简单的：不管内部还是外部沟通都能一句话说明白：我们在做什么。
藍图应该写在软件架构设计文档的扉页、写在邮件的签名档、写在内部即时通信群
在项目过程中架构师要保持对目标蓝图的关注，对任哬偏离蓝图的设计和决定保持警惕错误的偏离要及时修正，必要的变更要经过大家讨论并且需要重新获得大家

架构师需偠对系统架构负责，但并不是说一定要架构师自己完成架构设计并要项
目团队严格遵守架构决策。
把架构和架构师凌驾于项目和项目组の上只会让架构师变成孤家寡人，让架构曲
1. 不要只有架构师一个人拥有架构
2. 让其他人维护框架与架构文档

不要企图在项目中证奣自己是正确的一定要记住，你是来做软件的不是来当老
大的。所以不要企图去证明自己了不起永远也别干这种浪费时间、伤害感凊的事

很多时候，对架构和技术方案的反对意见其实意味着架构和技术方案被关注、被
试图理解和接受。架构师不应该对意见过于敏感这时架构师应该做的是坦率地分享自
己的设计思路，让别人理解自己的想法并努力理解别人的想法求同存异。
对于技术细节的争论应該立即验证而不是继续讨论当讨论深入到技术细节的时候
也意味着问题已经收敛，对于整体架构设计各方意见正趋于一致。
而当大家鈈再讨论架构的时候表明架构已经融入到项目、系统和开发者中了，架
构师越早被项目组遗忘越表示架构非常成功；项目组越离不开架构师，越表示架构还

架构师作为团队的技术领导者在项目过程中不要去试图控制什么，带着一个弹性
的计划和蓝图推进团隊会管好他们自己。你越是强加禁令队伍就越是没有纪律；你
越是强制，团队就越是不能独立自主；你越是从外面寻找帮助大家就越昰没有信心。

其实即使是在一流的技术团队里也一定有数不清的问题，只是人们习惯了这些问
题以至于无视它们的存在。正所谓“鱼是最后一个看见水的”天天面对这些问题，反

问题被发现它只是问题发现者的问题，而不是问题擁有者的问题如果想要解决一个问题，就必须提出这个问题让问题的拥有者知道问题的存在。 　　

• 把“我的问题”表述成“我们的问題”
• 给上司提封闭式问题给下属提开放式问题
  不要问上司“你觉得该怎么办？”这种没有建设性的开放式问题给上司
  提问题是希望能夠得到他的支持，而不是带着一头雾水等他去指点迷津公司
  付你薪水不是让你睁着迷茫的眼睛卖萌。给上司提问应该是“你觉得A 和B 两
  个方案哪个更好”这种封闭式问题。
如果在合作中出现问题告诉他问题的存在和紧迫性，而不是责问他为什
所谓直言有讳是指想要表达嘚意图要直截了当说明白不要兜圈子，但是
在表达方式上要有所避讳照顾到当事人的感受。

1. 在解决我的问题之前先解决你的问题
   先解决别人的问题有几个好处：
   你帮别人解决了问题，礼尚往来别人也会帮你解决问题。
   在帮别人解决问题的过程中熟悉了情况，后面解决自己的问题也就得
   解决别人的问题时使用的是你的解决方案这个方案在你的控制之中，
   将来往这个方案里再塞一些东西解决自己的问题手到擒来。